The Software Supply Chain Risks You Need to Know

Code that an organization's developers create is only the beginning of modern software development. In fact, first-party code is likely to be only a small proportion of an application - sometimes as little as 10% of the application's artifact ecosystem.

An enterprise's software supply chain is made of many parts, from many sources: open source packages, commercial software, infrastructure-as-code (IaC) files, and more. That diversity means that the supply chain you need to secure has many, many points of risk, and a wide surface area for security threats due to mistakes, oversights, poor quality, or malicious attack.

The 4 Key Software Supply Chain Risk Trends

Understanding where these vulnerable points are is important to securing your software supply chain. But addressing them one-by-one with point solutions is like playing whack-a-mole - a smashed threat can just appear somewhere else where you're not looking for it.

Fully securing your supply chain from threats requires vigilance from end to end, starting before a developer's first build, throughout your pipeline to release and distribution, and even after deployment. Beyond merely revealing vulnerabilities, you'll also need to know their context to be able to judge the true risk.

Let's examine four types of risk that threaten to make your software supply chain vulnerable to attack:

Known Vulnerabilities

Components from third parties - such as open source and commercial software - can come with unintended vulnerabilities, many of which are known and publicly tracked in the Common Vulnerabilities and Exposure(CVE) list.

You can protect against these risks with a Software Component Analysis(SCA) solution that identifies dependencies in code and components in images that are known to be vulnerable.

But you'll also need to have sufficient information to be able to make and automate risk-based decisions. An extended database is a must - one that not only tracks more risks, but includes in-depth security researchthat can help you to know all your options for mitigating those risks, so you can choose the most practical and cost-effective method.

Equally important is contextual analysisthat identifies how likely a vulnerability is to be exploited. For example, the vulnerable function in a component may not be used by the application, or a vulnerable process is never run in a production version.

You can also recognize likely operational risksfrom components that appear to be safe. For example, an open source package that hasn't been maintained for a while may not have been sufficiently monitored for security issues. In these cases, vulnerabilities aren't certain, but a potential threat can be anticipated.

These known and anticipated risks can and should be discovered at the points of:

• Source code- Shifting left security vigilance to the time when code is created can save costs of later remediation. Security teams can curate an internal repository of approved 3rd party components, and/or developers can be alert to vulnerable dependencies through extensions to their IDE. While inherently incomplete, this approach can help avoid known risks.
• Binaries - Automated SCA scanning of all packages, builds, and images in key binary repositories (both first- and third-party components) ensures that your entire software supply chain is protected against known vulnerabilities and operational risks. As the most accurate representation of the production state of your application, binaries enable the highest quality real-world analysis of risks.

Unknown Vulnerabilities ("Zero-Days")

Mistakes are an everyday part of coding. Logic flaws, poor encryption, and potential memory corruptions unintentionally make applications vulnerable to malicious attacks such as remote code execution and denial-of-service (DoS). These errors can lurk undetected in both first- and third-party code, sometimes for years before being recognized.

These are known as "zero day" issues, in part for the length of time they have been known - but also because their urgency means teams have zero days to fix them in already-deployed software.

To catch and prevent potential zero day issues, you must test each component and/or application, taking into account the flow between different binaries, processes and services. Static code analysis (to review code source) and dynamic code review (to test running code) tools can each typically identify about 85% of flaws, but expertise is required to interpret results. Just as with known issues, a vulnerability may not be exploitable.

More advanced technologies that combines symbolic execution, data flow analysis and automated fuzzing can reduce the false positive ration dramatically and identify vulnerabilities that cannot be found by typical SAST/DAST. Combining analysis of both source and binaries can also produce better results and help developers, security teams, and production managers focus on fixing what matters.

Despite best efforts, vulnerabilities will be discovered that impact deployed software. Continuous SCA scanning can help ensure swift notification of any late-breaking CVEs that affect production software. And a rich body of Software Bill of Materialsmetadata enables you to quickly know the full impact of a vulnerability to your organization, and to mitigate or remediate across your entire application inventory.

Non-Code Issues

Not all vulnerabilities lie in your code - they can be found within binaries and in supporting artifacts such as configuration or IaC files. Misconfigurations, poor encryption, exposure of secrets and private keys, or operating system issues can open up an attack surface.

These byproducts of human error are typically due to a lack of attention rather than malice, and are usually introduced outside of the hot spotlight of major development. Configurations thrown together for testing can be thoughtlessly promoted to production. These risks are often easy to fix - but hard to catch and harder to recover from.

Even a benign intent can lead to malicious consequences. Most notoriously, the SolarWinds breachbegan with a password exposed on a public GitHub server, enabling a malicious code injection that ultimately exposed sensitive government data. Dependency confusionbetween similarly named packages can also happen without malice, especially when package repository resolutionis poorly configured.

It's vital to catch these issues early, before they advance to production. You'll need to take these potential risks at least as seriously as vulnerabilities in your code, and integrate this vigilance into the end-to-end security posture of your pipelines.

Malicious Code

Intentional threats, whether from external injection attacks or malicious insiders, can be the most difficult to find, since they are often masked to appear as an already validated component. Viruses, bots, ransomware, and spyware are often enabled by the more benignly introduced vulnerability types we've already discussed. Seeding popular repositories with harmful packages, hacking into maintainer's accounts to alter existing packages, or injecting code into compromised source repositories are frequently used methods of enabling backdoor access for an attack.

Finding these attacks after deployment is typically too late - the damage has been done, and it can be very, very costly. So you should protect against them throughout your pipeline:

• Access control - Internal package repositories must limit write access to key roles and team members through permissions and secure authentication (including multi-factor authentication) that's consistent across the organization.
• Proxy repositories- Caching external repositories (such as Maven Central and npm) can provide an immutable snapshot of third-party resources, so any subsequent malicious overwrite will be immediately evident.
• Testing and analysis - Sophisticated static and dynamic analysis tools can detect and flag malicious code. The JFrog security research team has uncovered and disclosed over 1300 malicious packages in public package repositories through tools it has developed.

End-to-End Vigilance

While some of these risk trends can be addressed one at a time, point solutions are merely alarm systems - and only helpful where you think to place them.

For much the same reason, separate security-only solutions are of limited help as well, since their limited scope cannot help you to analyze and judge the full context of a risk within the entire software supply chain.

A comprehensive security posture can't just focus on isolated points in your pipeline, it must enable you to connect the dots between different issues and security findings - something that separate niche solutions can't do.

Software security requires end-to-end vigilance, enforcing consistent risk oversight and enabling mitigation in both development and production environments. Your security solutions must act holistically on your software supply chain, and enable you to take action on a large scale. To secure consistently across your organization, it must operate against a single source of truth for all of your binaries, and be deeply integrated with your DevOps tools.

Want to learn about "what's next" from JFrog that will help meet these needs? Register for one of the swampUP City Tourevents coming soon near you!

Public link

Please use the above public link if you want to share this noodl on another website.