devopsy.kinsta.cloud

Tag: Software Supply Chain

Checkmarx Surfaces Malicious Effort to Compromise Software Supply Chains

Checkmarx, this week, reported it has discovered malicious software packages that, in addition to injecting malware capable of bypassing endpoint security to exfiltrate data, also provide persistent remote access and control of desktops and servers.

Darren Meyer, security research advocate at Checkmarx, said the attack appears to be targeting applications developers using Colorama, a widely-used Python package for colorizing terminal output and a similar JavaScript package on NPM. These malicious packages were uploaded to the PyPI repository.

The goal is to use typo-squatting and name-confusion to trick application developers into downloading these packages as part of an effort to compromise software supply chains, said Meyer.

However, the malicious packages have since been removed from the PyPl repository for unknown reasons, so they may have been created to target a specific organization, he added. Checkmarx researchers were also able to track the development of these malicious packages back to a specific account on the GitHub repository.

Regardless of motivation, these malicious packages are the latest example of increasingly sophisticated attacks being launched against software supply chains, noted Meyer. Rather than simply trying to steal data, it’s apparent that cybercriminals are looking to gain more persistent footholds in application development environments.

The approach not only makes it possible to continually steal data as code is developed, but it also creates an opportunity to further distribute malware into downstream applications before they are deployed in production environments.

The challenge is that efforts to secure software supply chains remain a work in progress. A survey from The Futurum Group, for example, finds that only 16% of respondents feel their organization has achieved a tight partnership based on shared goals across their application development and cybersecurity teams.

On the plus side, a similar Checkmarx survey finds that more application security resources are shifting toward the teams that build and deploy software, versus being the sole responsibility of a centralized cybersecurity organization.

As application security increasingly becomes a shared responsibility, more care will be exercised over what software packages are allowed to be downloaded. Even then, DevSecOps teams will still need to continuously scan any third-party code that is being incorporated into downstream applications, especially if it has been downloaded from any type of public repository.

In the meantime, DevSecOps teams should assume that tactics and techniques used to compromise software supply chains are only going to continue to become more lethal. In terms of rich targets, cybercriminals have clearly put application developers and software engineers at the top of their lists. Many of them are counting on the fact that far too many application developers continue to routinely download code from public repositories without appreciating cybersecurity implications.

Short of prohibiting access to these public repositories altogether, the only viable option continues to be a mix of training augmented by tools that will hopefully identify security issues as far left into the software development lifecycle as possible. After all, the one certain thing is that the longer a threat is allowed to persist, the more damage there will be inflicted.

May 29, 2025
Endor Labs Extends Microsoft SCA Alliance to GitHub

Endor Labs has allied with GitHub to integrate its software composition analysis (SCA) tools directly within DevOps workflows.

In addition, two companies are now making it possible for DevOps teams to acquire the Endor Labs SCA tools via their GitHub Advanced Security and Dependabot software dependency management subscriptions.

Endor Labs CEO Varun Badhwar said this integration will make it simpler for application development teams to discover and remediate vulnerabilities within the context of a GitHub Actions workflow.

At the same time, that level of integration will also streamline vulnerability management by, for example, making it simpler to determine whether a vulnerable function can actually be reached by a cyberattack, said Badhwar. That’s critical because too many application developers today are wasting time tracking down vulnerabilities discovered by a cybersecurity team that doesn’t represent an actual threat to the organization, he added.

As more applications are developed using artificial intelligence (AI) tools, that volume of code that might contain vulnerabilities will overwhelm DevSecOps teams unless an effort is made to prevent them from ever being created, noted Badhwar.

Previously, Microsoft, the parent company of GitHub, integrated the SCA tools from Endor Labs into Microsoft Cloud Defender, a cloud-native application protection platform (CNAPP). The alliance with GitHub extends the reach of the SCA tools further left, to enable DevOps teams to eliminate vulnerable code before it ever finds its way into a production environment. That approach should make it simpler for application developers to discover and remediate vulnerabilities as they are writing code.

While a lot of DevSecOps progress has been made of late, there is clearly still a long way to go before software supply chains can be considered secure. In general, developers still don’t allocate enough time to creating patches for applications that have already been deployed and the time that is allocated is often spent fixing the simplest vulnerabilities rather than ones that are potentially the most lethal.

