devopsy.kinsta.cloud

Tag: open source vulnerabilities

Broadcom Launches Trusted Artifact Service for Spring Framework

Broadcom today at the VMware World Explore conference a set of hardened artifacts for the open source Spring framework, including the 5,000 dependencies that are needed to run it.

TrueSource Trusted Artifacts by Broadcom provides access to artifacts built in a clean room, including instances of Apache Tomcat, Kotlin, PostgreSQL, RabbitMQ, MySQL, and Valkey databases and middleware. It also extends to the Bitnami Secure Images catalog, adding hardened, verifiably built container images for hundreds of commonly used open source packages.

Based on the enterprise edition of the Spring framework that Broadcom supports, TrueSource Trusted Artifacts by Broadcom includes curated artifacts written in Java, Python and Node.js. Every library and artifact is selected against a reference architecture, then built and verified by human Broadcom engineers. That aspect of the service is critical because patches generated by AI coding that have not been validated by software engineers are much more likely to break an application running in a production environment.

Broadcom, via this service, will also scan customer repositories, assess the potential blast radius of each release, and then open pull requests based on the lowest-risk remediation path determined. There is also a set of dashboards through which DevSecOps teams can track what has been fixed and what tasks remain to be completed.

DevSecOps teams will also have the option to bring not-yet-public vulnerabilities they discover for early access remediation. In addition, there is a special program for critical infrastructure organizations that provides them with dedicated access to patch insights and mitigation advice.

Finally, Broadcom is committing to contributing the fixes it creates back to the maintainers of the open source software that it has remediated.

Purnima Padmanabhan, general manager for the Tanzu Division of Broadcom, said TrueSource Trusted Artifacts by Broadcom brings a lot of our open source capabilities together under one umbrella in a way that remains true to open source. In fact, Broadcom claims that over the past five months, engineers have already spent more than 12 billion tokens against frontier models to secure open source projects to ensure that every supported release line is patched before a Spring-related vulnerability is ever published.

Those efforts are crucial because earlier this year Broadcom revealed there has been a more than 1,700% surge in monthly security advisories reported by the Spring community, resulting in the largest set of security patches in Spring’s 23-year history being created and delivered.

Mitch Ashley, vice president and practice lead for software lifecycle engineering at The Futurum Group, said a curated pipeline inside the customer’s own build and deploy path addresses a key software supply chain requirement. Teams pull libraries, images, and data engines already built, signed, and pinned to the versions their release lines support, with automation that opens pull requests carrying the lowest-risk fix, he added.

That removes work enterprises absorb today: Triaging advisories, testing patches, and deciding what is safe to ship, noted Ashley.

It’s not clear to what degree exploits created using AI are starting to overwhelm DevSecOps teams, but the one thing that is clear is nearly all of them will require additional help to keep pace. After all, it’s not so much a question of whether there will now be more incidents so much as how much they can first be prevented and, just as importantly, rapidly contained.

August 31, 2026
Report Shines Spotlight on 91 Vulnerabilities Fixed in Latest Update to Spring Framework

A report published by Sonatype identifies more than 91 vulnerabilities that have been remediated in the latest update to the open source Spring framework for deploying Java applications mashed available by Broadcom earlier this month.

Released earlier this month, the 91 vulnerabilities affect 209,569 software components that will need to be updated.

Sonatype CTO Brian Fox said this large number of vulnerabilities that are being simultaneously released is another indication the providers of major software platforms are racing to pay down massive amounts of technical debt before vulnerabilities are discovered and exploited by cybercriminals that are gaining access to advanced artificial intelligence (AI) models.

Providers of platforms such as Spring already have access to those same AI models, which has given them a head start to find and remediate vulnerabilities before adversaries exploit them. In fact, Broadcom between March and April increased the number of advisories it has issued by more than 1,700%, according to the Sonatype report.

DevSecOps teams, in the meantime, are being tasked with making often simultaneous large-scale updates to multiple frameworks and platforms as providers rush to pay down technical debt that has been allowed to accrue for decades, noted Fox. Those teams, as a result, will need to find ways to automate the deployment of what will be a wave of patches that will need to be installed as quickly as possible. In many instances, DevSecOps teams will find they will be coping with tidal waves of updates to frameworks and platforms for multiple years to come, noted Fox.

