devopsy.kinsta.cloud

Tag: open source code

Sonar Acquires Tidelift to Extend DevSecOps Reach Into Open Source Software

Sonar today revealed it has agreed to acquire Tidelift to gain access to third-party open-source code that it plans to integrate into its static code analysis tools.

Harry Wang, vice president of growth and new ventures for Sonar, said that while the company’s existing portfolio makes it possible for DevSecOps teams to analyze code they have written, the integration with a Tidelift platform that identifies dependencies and associate flaws in open source software will extend the reach of the Sonar platform.

The combined company will reveal specific product plans early in 2025, said Wang. Earlier this year, Sonar in addition to adding generative artificial intelligence (AI) capabilities to its core platform for remediating vulnerabilities, also unveiled a tool that identifies vulnerabilities in code generated by artificial intelligence (AI) platforms.

That AI Code Assurance tool makes use of the core engine Sonar, developed for analyzing code to surface issues in code generated by platforms such as Chat GPT. At the same time, Sonar launched AI CodeFix, a tool that invokes large language models (LLMs) to surface recommendations for improving code, that development teams approve before being automatically applied.

The combined company will continue to be committed to keeping human developers in the loop as more code is generated using AI platforms, said Wang. The challenge is that the volume of code that will soon be generated will overwhelm the DevSecOps teams that are dedicated to ensuring that code that makes it into a production environment is of the highest quality possible, as organizations embrace secure-by-design principles, he added.

It’s not clear how much DevSecOps progress is being made, but a Techstrong Research survey finds less than half (47%) of respondents work for organizations that regularly employ best DevSecOps practices. Only 54% of respondents regularly practice code scanning for vulnerabilities during development, while 40% conduct security testing, the survey finds.

On the plus side, a full 59% of respondents said they are also making further investments in application security, with 19% describing their investment level as high. Nearly two-thirds (64%) also noted they are specifically investing in a code scanning tool, with 24% describing those investments as high.

Regardless of the current level of commitment to DevSecOps and code scanning, it’s only a matter of time before more stringent regulations require organizations to ensure that routine vulnerabilities don’t find their way into production applications. Organizations will need to be able to demonstrate that reasonable efforts were made to protect the software supply chain that was relied on to build and deploy software.

As a result, most organizations will be revisiting software supply chain security in the months ahead, either before or shortly after those regulations go into effect.

In the meantime, securing application software in an era where the dependencies on third-party code provided by maintainers of open-source repositories remains a major concern. The challenge now is finding a way to secure applications regardless of who, or what, created the code that drives them.

December 17, 2024
Most Critical Open Source Projects Lack Memory-Safe Code, CISA Says

The country’s top cybersecurity agency is continuing to urge software developers to adopt memory-safe programming languages to help reduce the number of vulnerabilities in their products, most recently through a report showing that more than half of widely used open-source projects contain memory-unsafe code.

CISA and the FBI also found that 55% of the lines of code in the projects were written in memory-unsafe languages and that the largest projects disproportionately were written in such languages. In addition, even projects that were said to be programmed in memory-safe languages included some components created with memory-unsafe code.

In the joint 22-page report released this week and developed in conjunction with counterparts from Canada and Australia, the agencies recommended software makers create roadmaps for transitioning to memory-safe roadmaps, including plans for addressing memory safety in external dependency, which tend to include open-source software (OSS).

The report, “Exploring Memory Safety in Critical Open Source Projects,” “provides a starting point for these roadmaps by investigating the scale of memory safety risk in selected OSS,” the agencies wrote.

CISA and other government agencies for more than a year have been beating the drum for memory-safe languages, encouraging developers to migrate away from C and C++ and adopting such languages as Rust, C#, Go, Java, Python and Swift.

A Needed Change

Such a transition will eliminate many of the memory safety issues that have haunted software developers for decades and account for the most common flaws in software, according to CISA. These vulnerabilities affect how memory is accessed, written, or allocated in ways never intended in the programming languages.