At the same time, cybersecurity teams tend to create lists of vulnerabilities without providing any context. Application developers then have to spend time determining whether the vulnerability being highlighted by the cybersecurity team is present in the application environment. As the number of times that investigation turns out to be fruitless, the more inured to vulnerability remediation requests the DevOps team tends to become.

Unfortunately, that lack of cohesion too often results in a known vulnerability not being addressed in a timely enough fashion. The truth is that cybercriminals are counting on the fact that organizational inertia will create plenty of opportunities for them to exploit.

The one certain thing is the application security expectations of organizations that consume are rising. As such, application development teams are being held accountable for the number of vulnerabilities that for one reason or another still find their way into a production environment. The challenge and opportunity now is to leverage SCA tools to eliminate as many vulnerabilities as possible from ever being created in the first place.

February 21, 2025
North Korea’s Lazarus Group Targets Developers, Supply Chain

North Korea’s notorious Lazarus Group is using an advanced malicious implant to target cryptocurrency wallets and spreading it via legitimate GitHub profile and possibly through npm packages.

The ongoing campaign, dubbed Operation Marstech Mayhem, is the example of a threat group using open-source code repositories like GitHub, npm, and Python Package Index (PyPI) in software supply chain attacks to spread their malicious code, hoping that developers will inadvertently include it in their software and spread it to downstream users.

It also “exposes a critical evolution in the Lazarus Group’s supply chain attacks, demonstrating not only their commitment to operational stealth but also significant adaptability in implant development,” according to researchers with SecurityScorecard, who have been tracking the campaign over the past few months.

The JavaScript malware includes multiple obfuscation techniques and a novel command-and-control (C2) that operates on unusual ports and is hosting unique Node.js Express backends, which is a break from previous similar Lazarus campaigns like Operation 99 and Phantom Circuit.

An Evolutionary Step for Lazarus

SecurityScorecard researchers last month wrote about Operation 99, a fake recruitment scheme aimed at developers looking for freelance jobs in the crypto and Web3 sector. Operation Marsetch Mayhem is a step beyond, they wrote in a report.

“This divergence in operational methodology not only complicates detection but also suggests that the Lazarus Group is continuously refining their techniques to exploit vulnerabilities in modern software supply chains, including the targeting of cryptocurrency wallets and tampering with browser extension configurations,” they wrote.

The latest version of the implant is Marstech1, which the researchers wrote was embedded in the code of a GitHub repository associated with a profile called “SuccessFriend,” which they believe is Lazarus Group’s profile and is known to create both legitimate and malicious software.

At the same time, they suspect the threat group also is spreading the malware through genuine npm packages that are aimed, again, at project developers in the crypto and Web3 sector.

A New, Ongoing Threat

The Marstech1 implant first emerged in late December 2024 from a C2 server hosted in Stark Industries. It also cropped again last month, with SecurityScorecard calling “limited targeted attacks on the supply; it has not surfaced elsewhere” since the two occurrences. It has claimed almost 240 victims in the United States and elsewhere.

Marstech1 searches Chromium-based browser directories and multiple operating systems to modify browser configuration files, most importantly the MetaMask extension that is popular for crypto wallets. It then looks for Exodus and Atomic Crypto wallets on Linux, macOS, and Windows systems. The implant will steal sensitive data from target directories and crypto.

Such campaigns are common with Lazarus Group and other threats actors backed by the North Korean government, which uses the month to bypass international sanctions and finance its nuclear and other weapons programs. According to blockchain analysis company Chainalysis, North Korea-based threat groups stole $1.34 billion in crypto last year.

Obfuscation and Evasion

To evade detection when embedded into a software project, Marstech1 includes a number of obfuscation techniques, including Base64 string encoding, random variable and function names, control flow flattening and self-invoking functions, and splitting and recombining strings.

To further avoid static and dynamic analysis, Marstech1 uses a two-step process that includes Base85 encoding and XOR decryption.

The researchers also wrote about anti-analysis code that “employs one-time execution wrappers and console hijacking techniques to complicate both static and dynamic analysis. The one-time wrappers allow critical functions to run only once, immediately nulling the callback afterward so that subsequent calls yield no effect. This prevents analysts from repeatedly invoking or modifying key functions during debugging or automated analysis. Additionally, a self-referential check examines the function’s own string representation, a tactic intended to detect tampering or reverse engineering attempts.”

