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.
.ai-rotate {position: relative;}
.ai-rotate-hidden {visibility: hidden;}
.ai-rotate-hidden-2 {position: absolute; top: 0; left: 0; width: 100%; height: 100%;}
.ai-list-data, .ai-ip-data, .ai-filter-check, .ai-fallback, .ai-list-block, .ai-list-block-ip, .ai-list-block-filter {visibility: hidden; position: absolute; width: 50%; height: 1px; top: -1000px; z-index: -9999; margin: 0px!important;}
.ai-list-data, .ai-ip-data, .ai-filter-check, .ai-fallback {min-width: 1px;}
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.
This post was originally published on the 3rd party site mentioned in the title of this this site