They can lead to more updates, patching and incident responses that can cost both the software maker and their users. The vulnerabilities also open up the software to exploitation by bad actors. The flaws can include buffer overflows, use of uninitiated memory and use after free.

Memory-safe languages essentially prevent programmers from creating code that can lead to memory bugs and security flaws by including features that automatically catch memory access errors, like dangling pointers and buffer overflows, at the compile time and runtime stages. C, C++, and similar non-memory safe languages don’t have such automatic functions, which leads to more bugs ending up in the final version of the code.

“Memory-unsafe languages require developers to properly manage memory use and allocation,” the agencies wrote in the report. “Mistakes, which inevitably occur, can result in memory-safety vulnerabilities such as buffer overflows and use after free. Successful exploitation of these types of vulnerabilities can allow adversaries to take control of software, systems and data.”

That said, “memory-safe languages shift the abstraction layer and responsibility for writing memory-safe code from the developer to the compiler or interpreter, vastly reducing opportunities to introduce memory-safety vulnerabilities.”

More Work to Be Done

The 172 open-source projects analyzed came from the Open Source Security Foundation (OpenSSF) Securing Critical Projects Working Group’s list of critical projects.

The agencies found that even for projects written in memory-safe languages, there still can be memory safety flaws.

“This can be caused by direct use of memory-unsafe languages or external dependency on projects that use memory-unsafe languages,” they wrote. “Additionally, low-level functional requirements to disable memory safety may create opportunities for memory safety vulnerabilities in code written in otherwise memory-safe languages. These limitations highlight the need for continued diligent use of memory-safe programming languages, secure coding practices and security testing.”

Not Always an Easy Transition

Neatsun Ziv, co-founder and CEO of OX Security, said he wasn’t surprised that many of these projects use memory-unsafe languages. A barrier to shifting to memory-safe code is the prevalence of legacy systems built with C and C++.

“Rewriting these in modern, memory-safe languages is not only costly but also complex, potentially leading to disruptions in critical business operations,” Ziv said. “The key challenge lies in balancing enhanced security with the financial implications.”

He recommended companies create detailed plans for migrating to memory-safe languages, including prioritizing the most critical components first. In addition, they should use advanced code analysis tools and compilers to automatically detect and correct unsafe coding practices and establish clear governance frameworks that integrate memory safety and secure coding practices across the software development lifecycle.

“Focusing on memory safety is crucial for enhancing the security of future software development,” Ziv said. “However, transitioning from existing systems involves significant upfront investment and careful weighing of costs, benefits, and potential security compromises for each organization, which is why it’s taking a significant amount of time for enterprises to make the switch.”

Building the Case

The report builds on another document, “The Case for Memory Safe Roadmaps,” which CISA and agencies in other countries released in December 2023. CISA Director Jen Easterly at the time put adopting memory-safe coding into national security terms and said it was a key part of the federal government’s Secure By Design initiative to encourage developers to integrate security capabilities throughout the entire software development lifecycle rather than bolting it on at the end.

It also in line with another push by the Biden Administration to lift the responsibility of securing software and other technologies from the users and put it on the shoulders of developers.

In February, the White House issued a technical report that reinforced the argument that greater use of memory-safe languages would eliminate a range of security flaws, with National Cyber Director Harry Coker saying in a statement that “we, as a nation, have the ability – and the responsibility – to reduce the attack surface in cyberspace and prevent entire classes of security bugs from entering the digital ecosystem.”

June 28, 2024
Forking RHEL! Oracle and SUSE Join the Fight ¦ Silverman Sues AI Firms

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: SUSE announces a Red Hat Enterprise Linux fork after Oracle said a similar thing, and Sarah Silverman says OpenAI and Meta have stolen her words. (more…)

July 12, 2023
IBM/Red Hat Sparks Anger at GPL ‘breach’ as RHEL Source Locked Up

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Red Hat Enterprise Linux (RHEL) goes closed source. Well—no, not really; but IBM’s lawyers are accused of skating so close to the edge of legality that they risk violating the GNU Public License. (more…)

