Software supply chain security risks analyzed

Supply Security

A report analyzing more than 100 million alerts, tens of thousands of code repositories, and 140,000 real-world applications has found that 95% of organizations have at least one high, critical, or apocalyptic risk within their software supply chain. The data was normalized using the Open Software Supply Chain Attack Reference (OSC&R) framework, developed in collaboration with experts from Google, Microsoft, and GitLab. On average, each organization has nine such issues, with one in five applications exhibiting a run-time exposure.

The three most frequently observed vulnerabilities are command injection (15%), sensitive data in log files (12%), and cross-site scripting (11%). Six of the top ten observed vulnerabilities are tied to poor implementation of fundamental security practices such as authentication, encryption, exploitable information in logs, and over-provisioned privileges. More than a third (36%) of applications were vulnerable to exploits in the initial access attack stage, while 20% were also vulnerable to either Persistence or Execution exploits.

A total of 12% contained vulnerabilities tied to tactics in all three stages. The most common attack techniques discovered include backdoors into code (31%), over-privileged user accounts (29%), and command injection (27%). The challenge is that on average, application security teams are monitoring 129 applications, with more than 119,000 security alerts being generated annually.

Analyzing software vulnerabilities in supply chains

Katie Teitler-Santullo, security strategist at OX Security, said the only way to cope with that number of alerts is to rely more on contextual analysis, which OX Security claims can reduce the volume of overall alerts by more than 97%. At the core of this capability is a proprietary OSC&R framework that provides a model through which risks can be easily identified by identifying potential attack paths.

Armed with these insights, it becomes simpler for DevSecOps teams to prioritize remediation efforts, noted Teitler-Santullo. While much progress has been made in improving software supply chains, it’s clear there is still much work to be done. Developers today typically only spend a fraction of their time remediating vulnerabilities, so DevSecOps teams need to ensure those efforts are focused on the issues that represent the greatest potential risk to the organization.

The biggest challenge, however, is getting application developers to buy into the DevSecOps process. Most developers resist approaches that take time away from building new applications, making it incumbent on DevSecOps teams to address application security issues in ways that don’t adversely impact developer productivity. In the meantime, growing regulatory requirements will necessitate that organizations revisit DevSecOps workflows, for example, by addressing known vulnerabilities in a timelier manner.

Automation will be key to ensuring that the code running in a production environment is as secure as possible.