Operation Marstech Mayhem should serve as a “stark reminder that the landscape of cyber threats is rapidly evolving,” they wrote, adding that the integration of the implant in legitimate GitHub repositories and their “subsequent embedding in trusted software packages [pose] a significant risk to both developers and end-users alike.”

Given the advanced anti-bugging defense and self-modifying code used with Marstech1 that looks to thwart real-time analysis, developers and organizations need to become even more vigilant against malicious behaviors and develop security frameworks for supply chain management, the researchers wrote.

February 17, 2025
Proactive Dependency Management: Reducing Risk and Improving Software Quality
In modern software development, open-source components or dependencies are fundamental to rapid innovation. Developers typically choose these components based on personal experience, research or guidance from technical leads. However, once integrated, these dependencies often recede into the background.

Over time, these dependencies can accumulate technical debt, turning into neglected assets that may introduce bugs or security vulnerabilities.

Proactive dependency management is crucial for maintaining secure, high-quality software. I recently discussed this topic at All Day DevOps (ADDO) 2024. Read further to learn more about common pitfalls, key statistics and best practices to stay ahead of potential issues.

The Hidden Cost of Neglected Dependencies

While software dependencies play a vital role in modern applications, they can also introduce significant risks if not managed proactively.

Here are some key statistics that illustrate the impact of neglecting dependency management:
- Each application has six to 10 direct dependencies, which balloon to 180 total dependencies when accounting for transitive dependencies.
- 80% of application dependencies go un-upgraded for over a year, exposing software to bugs and security vulnerabilities.
- Each project releases an average of 15 new versions per year, and developers spend about two hours on each dependency version upgrade.
- This adds up to 300 hours per application per year — a significant investment of time that could be reduced with better automation and management
Vulnerabilities Lurking in Outdated Dependencies

One of the most critical issues with unaddressed dependencies is their potential to introduce security vulnerabilities.

Even when fixes are available, many organizations fail to update their dependencies on time. A full 96% of vulnerable releases downloaded had a fixed version available.

The notorious Log4Shell vulnerability of the Log4j component is a prime example. Despite the well-publicized risk and the availability of patches, 13% of Log4j downloads in 2024 are still vulnerable versions.

This statistic underscores the importance of staying vigilant about dependency updates, especially with critical components that could expose applications to significant risks.

Automating Dependency Management for Reliability and Security

Proactive dependency management can be a daunting task, but automation offers a solution. Automated systems can monitor dependencies and flag updates, helping teams stay ahead of vulnerabilities and ensure compatibility.

However, not all automation is equal. To be effective, automated solutions must take into account API compatibility to prevent broken builds and reduce upgrade time. Without this, a typical two-hour upgrade can balloon, disrupting other priority work.

Another valuable input to automate solutions is the popularity of open-source components. Popular components exhibit 63% more identified vulnerabilities but also address 54% more and resolve them 32% faster than less-known components. While popular projects undergo more rigorous scrutiny, they typically make updates more accessible, which becomes incredibly powerful when those updates can be integrated through automation.

The Impact of Transitive Dependencies

One of the most challenging aspects of dependency management is the ripple effect that changes made to direct dependencies can have on transitive dependencies.

Managing only 10 direct dependencies can impact up to 170 transitive ones, forming a complex web of interconnected components that require vigilant monitoring and updates. Overlooking this intricacy can lead to significant issues, such as build failures, bugs and security vulnerabilities.

For this reason, automating dependency management is essential for reducing the risk of unexpected failures. Automated tools that provide visibility into the full dependency graph enable developers to assess the impact of updates and take action before problems arise.

Best Practices for Proactive Dependency Management

A key takeaway from the presentation is that proactive dependency management is not just about staying on top of updates — it is about creating a strategy that minimizes risk while improving software quality.

Here are a few best practices that can help:
- Automate dependency updates: Leverage automation tools to track and update dependencies across your applications. By automating routine updates, you can reduce the manual workload on your team and minimize the risk of vulnerabilities.
- Monitor for vulnerabilities: Regularly scan your dependencies for known vulnerabilities and ensure that you are updating to secure versions as soon as they become available. This is especially important for popular open-source components, which are frequently targeted by attackers.
- Assess API compatibility: Ensure that your automation tools account for API compatibility to avoid broken builds and wasted time. This will help keep your development process smooth and efficient.
- Focus on transitive dependencies: Don’t just manage your direct dependencies — make sure to monitor the transitive dependencies that they introduce into your These hidden dependencies can often be the source of critical issues if left unmanaged.
Staying Ahead of Technical Debt and Security Risks

