According to an article in Security Magazine, 98% of organizations have been negatively impacted by a cybersecurity breach in their supply chain. Aqua’s 2021 Software Supply Chain Security Review notes that “attackers focused heavily on open source vulnerabilities and poisoning, code integrity issues, exploiting the software supply chain process and supplier trust to distribute malware or backdoors.” This report also discovered that almost every company they had evaluated had “vulnerabilities and misconfigurations that can expose them to supply chain attacks.” These findings show a significant threat and a disconnect between a business’s need for security and DevOps’s need for agility and speed.
Business expectations of faster delivery and reduced cycle time have naturally led development teams to embrace and adopt the practices of CI/CD. DevOps was designed to shorten development cycles, allowing organizations to be agile and maintain the pace of innovation. Many DevOps teams do this by taking advantage of cloud native technology and practices. The challenge is that these practices rely on many third-party components including using between hundreds and thousands of open-source packages for each application. That leaves organizations with the need for more visibility into and understanding of how the components they use are developed, integrated, deployed, and maintained. This leads to vulnerability, the inability to ensure the components’ security, and, eventually, compromise.
Threat actors know one of the best ways to infiltrate a target is to find a back door through the supply chain. Most of today’s software is not written from scratch, and attackers leverage the fact that most software artifacts contain a lot of open-source code. These are a reliable way for bad actors to penetrate the environment as a third party usually has less security than companies’ own source code. Any changes made to software artifacts, a flaw in the code, or unpatched software leaves businesses more susceptible to security issues and a door open.
Private Is Not Secure – The Golden Pipeline
A “golden” anything implies something that is in its final form, and it conjures up the idea of a perfect version that is constant and reliable.
As DevOps continues to migrate toward the cloud, the diverse range of tools, platforms, and containers and the complex ecosystems used create a vacuum for risk. In the context of application development, the idea of the golden image is well known; a consistent, reliable baseline for configuring a system or application allowing you to streamline development. The idea being the implementation of a golden image would allow for faster deployment, patching, and configuration, as well as less human error and drift.
Why not take the same concept and apply it to how we build development pipelines? There are still many traditional pipelines with projects starting on a private repository. The concern is that this could be done with little prior discussion or security built in outside the project being created on a private repository. Private does not equal secure. That’s why we propose the “golden pipeline”, a pipeline that is secure-by-default and works within the existing development operational model. This way, security is built into the application and validated at each stage, so by the time it reaches production it’s already as clean as can be.
Shifting Left Incorporating Security
Having this golden image is more than just an ideal solution for security in DevOps. The term “shift left” is also used frequently. Some may say it is overused when discussing the integration of security. But what is the reality of what is being said in “shift left”?
Maybe it is to look at security in terms of time, not direction. In other words, move the security discussions to earlier in the process, left of the timeline. Finding what could be an issue at the beginning before it becomes an external factor that stops development and adds significant work to the project, causing friction between teams. Think of it as shifting the analysis left but verifying on the right. Look at security earlier so there are no issues later.
How is this done? By collaborating with teams in advance, building the security measures and policies into the pipeline (as opposed to on-top-of the pipeline), and having documentation and processes that everyone agrees to before the project’s inception.
Integrating Security into Development
Meet developers where they are. Yes, having an agreement in place to implement policies that are the least intrusive yet still secure poses challenges to many DevOps and security teams looking to create consistent “shift left” practices and find that “golden pipeline.” As supply chain concerns grow, aligning to execute security across teams now only helps determine success later. But how do you enforce security? Two words: communication and feedback.
Enforcing security without involving your developers is setting your project up for failure. Each team has little nuances that are specific to how they work. Enforcing rules that may be a critical risk for one may have no impact on another.
To solve this, we recommend two tiers of policies. The first, Tier One, is general company policies, the standardized rules. This type is typically a general risk and not heavily enforced. The Second Tier would be anything you want to enforce. It should be granular. Build into the security flow the nuances and provide key stakeholders with role-based access control and permissions in line with their scope. This allows teams and stakeholders the ability to create policies and enable a shared responsibility model.
The Aqua Difference – Better Together
Your source code is your application’s largest attack surface. It can be composed of millions of lines of code and a complex web of external dependencies, all of which must be vetted on every change for trust. While tools are available to scan for risks, they do not cover everything.
Software supply chain security helps organizations detect, identify, analyze, and mitigate risks associated with the digital artifacts that enter their software via third parties like open source libraries, commercial software vendors, or outsourced development. A comprehensive supply chain security strategy combines risk management and cybersecurity principles to assess supply chain risks, implement measures to block, mitigate or remediate them, and review what other tools may miss.
Learn how to enable your organization to automate the secure development and deployment of applications in your DevOps pipeline by embedding comprehensive security testing and robust policy-driven controls early in your next project.
Watch our webinar Making Security Easier for Your Developer Pipeline where Microsoft’s Stephen Griffith, Cloud Native Principal Specialist & Global Black Belt, and I further discuss how you can “shift left” and create that “golden pipeline” by:
- Identifying software supply chain issues
- Implementing standards that work across teams
- Improving security posture with integrated checks
- Leveraging developer tools to ensure a feedback loop and make security part of the process