Eventually, however, there can only be so many issues to fix, so following those waves of updates, the overall state of application security should substantially improve, he added. In the meantime, however, instead of applying patches to applications a couple of days a month, DevSecOps teams for the foreseeable future may find that they now need to continuously update applications, said Fox.

The challenge, of course, is that today exploits in many cases are being built faster than a patch can be created and applied. Adversaries are also becoming more adept at using AI to chain together low-level vulnerabilities to create a more lethal exploit. As such, DevSecOps teams are likely going to need to be able to apply virtual patches and other controls to mitigate threats while waiting for patches that, with the aid of AI coding tools, will now be made available much faster.

The proverbial fly in that ointment is that many of the maintainers of smaller open-source software projects that an application may depend on may not be able to keep pace. Multiple initiatives have been launched to aid those maintainers; however, many of those projects were created by a volunteer labor force that might not have the time, resources, or inclination to build, test and apply a software patch in a matter of days or, if needed, hours. Many enterprise IT organizations may need to rationalize the amount of open source software they have deployed because, as an unpaid labor force to keep pace with building, testing and applying patches is silly on its face, noted Fox.

At this juncture, it may not be possible to fix every application before it is exploited. Hopefully, however, organizations will be able to prioritize making updates to their most critical applications to, at the very least, limit the potential havoc that otherwise will most certainly soon ensue.

August 25, 2026
Chainguard Expands Repository to Add More Secure Open Source Libraries

Chainguard has expanded the number of secure open source libraries it makes available to include Java and JavaScript components based on code it has reworked to better secure software supply chains. Additionally, an expanded set of secure Python libraries, first introduced last year, is now generally available.

Bria Giordano, libraries lead for Chainguard, said the overall goal is to better secure software supply chains by making available a repository that organizations pay to access, from which developers can download software artifacts and components that adhere to Level 2 of the Supply-chain Levels for Software Artifacts (SLSA) framework defined by the Open Source Security Foundation (OpenSSF).

In total, Chainguard has rebuilt nearly one million unique versions of Java dependencies, including enterprise essentials such as Spring Boot, Jackson, Apache Commons, and Log4j, using the Chainguard Factory, an automated platform for creating software builds based on code originally found in open source software repositories.

Chainguard also covers 88% of the top 500 highest-impact JavaScript libraries, along with tens of thousands of additional libraries. Finally, Chainguard now covers 94% of Python dependencies typically found in applications.

In the last year, security researchers discovered more than 450,000 malicious packages. Chainguard provides DevOps teams with an alternative repository for downloading secure libraries and containers, constructed by developers that are augmented by artificial intelligence (AI) agents, to create libraries in a way that adheres to best DevSecOps practices.

That approach eliminates the need to rely on individual application developers to test every component they use for known vulnerabilities, noted Giordano. It’s simply not realistic to expect developers to keep track of millions of open source libraries that are found in repositories all across the web, she added. Instead, Chainguard researchers continuously monitor open source software projects for updates to ensure the libraries made available are based on the latest version of the code made available by maintainers, noted Giordano.

It’s not clear to what degree DevOps teams are adopting repositories that provide access to inherently more secure software than what might be found on GitHub or Maven. A recent Futurum Group survey finds that about 35% said they also plan to make some type of investment in application security, with well over a third of respondents expecting their organization to increase spending on software security testing (39%) and application programming interface (API) security (36%) over the next 12 to 18 months.

Chainguard, however, is making a case for resolving application security issues at the root cause by ensuring that the code that is often reused to build applications is fundamentally secure.

Mitch Ashley, vice president and practice lead for software lifecycle engineering at The Futurum Group, said Chainguard’s expansion of its repository service shifts supply chain security from perimeter defense to source control. Rebuilding at the dependency layer targets the unverified libraries where most of the issues that led to an application security incident really began, he said.

Hopefully, there will come a time when AI tools generate open source code that has fewer vulnerabilities than what is being seen today, but in the meantime, DevOps teams would be well-advised to always consider the source when downloading any type of software component.

March 4, 2026
DevSecOps Implementation: Source Composition Analysis
This is the second installment in this series on DevSecOps. Read the first installment, on Static Analysis, here.

