• United States



john_mello jr

Open-source software risks persist, according to new reports

Jun 23, 20223 mins
Application SecurityDevSecOpsOpen Source

Companies are still struggling to gain confidence in the security of their open-source projects, but shifting security earlier in the development process shows promise.

noops code developer devops html web developer by mazimusnd getty
Credit: Maximusnd / Getty Images

Open-source software (OSS) has become a mainstay of most applications, but it has also created security challenges for developers and security teams, challenges that may be overcome by the growing “shift left” movement, according to two studies released this week.

More than four out of five organizations (41%) don’t have high confidence in their open-source security, researchers at Snyk, a developer security company, and The Linux Foundation reveal in their The State of Open Source Security report.

It also notes that the time to fix vulnerabilities in open-source projects has steadily increased over the last three years, more than doubling from 49 days in 2018 to 110 days in 2021.

The open-source debate: Productivity vs security

The report, based on survey of more than 550 respondents, also notes that the average application development project has 49 vulnerabilities and 80 direct dependencies where a project calls open-source code. What’s more, the report found that less than half of organizations (49%) have a security policy for OSS development or usage. That number is worse for medium- to large-sized companies: 27%.

“Software developers today have their own supply chains,” Snyk Director of Developer Relations Matt Jarvis explains in a statement. “Instead of assembling car parts, they are assembling code by patching together existing open-source components with their unique code. While this leads to increased productivity and innovation, it has also created significant security concerns.”

Shifting security left reveals vulnerabilities sooner

Another survey—the AppSec Shift Left Progress Report—suggests better OSS security can be achieved by moving security “left” or closer to the beginning of the software development lifecycle. The report, based on the users’ experience of ShiftLeft’s Core product, found that 76% of new vulnerabilities were fixed within two sprints.

One reason vulnerabilities are fixed so fast is because they’re found fast. “Every change in code that a developer makes is scanned in a median of 90 seconds,” says ShiftLeft CEO and co-founder Manish Gupta. “Because the code is still fresh in a developer’s mind, it becomes easier for them to fix the vulnerability.”

The report acknowledged that improvements in its software weren’t the only reason for improved scan times. “We saw the average size of applications in terms of lines of code go down,” it notes. “This aligns with more organizations moving to microservices and smaller, more modular applications.”

Increased scanning for vulnerabilities

ShiftLeft’s customers also saw a decline in the number of OSS vulnerabilities that they needed to address in their applications by 97% because adversaries could exploit only 3% of those vulnerabilities. When analyzing OSS vulnerabilities, Gupta notes, it’s not how many vulnerabilities an application has, but where are they exploitable by a bad guy.

ShiftLeft also reported that its customers improved the mean time needed to mitigate vulnerabilities by 37%, down to 12 days in 2022 from 19 days in 2021. It attributed the decline to developers and security teams performing more scans earlier in the development process. “Some of our customers are doing as many as 30,000 scans a month,” says Gupta.

Is the vulnerability actually exploitable?

The report raises the question, “Is the vulnerability actually reachable by an attacker?” This is important when tackling zero-day flaws such as Log4J, which some organizations are still coping with months after its discovery in December 2021. It says that 96% of Log4J in use in its customers’ applications was not at risk of attack.

Remediating vulnerabilities that aren’t exploitable will have zero impact on risk. Deprioritize it and focus on others.