Ignoring your dependencies is not an option. The statistics presented show the consequences of failing to manage dependencies proactively. By adopting best practices and embracing automation, you can reduce technical debt, improve software quality and avoid costly security breaches.

Managing dependencies isn’t just best practice, it is an essential ongoing process. Implement these strategies in your projects to stay ahead of potential issues and ensure your software remains reliable, secure and up to date.
November 13, 2024
Learning From SpaceX: How the Space Industry’s Transformation can Inspire DevOps in Software Development

In recent years, the space industry, much like software development, has experienced rapid transformation. SpaceX has revolutionized space launches with its use of reusable rockets and innovative suppliers.

These advancements, among others, provide invaluable insights for software engineers and DevOps teams.

I recently delivered a presentation at All Day DevOps (ADDO) in October 2024 that highlighted how software teams can adopt practices from SpaceX’s journey to improve efficiency, innovate faster and manage risk more effectively.

From Monolithic to Modular: Lessons From Satellites and Microservices

The evolution of satellite technology provides an interesting parallel to the shift in software architecture. Historically, satellites were large, monolithic structures with multiple sensors and functions, much like traditional monolithic software applications.

This approach worked for a time but wasn’t scalable or efficient in the long run.

The introduction of CubeSats — small, modular satellites designed for a single function and built using commercial off-the-shelf (COTS) components — mirrored the move toward microservices in software development. These smaller satellites were cheaper to build, easier to launch and allowed for more rapid innovation.

Similarly, microservices enable development teams to break down applications into smaller, manageable components. This architectural style allows teams to work on individual modules independently, facilitating faster iteration and reducing the risk of errors. By isolating functionalities, developers can update or modify components without impacting the entire system, leading to more efficient and agile project management.

Balancing Speed and Safety: SpaceX’s Approach to Risk Management

SpaceX’s development process is yet another source of inspiration for software teams. The company’s engineers adopted a DevOps-like approach, breaking down large government projects into smaller, more manageable components and commercializing them quickly.

SpaceX embraced failure, understanding that it was an integral part of its rapid innovation process. They experienced several high-profile setbacks, each one serving as a valuable learning opportunity, paving the way for greater success. Notably, though they also achieved manned launches, proving their transition from rapid innovation to stable deployment.

For DevOps teams, this approach highlights the importance of embracing a ‘fail fast, learn fast’ mentality. However, not all failures are equal. It is critical to manage where failures happen, their impact, and what is learned from them. In software development, this could mean using automated testing and staging environments to catch issues early, rather than allowing them to affect production systems.

Automation and Data: The Key to Scaling Innovation

SpaceX’s rapid pace and secure operations are grounded in automation and dependable data. Their rockets continuously gather health and status information, aiding in anomaly resolution during and post-missions. This enables swift iteration and design enhancements.

Similarly, for DevOps teams, automation is essential for maintaining speed without sacrificing security. In the fast-paced world of software development, teams rely on automation to streamline processes, reduce manual errors and enhance efficiency.

Reliable data, particularly via software bills of materials (SBOMs), plays a crucial role by allowing teams to meticulously track components throughout the entire software development life cycle. This ensures vulnerabilities are caught and addressed early, thus safeguarding the integrity of the software.

Automation without reliable data is useless, as it could lead to overlooked flaws and potential security risks, highlighting the need for robust data management alongside automated systems.

Lessons for DevSecOps: Integrating Security Into Development

One of the most important lessons from SpaceX’s journey is the integration of safety into every step of the process. For software teams, this means adopting a DevSecOps approach, where security is not an afterthought but an integral part of development.

Just as SpaceX had to meet strict safety standards for crewed space missions, software teams must apply appropriate security measures based on the specific risks of their applications.

It is essential to strike a balance between speed and security. Not all security measures need to be applied equally across the entire development life cycle.

Instead, focus on where they are most needed — near production systems and sensitive data. By using automation and security policies tailored to the application’s specific risks, teams can ensure both speed and safety.

Innovating Safely and Efficiently

SpaceX has proven that it is possible to innovate rapidly while maintaining safety and security.

By adopting similar practices in software development — breaking down projects into smaller components, embracing automation and integrating security throughout the lifecycle — DevOps teams can drive innovation without sacrificing quality or safety. We can move fast and yet remain secure; we just need to take the right approach in the right places at the right time.