One of the better additions to security in recent years is source composition analysis (SCA). The purpose of SCA is to sit in the gap between static analysis and dynamic analysis to help you find issues introduced by included libraries, projects, etc. While effective, source composition analysis is only available on open source libraries and packages, which are the highest growth areas of external sources in any project. If we are purchasing a product to include in our application, we take our time and compare and contrast to make certain we have the right thing. If there is an open source option, we just drop it in. Particularly if the option is popular—little thought goes into using MySQL database in Python or its equivalent in other languages. If a Python project uses MySQL or MariaDB, it is needed, so it is grabbed and used.

The growth of source composition analysis is a great boon to security. Having a tool that takes care of monitoring vulnerabilities in code that is included across the board, sometimes in very uncontrolled ways, means vulnerabilities are known before the app goes live or the new release is published. Security staff doesn’t have to try to ferret out what is included in projects across the org and then cross-reference those findings with the National Vulnerability Database (NVD) or project-specific lists. The tool takes a load off security’s shoulders and makes certain developers know the risks their open source software (OSS) usage represents. The best tools notify developers when including vulnerable open source and can be configured to require approval before a vulnerable OSS library/module can be included.

With all of that said, let’s talk about what to look for. There are some similarities with our static analysis list, but some distinct differences also. Disclaimer: As mentioned in the Static Analysis blog, this is very high-level. The research we’ve done at Accelerated Strategies Group went much deeper than we can present in a series of blogs; this is just to help you understand the top-level issues and get started down the road to a solid DevSecOps plan:
- Language Support: This goes beyond most users’ needs in static analysis. One of open source’s strengths is building off other projects. It is often the case that Python will call C modules and some Python projects even include Go libraries. This means your chosen development tools aren’t so much relevant for scanning as the development tools chosen by projects—and their included projects.
- Depth of Checking: Which brings us to, “How deep does the tool go?” Nesting of open source libraries can be deep and complex, with the project an application uses directly just the tip of the ice-berg. Ideally, look for a tool that answers the, “Is this even ever called?” question. It’s a good start to alert on included OSS projects and it is far better to alert on ones where the vulnerable parts are called from somewhere in the hierarchy.
- Where to Run: The market is slowly moving to support both cloud-based and local scans. Make certain your organization’s needs are met by the vendor’s offerings.
- When to run: Some vendors bundle source composition analysis in with their static analysis IDE plugins; others have developers run the scan command line; others offer source composition analysis at the build step—when the app is together in one place; still others offer all of the above. Again, make certain the needs of your organization are met.
- What Is Detected: As with most security tools, this is normally a base comprised of public sources (NVD, OWASP), with add-on detection from other sources. Know what those other sources are and what they offer: that is one major difference between most products.
- Reporting: Make certain that vulnerability reporting has everything you need. Consider the possibility that it alerts on a vulnerable OSS library in source file insecure.go. All other uses of that vulnerability need to be visible in some way from that report. Removing the reference from insecure.go is useless if reallyinsecure.go also includes it and has an exception from management to keep the inclusion.
- Reporting Integration: While scanning OSS usage and vulnerabilities the usage introduces is important, so also is the ability to see these results side by side with static, dynamic and even interactive scans so the overall security posture of the application can be evaluated.
- Frequency Versus Cost: OSS vulnerabilities come in unpredictable patterns, with several dropped in a week after no important ones were seen the week before. You are going to want to run these scans frequently enough to feel comfortable with your security posture, but depending upon licensing, each run might cost your company money. Make sure you understand your needs and costs associated with meeting them.
- Licensing: The newest feature to be added to these tools is the ability to list all licenses of all included libraries so that someone can review and see what risk is introduced to the organization from licensing. Many open source projects are licensed so that commercial use is limited; this tool puts all the various licenses together so an organization can evaluate litigation risk based upon license usage. The best tools allow you to also enter proprietary license information so that all licensing relevant to an application is reviewed together.
These tools help improve security posture by automating what is an increasingly complex manual process and bringing in vulnerability sources that security (be they secure developers or dedicated security staff) would have to manually look for. They enable shifting OSS vulnerability resolution left, allowing your team to become more agile and proactive. Make certain the tool chosen is the right one for the organization.