June 29, 2023
Rocky Linux Emerges as a CentOS Replacement

Rocky Linux was created to offer the community an alternative following Red Hat’s recent decision to shift its focus away from CentOS—the open source version of Red Hat Enterprise Linux (RHEL). However, the Linux distro’s popularly can also be attributed to how its creator sought to offer a superior alternative based on lessons learned during CentOS’ development—and less as a perceived backlash to Red Hat’s controversial move, said Gregory Kurtzer, Rocky Linux’s creator, who is also founder and CEO of Ctrl IQ.

“As one can probably imagine, there were a lot of lessons learned from the founding of CentOS—we did a lot of things correctly, but we made some mistakes, as well, that set into motion some of the difficulties the project went through,” said Kurtzer. “I was not—nor am I now—upset at Red Hat or anyone else. It’s important to understand that companies have a legal responsibility to do what they need to do. But I will say, this is why open source communities should not be controlled by a single company, especially if that company has a competing product to the open source project.”

In addition to applying experience gained from the CentOS project to help “recreate the initial goals of CentOS in a new project,” Kurtzer said he was prompted to create Rocky Linux following Red Hat’s decision to end-of-life (EOL) CentOS. The move “affected my company, our customers, as well as the entire industry,” said Kurtzer.

“To be blunt, my knowledge—in terms of doing it myself is severely dated. Luckily, after I made the announcement that I was considering recreating CentOS, thousands of people reached out to me wanting to be part of the project and contribute,” said Kurtzer. “From that, our development team and open source community was born.”

Additionally, CentOS Stream offers value to the community by allowing “us and others” to take part in developing the upstream Enterprise Linux standard, said Kurtzer, who added that his team will continue to debug Rocky Linux so that solutions are properly integrated into the Enterprise Linux Standard.

“The necessity was absolutely clear, so I founded Rocky Linux and the Rocky Enterprise Software Foundation (RESF),” Kurtzer explained. “Together with our contributors, sponsors and partners, we all have united for a common goal: to create an open source community that will provide us all with an enterprise operating system to stand the test of time, attrition and commercial agendas.”

Interest in the development of a CentOS alternative was strong when Kurtzer first floated the idea of the project to the community. Since its release in June, the total number of ISO downloads is 56,000, according to Rocky Linux Tier0 mirror data.

“We have zero visibility as to any other ISO downloads from any of our other mirrors, but if I were to guess, I’d say it would be about two to three times more, in total,” said Kurtzer. “When we all get a moment to breathe, it will be fun to see how many people are using Rocky Linux, and take in all the feedback the community has provided,” he said.

With this team of developers, Kurtzer said it took about seven months to build the general availability (GA) release. “We didn’t just jump right into building the operating system because the goal was to create an infrastructure where many contributors and developers can take part without putting the security of the product at risk. Building that infrastructure took about four months,” Kurtzer said. “Once the infrastructure was completed, we spent about two months building the first-release beta candidate and then spent the following month ensuring that we did everything correctly.”

July 13, 2021
Sonatype Advances Open Source Code Quality, Security

Sonatype today launched an Advanced Development Pack service that surfaces dependencies between open source components in a way that makes it easier for developers to know which ones to employ to build the most secure application possible and what components offer the simplest upgrade path.

Company CTO Brian Fox said the Advanced Development Pack service is an extension to the Nexus Lifecycle platform the company currently makes available to identify vulnerabilities in open source code.

The Advanced Service Pack was created after studying development and cybersecurity practices across 30,000 software teams that Sonatype was able to analyze in its Maven repository, said Fox. The goal is to eliminate a vicious cycle that emerges as organizations develop applications using components that too often need to be either replaced or updated depending on the security and quality issues uncovered later in the development life cycle. By making it easier to identify the highest-quality modules available, the Advanced Development Pack serves to increase developer confidence in the quality of the open source components being pulled as they develop their application.