By learning from the space industry’s transformation, software teams can chart a course toward faster, safer development practices that meet the demands of today’s fast-paced market.

October 24, 2024
Endor Labs Adds Analytics and Patching Tools to Secure Open Source Software

Endor Labs today at the Black Hat USA 2024 conference revealed it has added an ability to determine how challenging it might prove to be to upgrade an open source software package, including its potential to break an application, to its platform for securing software supply chains.

Additionally, the company is adding Endor Magic Patches to enable DevSecOps teams to apply patches created in a later release to a previous version of the module if they determine upgrading that module would be too difficult.

Jenn Gile, director of product marketing at Endor Labs, said these analytics capabilities will provide DevSecOps teams with the context needed to determine when to upgrade a module based on the potential level of disruption that a new module might introduce to an IT environment.

While existing software composition analysis (SCA) tools are capable of identifying vulnerabilities, they lack the critical remediation advice organizations need to make a decision to upgrade, she added. Endor Labs, in contrast, is making use of analytics applied at the time a build is created to determine exactly which third-party dependencies are used and how they interact with the application code, noted Gile.

As a result, most organizations will opt to not upgrade a module on the assumption the risk level to the business is too high, she added.

Conversely, DevSecOps teams might decide to go forward with an upgrade only to discover the effort required was much greater than anticipated. It’s not uncommon for DevSecOps teams to roll back an upgrade after that level of difficulty is determined.

The latest capabilities added to the Endor Labs platform provide the actionable intelligence that DevSecOps teams working in collaboration with their cybersecurity colleagues need to make more informed upgrade decisions, said Gile.

If it is determined that upgrading a module is too challenging, DevSecOps teams then have the option to deploy source code and associated patches, including test, build and deploy steps, using Endor Magic Patches.

Open-source software security has become a major issue because organizations that rely on these applications that include open-source code can’t easily develop a patch any time a new vulnerability is discovered. In many cases, as in the case of the infamous Log4J shell vulnerability that impacted Java applications, IT teams will discover that the code impacted is being maintained by a small team of unpaid volunteers who lack the time or motivation to quickly develop a patch.

While the open source community is pooling resources to address that type of challenge going forward, many enterprise IT organizations are reevaluating their applications intending to become less dependent on open source software that isn’t being maintained by a large team of developers that are actively contributing to the project.

One way or another, however, there will most certainly come a time when a new zero-day vulnerability will be discovered that DevSecOps teams will need to instantly fix before cybercriminals exploit it. That’s especially critical in an era where the time between when a vulnerability is disclosed and the first attacks that exploit it is now measured in hours.

August 7, 2024
Survey Surfaces Troubling Signs of Software Supply Chain Insecurity

A global survey of 1,224 software engineering professionals working at organizations with more than 1,000 employees suggests a significant gap has emerged between what senior executives believe is being done to improve application security and what might actually be occurring.

Conducted by Atomik Research on behalf of JFrog, a provider of a DevSecOps platform, the survey finds that 67% of the 331 executives and managers surveyed believe code-level security scans are conducted regularly but only 41% of the developers concurred.

A full 88% of executives also said they believe artificial intelligence AI and machine learning tools are being used for security scanning and remediation processes. However, only 60% of DevSecOps teams reported they are actually using these tools. Just over 90% of executives also believe they are using machine learning models in their software applications, whereas only 63% of developers confirm that is true.

Similarly, 92% of executives claim their organizations possess tools to detect malicious open-source packages, while only 70% of developers agreed.

JFrog Field CISO Paul Davis said the disconnect between executives and rank-and-file developers most likely stems from the simple fact many organizations are still on the journey when it comes to re-engineering DevSecOps workflows. The challenge is each organization is starting that journey from a different place and as such they are progressing at different paces that are often difficult to quantify.

Making matters more challenging, however, is the fact that only 30% of all survey respondents identified the need to address vulnerabilities in their software supply chain as a top security concern. It’s not exactly apparent why less than a third of respondents are concerned about vulnerabilities despite their prevalence but the survey results suggest there is either a level of potential overconfidence or that other more pressing issues might be taking precedence.

Securing Software Supply Chains With or Without Regulation

