In the DevOps and DevSecOps Introduction, What is DevOps, we reviewed how our security teams overlay onto DevOps for visibility and increased security throughout the software lifecycle. This article explores DevSecOps during the planning phase of the project and why it’s important for developers to be trained on how to help protect the software they are writing from Free Open-Source Software “FOSS” risks and supply chain attacks.
Development’s role in DevSecOps
Development teams that have an Agile culture will be familiar with DevOps frameworks and the ability to deal with rapid change effectively. As developers work through user stories, they may search for available FOSS that is useful and speeds up the user story delivery. DevSecOps collaboration with developers during this process helps protect user stories from the risks associated with using FOSS and supply chain attacks.
Free Open-Source Software “FOSS” risks
Arguably the most popular FOSS is the Linux operating system released in 1991 by Linus Torvalds. It is free to use, and the source code is publicly available. The copyleft license type that covers Linux requires a developer who modifies certain parts of the Linux operating system to share the source code they created. The two main categories of FOSS licenses are copyleft and permissive.
Copyleft license means that the software author has a claim on the copyright of their work, and anyone that uses, modifies, or shares the work must make their code publicly available. A developer in a private company that adds to or modifies copyleft licensed software could be forced to expose proprietary code or trade secrets. An example of a copyleft license is GNU v2 created by Richard Stallman.
Permissive license allows much more freedom to the developer when adding to or modifying the software and generally requires nothing in return. Some permissive licenses attach more requirements than others. But in general, they are less risky for a business to use with proprietary software. An example of a permissive license is the MIT License, created at the Massachusetts Institute for Technology.
The US Courts have set a precedent in favor of the FOSS author when there is a dispute. Which is why the organizations security and compliance teams should create a policy providing an authorized list of FOSS licenses for use within the organization. Developers should consult with Security and Compliance teams for any additional questions or request for FOSS exceptions.
The collaboration of the team will protect the company from potentially having to share proprietary software, paying fines, or defending itself in litigation. More important, protecting proprietary software from a FOSS license violation can also limit the risk of a supply chain attack.
Supply chain attacks
In 2020, the network monitoring company SolarWinds unknowingly distributed malicious software to their customers. It was a huge event that went unnoticed for months and exposed many well-known technology companies to hackers. Evidence of the incident showed that malicious software was injected into the SolarWinds Orion software during the build process. When the new version of software was released to customers, hackers were unknowingly granted access to systems.
Supply chain attacks occur when developers include (accidently or intentionally) FOSS that is malicious or contains vulnerabilities with their own software during the build process. With it imbedded in the developer’s software release, the malicious software acts like a trojan horse. Once it’s been installed by a user, the malicious software activates and either waits for commands from the controller or starts performing pre-defined actions like a ransomware attack, obtaining login and password credentials, or scanning the network for other places it can jump to. Below are some of the common ways supply chain attacks happen along with how DevSecOps can work with developer teams to prevent these during the planning process.
- Compromised software updates – Software developers release patches and updates to their software on a regular cadence. DevSecOps helps protect users by making sure developers only use software updates that come from a valid and protected source.
- Inherent defects in FOSS – FOSS is not immune to bugs, security flaws, and malicious actors. DevSecOps advises software developers to pull FOSS from reputable public repositories. Developers should also search the version history for security issues or concerns before implementing FOSS into their software builds.
- FOSS download limitations – FOSS from public repositories and registries have a limited number of daily downloads for free. Large development organizations can quickly exceed these daily downloads which can result in failed software builds or delay a planned production deployment. DevSecOps can provide private repositories and registries for developers to store FOSS that is under the control of the business and has unlimited downloads.
- Manual steps in a build and release process – Developers should plan their projects around the use of automated build and release pipelines. Pipelines allow DevSecOps to use security scanning tools to identify malicious software.
Licensing and supply chain attacks can expose business systems to serious risks and be very difficult to eliminate when embedded in a software release. Planning with DevSecOps helps software developers navigate the risks associated with FOSS and supply chain attacks.
Next steps
When planning is complete and developers begin coding their software, they need a secure place to store and protect their work. The next article will cover how we secure repositories to protect the company’s proprietary code.
