Cloud-native deployments are often short, interchangeable, and simpler to guard, but their software supply chains need closer attention.
The foremost reason that businesses leverage open source software is to boost development. Developing an application entirely from scratch is extremely rare. Therefore, an estimated 99% of codebases include open source elements, and up to 70% of enterprise code is presently based on open source. Developers are merging ready-made components with custom code to accomplish the desired result without reinventing the wheel.
According to Risk Sense, vulnerabilities in leading open-source software unveils that their total number more than doubled from 421 common vulnerabilities and exposures (CVEs) to 968 between 2018 and 2019. Moreover, GitHub stated that 17% of software bugs were inserted deliberately by malicious leads.
Developers surveyed by the Linux Foundation reported that on average, only 2.27% of their time is spent on security bugs, leaving companies with knowledge of the risk but no direct method to resolve it.
However, vulnerabilities represent a possible risk that can only be used when the vulnerable component is being used, unpatched without compensating powers. To boost their possibilities of success, attackers have adapted poisoning open-source projects with outright malware. This was designed to be included in the software supply chain and performed alongside the application code.
Companies aiming to reduce these risks must start with gaining visibility and control over externally sourced software. Vulnerability scanners can aid in controlling the risks of security bugs in open source components. These tools should include automation, prioritization, actionable advice, and metrics to measure how vulnerabilities are remediated over time. Automation is critical because relying on manual assessment and remediation processes is lengthy, and a lot of developers lack the knowledge to prioritize the threats and address them.
Packages, entire container pictures, and ready-made modules can be the product of attackers attempting to enter and inject malicious code into applications. Worst-case scenario example is a misconfigured container picture with a default user of the root, made on a base image comprising a backdoor and deployed in a cloud environment with open networking.
Hence, to prevent such scenarios, businesses should scrutinize their entire supply chain, including how software enters the organization, from where, and by whom. There must be precise guidelines on the quality and reputation of open-source software. Also, projects with recent commits, interested contributors, and good governance should be preferred.
Incoming software should be inspected for vulnerabilities and analyzed while operating in a sandbox environment before being used. This will help expose malicious code that was inserted intentionally and will only be detectable on execution.
Several information security practices were established when development and operations were relatively trusted, but long-running servers were challenging to protect. In the current environment, the state of security is reversed, and the supply chains require more attention than ever.