It’s not clear how much influence regulations might have on spurring organizations to better secure their software supply chains. The European Union (EU), for example, is advancing the Cyber Resilience Act (CRA) that requires organizations to secure the software supply chain for any software that is sold, but other countries have yet to follow suit. In the absence of an actual regulation, it’s up to each organization to determine how best to secure its software supply chain against cyberattacks.

The most common form of those attacks typically involves stealing the credentials needed to access an application development environment. Once cybercriminals gain access, they will over an extended period attempt to embed malware into a workflow in the hopes that malware will find its way into multiple downstream applications. At the same time, cybercriminals are also targeting open-source software repositories by pretending to be interested contributors, before similarly injecting malware into a tool or software component that might be used by thousands of organizations.

Hopefully, advances in artificial intelligence (AI) will soon make it easier to identify and remediate these types of threats. In the meantime, however, the level of disconnect between developers and managers concerning what is being done to ensure software supply chains are secure is, at the very least, disconcerting.

July 19, 2024
Report Surfaces Thousands of Potential Vulnerabilities in GitHub Workflows

An analysis of 2.5 million GitHub Actions workflow files belonging to 553,000 organizations and personal users published today suggests many DevSecOps teams that use the GitHub continuous integration/continuous deliver (CI/CD) platform to build and deploy applications are relying on workflows that are often fundamentally insecure.

Published by Legit Security, a provider of a platform for managing application security posture, the report uncovered interpolation of untrusted input in more than 7,000 workflows; execution of untrusted code in over 2,500 workflows; and use of untrustworthy artifacts in 3,000-plus workflows.

Additionally, 98% of references used by jobs and steps do not follow the best practice of dependency pinning while 86% of workflows do not limit token permissions.

Many of the actions created by third parties that DevOps teams might reuse are also insecure, mainly because they have been created by small teams that lack cybersecurity expertise. Of the 19,113 custom GitHub Actions in the marketplace, only 913 were created by verified GitHub users, with 18% having vulnerable dependencies. A total of 762 are archived and do not receive regular updates.

Noam Dotan, a security researcher for Legit Security, said that it’s apparent there is still much work to be done securing software supply chains that cybercriminals are increasingly focused on compromising in hopes of injecting malware into multiple downstream applications. While there is not much a DevSecOps team can do about a vulnerability found in the core of a CI/CD platform, there is plenty of opportunity to remediate DevOps workflows at the application level, he added.

For example, many DevOps teams are employing workflows that have risky dependencies or provide overly permissive access privileges that create vulnerabilities that should be addressed before they are easily exploited, noted Dotan.

The Need to Make Software Supply Chains More Secure

GitHub, of course, is not the only CI/CD platform that has security issues. In the wake of a series of high-profile cyberattacks on software supply chains, security researchers more than ever are focused on uncovering vulnerabilities in DevOps tools, platforms and workflows. As more organizations embrace secure-by-design principles to build more secure applications, awareness of the need to make software supply chains more secure has risen sharply in recent years. The challenge is that given the sheer number of tools, platforms, pipelines and workflows that span a software supply chain the effort required to achieve that goal is gargantuan.

Unfortunately, cybercriminals have become more adept at, for example, stealing credentials that provide them with nearly unfettered access to application development environments. Once cybercriminals gain access it then becomes possible to, for example, embed malware in code bases that might not be activated until months later.

No developer wants to wake up one morning to discover a cyberattack has been traced back to a mistake they made. The trouble is that it’s too easy for developers to make a simple mistake that can have catastrophic consequences. It’s up to the DevSecOps teams to ensure that the software supply chain itself is as secure as possible. Otherwise, all the time and effort spent teaching developers how to write more secure code will likely to have been to no avail.

July 16, 2024
ReversingLabs Applies AI to Better Secure Application Binaries

ReversingLabs this week launched a binary analysis tool that uses machine learning algorithms to identify risks before and after applications are deployed.

Erik Thoen, vice president of product management for ReversingLabs, said Spectra Assure makes use of the same core artificial intelligence (AI) technologies the company uses to discover malware within binaries to analyze the entire software package, including first-, second- and third-party components, to identify potential threats.

Thanks to the use of AI, Spectra Assure is able to scan applications that are gigabytes in size in minutes or hours, depending on their complexity, noted Thoen.

That approach is critical because attacks launched against applications are more often aimed at binaries that are deployed in production applications rather than the source code used to create them, he added.