A Component Chooser tool, currently in beta and slated for availability next year, will also make it possible to employ project hygiene ratings based on security and license compliance as well as identify where else that component may already be in use.

The Advanced Service Pack makes it possible to evaluate open source components based on factors such as project quality, ease of upgrade and advanced knowledge of abnormal committer behavior, said Fox. Other factors evaluated include the cost of migrating to a newer or safer version of a module and whether it is possible to do so without breaking code, release frequency, the cadence of dependency updates, development team size and popularity.

The Advanced Development Pack also furthers the adoption of best DevSecOps practices by identifying which dependencies have become vulnerable and have been remediated, as well as suspicious behavior involving project code commits that might be indicative of a malicious injection attack. It also applies machine and deep learning algorithms to automatically identify and block software supply chain attacks based on typosquatting and malicious code injection. In the past 90 days alone, the malicious code detection bots created by Sonatype have discovered 43 new malicious packages including electorn and loadyaml.

Sonatype has also included a transitive solver capability that provides comprehensive remediation advice for solving both direct and transitive dependencies without violating policies or failing builds.

Fox said that while there’s a lot of focus these days on making sure individual application components are secure, it’s also become apparent that cybercriminals are now targeting application development platforms as part of an effort to compromise the entire software supply chain. As such, DevOps teams now need to focus on securing both the components they employ and the platforms used to construct their applications.

In the meantime, there may never be such a thing as absolutely secure open source code. However, it is becoming possible to greatly minimize the risks associated.

October 7, 2020
Doing DevOps in an Interconnected World
Doing DevOps would be simple if you had total control over the tools, code and infrastructure that your company used. But the fact is, you don’t. Instead, we live in a world where most CI/CD chains connect in some way to third-party resources or processes.

In other words, doing DevOps effectively means integrating with entities that are external to your organization. Here’s a look at what this entails in practice and why it’s so important.

The Interconnected World of DevOps

Conversations about DevOps often assume that all DevOps processes happen internally. In reality, many software delivery pipelines depend on third-party resources and services. Consider the following examples of ways companies could make their software delivery chains dependent in part upon third-party agendas:
- They integrate open source code into their codebases and therefore depend on an open source community to write some of their code.
- They maintain relationships with partners and need to be sure their release schedules and toolchains are compatible with their partners’ needs.
- They need to make sure the applications they deliver work on different operating systems, browsers and hardware devices that are controlled by third parties.
- They are subject to regulatory rules handed down by third parties and must ensure their delivery chains meet those regulatory requirements.
- Their applications depend on APIs that are designed and updated by third parties.
In these ways and more, the CI/CD pipelines organizations build to do DevOps need to be able to integrate with, and adapt to, decisions made by third parties. If they don’t, the organizations risk problems such as broken code, the loss of partners and regulatory compliance issues.

Succeeding at Interconnected DevOps

This is why it’s critical to design CI/CD pipelines and other DevOps processes in ways that make them mesh with third-party resources and services. In practice, this means:
- Adopting tools that are flexible and have broad coverage. You don’t want to tell a partner you can no longer work with their code because your CI server doesn’t support their new programming language.
- Use branching in the CI/CD process. Multiple branches give you more flexibility to support different target environments. They also help you react to sudden changes made by third parties without having to overhaul your entire CI/CD process.
- Make sure your collaboration and communication channels integrate with those of third parties on whom you depend. If you use open source code in your application, for example, add the open source project’s security announcements to your Slack channel so you’ll be notified right away when a vulnerability arises.
- Choose your integrations wisely. Just because you can integrate a third-party API into your application, for example, doesn’t mean you should. Too many dependencies put the efficiency of your CI/CD pipeline at risk.
No matter the details of your CI/CD chain, the most important thing is simply to recognize that we live in a very interconnected world and most organizations don’t have total control over their software delivery processes. That’s just a fact of modern DevOps. But with the right planning and strategies, you can ensure that third-party dependencies add value to your software delivery pipeline rather than creating unnecessary risk and overhead.

— Chris Tozzi
July 10, 2019