As I said in the last installment, you all are keeping the lights on in a truly difficult time, making a tough job look easy. Don’t let vulnerabilities that can be caught easily with these tools but might stay hidden without stop your great work. They are relatively easy to install and configure; once you have them, you have on-demand OSS vulnerability scanning and if you are like most organizations, OSS is a huge piece of your software infrastructure. Keep rocking it, and make sure you are covered for OSS vulnerabilities and licensing.
November 16, 2020
5 Ways to Detect Application Security Vulnerabilities Sooner to Reduce Costs and Risk

Security testing has always been an important step in the application development process. Yet, traditional measures often occur too late in the process to effectively find and fix vulnerabilities before causing costly production delays, or worse, putting organizations at risk for potential security breaches.

To minimize security-related costs and risks, testing needs to occur sooner and more frequently throughout the development process. But, how can you accomplish this while keeping pace with growing application development demands?

Looking at automation can help. Development teams have been using automation to streamline manual activities such as build, deployment and functional testing for years now, and it is time security testing joins the mix. By integrating automated security validation into the continuous integration/continuous development (CI/CD) pipeline, you can catch vulnerabilities sooner, reducing the potential risk and financial impact.

In this article, we’ll look at five ways automated technology tools can help safeguard the CI/CD pipeline: SAST, detecting OSS vulnerabilities, identifying compromising credentials, DAST and verifying cloud infrastructure security.

Your CI pipeline provides a ready-made check-in point to install the following automated security gates and pinpoint vulnerabilities.

Static Application Security Testing (SAST)

SAST provides the earliest check-in opportunity, allowing you to identify potential issues at the coding stage, so you can resolve problems without breaking builds or allowing vulnerabilities to get passed to the final application release.

Commercial solutions such as Checkmarx help to identify hundreds of security vulnerabilities and weaknesses in custom code. You can also leverage many open source linters for your specific platforms to detect various vulnerability patterns that can compromise code security.

Detecting Open Source Software Vulnerabilities

Just because the code is secure doesn’t mean the entire application is protected. Most applications use a large number of dependencies, or third-party open source software (OSS) components. These may have various security vulnerabilities and put your application at risk.

Tools such as Whitesource Bolt and Black Duck can scan all of your projects, not only to detect OSS components, but also identify and provide fixes for any known vulnerabilities.

Identifying Compromising Credentials

Human error is always a security concern, especially when it comes to credentials. Just consider how many times you’ve heard of developers committing code only to later realize they’d accidentally included a password. These errors can lead to high-cost consequences for organizations.

There are many tools that scan for secrets and credentials that can be accidentally committed to a source code repository. One example is Microsoft Credential Scanner (CredScan). Perform this scan in the PR/CI build to identify the issue as soon as it happens so they can be changed before this becomes a problem.

Once an application is deployed, you can continue to scan for vulnerabilities through the following automated continuous delivery pipeline capabilities.

Dynamic Application Security Testing

Unlike SAST, which looks for potential security vulnerabilities by examining an application from the inside—at the source code—Dynamic Application Security Testing (DAST) looks at the application while it is running to identify any potential vulnerabilities that a hacker could exploit.

OWASP Zed Attack Proxy (ZAP) is an open source tool for performing pen testing on web applications and APIs. Pen testing helps ensure that there are no security vulnerabilities hackers can manipulate. It can be installed as a client application or come configured on a docker container. OWASP ZAP scans can be incorporated into your pipeline to check every deployment for security vulnerabilities.

Verifying Cloud Infrastructure Security

Finally, in addition to validating the application, the infrastructure should be validated to check for vulnerabilities. When using a public cloud, deploying the application and shared infrastructure is easy, so it’s important to validate that everything has been done securely.

Each public cloud includes tools to help verify that the infrastructure has been provisioned securely. APIs can be leveraged to check immediately after deployment in lower environments to help ensure any infrastructure security issues are caught before they get to production. Additionally, tools such as InSpec provide compliance-as-code to enforce the intent of provisioned infrastructure is always being met.