In addition, Spectra Assure can be applied to both open source and proprietary software, said Thoen. In contrast, many legacy scanning tools are designed to only surface potential issues in open source software, he noted.

Spectra Assure is designed to be used by both producers of software and the organizations that deploy software, said Thoen. Organizations that develop software need to be able to identify any security potential issues that may have arisen during the build process, while organizations that consume software need to be assured that there are no issues that will later compromise their IT environments, said Thoen.

ReversingLabs is attempting to fill a gap that exists in many software supply chains between when a software build is completed and deployed, said Thoen. While developers may scan source code for vulnerabilities, it’s not uncommon for changes to be made during the build process that inadvertently create vulnerabilities, said Thoen.

It’s still not clear which teams within organizations are assuming responsibility for the software supply chain. In many cases, DevSecOps teams are securing the software supply chain, but in other instances, cybersecurity teams have been tasked to lock them down. Among organizations that consume software, responsibility for application security might be assumed by either the cybersecurity teams or a procurement office responsible for purchasing software.

Regardless of how software supply chain security is managed, the number of attacks against them has risen sharply. A recent ReversingLabs report found there has been a 1,300% Increase in malicious packages found in open source software platforms since 2020.

Ultimately, it’s only a matter of time before more stringent regulations force the software supply chain security issue. A recent executive order issued by the Biden administration requiring federal agencies to secure software supply chains is a harbinger of stricter controls that enterprise IT organizations must implement. DevSecOps teams, in the meantime, have an opportunity to revisit the workflows that were created in an era where developers tended to overly trust the integrity of software components downloaded from open repositories.

Of course, it may require a catastrophic event to truly galvanize organizations into action, but one way or another, application security is going to improve. The only issue remaining to determine is how expensive a proposition that will be given the potential fines that are likely to be one day levied.

February 16, 2024
Veracode Report Shines Spotlight on Massive Application Security Debt

An analysis of more than a million applications published today by Veracode, a provider of a software supply chain security platform, found 42% of applications contained flaws that remained unfixed for longer than a year.

Based on 1,553,022 dynamic analysis scans and 11,429,365 static analysis scans, the report noted that those applications with that level of security debt were found in 71% of the organizations maintaining these applications. Nealy half of organizations (46%) have persistent, high-severity flaws that constitute ‘critical’ security debt. Approximately 63% of applications have flaws in first-party code, while 70% contain flaws in third-party code imported via third-party libraries.

Remediation rates also vary by flaw type. Fixing third-party flaws takes 50% longer, with half the known flaws fixed after 11 months, compared to seven months for first-party flaws.

Collectively, the scan run by Veracode produced 96 million raw static findings, four million raw dynamic findings and 12.2 million raw software composition analysis findings.

Chris Eng, chief research officer for Veracode, said it’s clear too many organizations are kicking application security flaws down the road only to find they don’t have the time to address them properly. Meanwhile, cybercriminal syndicates and nation-states are becoming more adept at exploiting these flaws with each passing day, he added.

In general, there is a lot more focus on software supply chain security in the wake of an executive order issued by the Biden administration that requires federal agencies to identify and remediate security flaws. However, the pace at which enterprise IT organizations are following the lead of the Federal government varies widely. Only a relatively small percentage of the vulnerabilities that exist in applications running in production environments are being exploited, so many enterprise IT teams have yet to prioritize the issue.

However, as more cybercriminals acquire the skills required to discover and exploit those vulnerabilities, it’s only a matter of time before a major application security crisis ensues, noted Eng.

Theoretically, at least, artificial intelligence (AI) should one day soon make it easier to discover and remediate vulnerabilities, but it’s just as likely cybercriminals will use the same capabilities to achieve their own nefarious ends. In fact, it’s largely a race against time before existing application flaws are exploited using AI-based tools and techniques. Application development teams that fix flaws the fastest reduce critical security debt by 75%, from 22% of applications to just over 5%, the Veracode report noted.

Naturally, it’s less costly and simpler to fix security flaws before applications are deployed in a production environment, so the more organizations embrace DevSecOps best practices on the front end, the lower the overall security debt becomes, noted Eng.

It’s not clear whether organizations might decide to replace or consolidate applications to reduce their security debt, but given the overall lack of cybersecurity expertise among application developers, the current level of security debt is likely to continue to rise. The challenge, of course, is that as the security debt rises, the number of developers available to address, unfortunately, remains comparatively constant.

February 14, 2024