4 Operational Risks to Not Leave to Chance

By JFrog Team September 1, 2022

5 min read

Not all of the recognizable risks in your software supply chain can be identified by their known vulnerabilities recorded as CVEs. A component that is outdated or inactive may present risks to your application that no one has had cause to investigate. Yet these components could still harbor threats.

Security teams and developers must also be able to identify and evaluate operational risks from components — open source software that doesn’t have a recorded CVE but can still endanger your organization.

Top 4 Operational Risk Factors

To fully protect your software supply chain, you’ll need to consider these top four operational open source risk factors when using open source components:

End of Life

If a component’s author has declared that it’s reached its end-of-life, then the risk is high and you shouldn’t be putting it to work.

The same rule applies if the component is known to be obsolete. While the open source software might still get the job done you need it to, its intentional neglect means that it’s no longer being actively monitored for vulnerabilities. And even if any security holes are discovered, no new version to fix it will be released.

Version Age

Older code tends to be less secure. Not only is an older component – even when it’s the latest version available – not going to have improvements for you to take advantage of, its own dependencies might be older components that are just as risky.

The older the code, the greater the risk. At JFrog, we consider any version older than 10 months but newer than 20 months to be a low risk, while versions a bit older than 3 years (40 months) are deemed high risk.

Version Currency

With some exceptions, you should always be trying to use the latest version of any component, to take advantage of all the newest improvements. This also helps avoid recognized vulnerabilities in an earlier, unremediated release.

A component version that’s only one or two releases behind – as long as it’s recent enough – is no real risk. Any more outdated than that, however, the risk rises proportionally. A component that has four versions newer than what’s used is considered medium risk, while being six or more versions behind is a high risk.

Project Health

A healthy open source project comes from a healthy community, as will be indicated by a high level of activity from several contributors. An infrequently updated component that is maintained by a single person isn’t likely to be benefiting from the same degree of improvement, oversight, or vigilance. Worse still is a project that has been seemingly abandoned.

Open source software projects rely on an active, engaged community of developers committed to using and improving them. The Kubernetes project, for example, has over 3,100 contributors helping produce three dot releases a year along with dozens of patch releases.

These are the chief indicators that you should consider when evaluating the health of a project:

Release cadence – A minimally healthy project should produce at least 2 GA releases (dot or patch) each year. A project with only a single release – or worse, no releases – each year should be considered unhealthy.

Commit frequency – A healthy project should have more than 100 commits in the last 12 months. Fewer than that should be considered unhealthy.

Yearly Contributors – The project should have commits from at least 5 different contributors in the last 12 months to be considered minimally healthy. Any fewer is an unhealthy number.

Improve Your Odds

Detecting these operational risks in your software supply chain should be a part of your DevSeOps practices. Along with identifying known vulnerabilities and ensuring license policy compliance, screening for these operational risks in your software bill of materials (SBOM) helps complete a comprehensive security posture.

JFrog Xray’s software component analysis (SCA) helps make doing so easy. Along with your security and license policies, you can configure operational risk policies to specify what to look for.