Enabling continuous security validation through the CI/CD pipeline can help fortify applications against an expanding array of security threats that can lead to significantly higher costs and exposure. At the same time, automation tools can provide added layers of protection while meeting the organization application development demands.

May 19, 2020
Open Source Vulnerabilities Were Up 50% in 2019 — How Will It Impact Software Development in 2020?

Open source vulnerabilities have been on the rise in recent years, but 2019 was truly one for the record books with a spike of nearly 50% over the previous year.

According to the recently released State of Open Source Security Vulnerabilities report by the WhiteSource research team, the number of vulnerabilities jumped from 4,100 in 2018 to 6,100 in 2019.

Figure 1: Number of reported open source vulnerabilities per year.

In hopes of better understanding what is behind this rise in the number of open source vulnerabilities, what it tells us about the state of open source usage in modern software development, and even where we are likely headed in the years ahead, let’s take a look at the report’s findings for insights on the current state of open source security.

More Code, More Vulnerabilities

According to the research report, the primary driver behind the rise in open source vulnerabilities is a function of the growth of open source. There are now more open source projects, code and members of the community than ever before.

All of these good folks are working hard to not only write more code, often with the backing of large tech giants, but also to seek out vulnerabilities in the code that can put the users of their components at risk. The combination of more code being written and the number of eyeballs reviewing the code for those inevitable human mistakes, comes together to produce a larger number of vulnerabilities being reported.

The increase in the number of vulnerabilities in open source components will have a considerable impact on software development. In recent years, we have seen open source components playing a bigger role in how developers build their applications. Most estimates believe that open source components comprise between 60-80% of the codebase in most modern applications. When a vulnerability is reported in a popular project such as Apache Struts or the Linux kernel, then huge swaths of developers can quickly find their software in need of patching.

The Good, the Bad and the Bazaar

WhiteSource’s research revealed the reassuring news that over 85% of reported open source security vulnerabilities have a fix available.

One of the reasons for this improvement is the fact that more enterprises are dependent on open source components for their own software, so they are investing in making it more secure, via bug bounty programs, backing foundations that support open source security or backing the projects themselves.

However, even as the situation in the field appears to be improving, there is still a way to go.

The fact that many published open source vulnerabilities are not indexed in one central location adds complexity to this challenge for development teams attempting to stay on top of published open source security vulnerabilities. If proprietary software is still considered to be the classical Cathedral, well-organized information and support under one roof, then open source is very much the Bazaar.

The WhiteSource report found that only 84% of known open source vulnerabilities appear in the National Vulnerability Database (NVD). This means that information about another 16% of the known vulnerabilities is out there, spread out among a wide range of resources. These might be security advisories, bug trackers and a laundry list of other locations. While 45% of reported open source vulnerabilities that were not initially published on the NVD eventually end up there, that could take months since their publication on other resources.

The challenge for organizations is that they run the risk of using a vulnerable component unaware of the security updates, while hackers are scouring all resources, looking for vulnerabilities that could be their next meal ticket.

Given the evolving security challenges facing organizations, what does the future hold for open source security in the year ahead?

Our Predictions for 2020

The easiest prediction that we can provide is that 2020 will have even more reported open source vulnerabilities than were published in 2019. The only question is: How big it will be? Chances are that the count will be more significant due to recent advances making it easier than ever to report and an open source vulnerability.

This past year saw the launch of GitHub Security Lab which aims to help researchers, maintainers and users easily report an open source vulnerability and publish a verified fix in one centralized location. By simplifying the reporting and documentation process, GitHub has gone a long way in helping their users to protect their software with better quality reporting.

Key Takeaways

For many, the rise in the number of reported open source vulnerabilities might be concerning, making us confront the fact that we probably have plenty of them in our software right now. However, the situation is actually improving, and even heading in the right direction. When vulnerable open source components are reported, we get to track them and move quickly to remediate. Only once you know you have a problem can you begin to fix it.

Hopefully, the increase in security awareness will keep pushing for a stronger, more organized and better supported open source community that will be resilient in the face of even more vulnerabilities that are likely to show up in next year’s research report.

April 20, 2020
Python’s Popularity Continues: Examining the Top Use Cases
Python continues to be one of the most popular coding languages in use. In fact, the TIOBE index of programming language popularity named it the 2018 Language of the Year. Its usage and adoption continue to grow and proliferate into additional use cases.

Python’s popularity and growth are in part because it’s flexible and easy to use. Python has grown from a scripting solution for sysadmins to web development for programmers to the driving force behind machine learning. We’ve observed this growth since 1999, when we began to build engineering Python distributions. As we’ve seen the use cases grow, we’ve examined the top use cases by customers ActiveState has observed.

Let’s look at the three most popular Python use cases within the traditional tech space: infotech, software and hardware.

Infotech: IT modernization

The IT team of a state legislature is challenged to be able to remotely manage thousands of user desktops. Its 147 representatives, as well as its hundreds of supporting personnel, work on-premises and/or remotely. One of the key tools that empowered the team was Windows Powershell. Unfortunately, Powershell is unsupported and no longer works under newer Microsoft operating systems.

Rewriting any application that’s a cost center is always difficult to justify. As a result, rewrites are rarely budgeted, planned and resourced appropriately. But the alternative was much costlier in terms of capital and resources: dispatch IT personnel to physically install, update and manage each user’s desktop, on an on-call basis.

It’s famously easy to get started and develop with Python. While there was no way around a rewrite of the desktop management scripts, the IT team could at least minimize the time and resources required. Python allowed Powershell script rewrites to be done incrementally in IT’s spare time. This translated into a significant lowering of costs, and reduction in the risk of a “big bang” rip and replace project.

Software: Adding Extensibility to Legacy Applications

A U.S.-based public company has a 30-plus-year history of providing a suite of electronic design automation (EDA) tools to their more than 5,000 customers worldwide. Its suite of tools historically was built in C++ and is packaged for deployment on-premises.

Because each customer has their own instance, it’s natural for the customer to want to customize the suite of tools to their needs. The U.S. public company used Python to wrap some of its C++ APIs to expose key functionality, making their software solutions more extensible by customers. Ensuring Python was deployed properly at customer sites required including Python within their existing installer, rather than relying on their customers to install Python correctly.

The company used an OEM distribution Python that added a standard version of Python within their application and deployed it, so all teams can customize and leverage the EDA tools as required. Plus, by deploying a standardized Python version across all customer sites and developer desktops, the company can decrease support costs and speed time to market by eliminating the need for legal department reviews. Further, using a third-party-standardized Python version eliminates the opportunity cost of managing one’s own Python build and can facilitate the discovery of issues, bugs and performance issues.

Hardware: Automating Network Administration

A Silicon Valley-based American technology leader develops, manufactures and sells networking hardware. A key enterprise demographic for the company is network administrators, who often are confronted with managing the vendor’s multiple devices across extended corporate networks.

The challenge: Network admins aren’t typically developers. Yet, they want to improve their efficiency by being able to programmatically make configuration changes to multiple network devices at once. While sample scripts are easy for any network admin to use and modify, the vendor did not want to be held responsible for creating all the scripts its user base might require.

Python was the solution because it is simple enough for any technical person to learn and start using effectively. The company chose a version of Python that allows their customers to quickly create sample Python scripts to cover the majority of typical network admin use cases.

This choice also allows network admins to create Python libraries they can leverage to create their own custom scripts to manipulate the configuration, operational state or event data from network devices. Most importantly, the cost of administering enterprise networks is significantly lowered and network admins are dramatically more efficient with programmatic access to physical networking devices and virtual network resources.

Looking Outside the Tech Space

Other examples that round out the top 10 use cases for Python include:
- Consulting services: Bespoke web development.
- Insurance: Creating business insights with machine learning.
- Finance: Data mining to identify cross-sell opportunities.
- Retail banking: Flexible data transformation and manipulation.
- Aerospace: Meeting software system deadlines.
- Business services: API access to financial information.
- Health Care: Predicting disease prognosis.
Ongoing Innovation

Python’s usage continues to grow due to its simplicity and flexibility. Developers clearly want to use it for a variety of reasons that surpass its creator’s original intent. To support this usage, organizations need to ensure their developers can do so securely, by overcoming open source vulnerabilities while still iterating quickly. It seems that use cases for Python are limited only to the imaginations of its growing, enthusiastic user base.

— Bart Copeland
April 18, 2019