The challenge of guarding against supply chain attacks [Q&A]
In recent years we've seen a trend towards attacks targeting the software supply chain rather than being directly against businesses.
Attacks can include poisoning the software components, stealing secrets to compromise an account, or modifying code repositories to allow for exploits.
Why have these attacks become such a concern? And how can organizations guard against them? We spoke to Guy Eisenkot, senior director of product management at Bridgecrew, to find out.
BN: Let's start with the basics -- how do you define supply chain security?
GE: Supply chains are made up of two primary elements -- the various application and infrastructure components that make up cloud native applications and the pipeline that builds and delivers these components into a working application environment. Both of these pieces are subject to threats from bad actors attempting to tamper code to install cryptominers or exfiltrate sensitive data. For example, infrastructure as code (IaC) can contain misconfigurations and open source packages can contain vulnerabilities. Similarly, version control systems and CI/CD pipelines can be configured insecurely and registries may also have poisoned images.
BN: What unique challenges do you think supply chain security poses for organizations? How are these different from other cybersecurity concerns?
GE: Our friends at Unit 42 found that even a mature security organization's software supply chain could be compromised with one exposed secret. Supply chain attacks come from a variety of locations, including poisoning the software components, stealing secrets to compromise an account, modifying code repositories to allow for exploits, and more. Mapping all of the components and processes of a software supply chain is the first step to understanding the threat surface and focusing on security efforts. Having true, end-to-end software supply chain security requires not only the visibility across assets, but also strong security posture at each stage and layer of the supply chain.
BN: What role do you think open source plays in helping companies improve their security posture? Can an experienced company be secure using only open source and in-house tooling, or are vendor solutions necessary?
GE: We believe the DevOps ecosystem has a foundational relationship with open source. We can't imagine cloud native applications without Docker, Kubernetes and Terraform. Security tooling has to conform to the same architectural patterns. I think the opportunity for growing organizations is similar when it comes to DevOps and Security alike. It enables them to experiment first and optimize based on continuous learning. We've taken that approach in our internal product building and have also implemented those learnings into open source utilities we maintain and foster like Checkov, Yor and AirIAM.
BN: What role do software developers play in cybersecurity within modern organizations?
GE: No one can spot the potential for an exploit and pivot like a security-minded developer. Developers know the vulnerabilities left in their containers because the breaking change would make you miss your deadline. Developers know which dependencies would break if a database were to go offline to fix a misconfiguration. Additionally, engineering and DevOps teams are direct stakeholders of cloud-native crown jewels -- IaC, VCS, CI/CD pipelines. Giving those teams the visibility and ownership to harden these assets is the most logical and impactful way to systematically prevent software supply chain attacks.
BN: The cybersecurity space in general is quite crowded with tons of vendors. How should an organization that wants to take security more seriously evaluate and ultimately choose the proper tooling?
GE: In the context of supply chain security, the space is indeed becoming crowded pretty quickly. Our advice for organizations is to include practitioners, in this case developers and devops, in the initiative and first explore utilization of existing investments. Based on the type of cloud and infrastructure developers use, it is likely that prominent industry leading tools will surface above the noise.
BN: What does it mean to actually shift security left? Does that mean developers should now be expected to know and understand security best practices, or that dedicated security teams should be embedded earlier in the software development lifecycle?
GE: In the context of secure development, we refer to 'shifting left' as embedding security related operations into developer workspaces. You are correct that it introduces a new set of expectations from the developer to understand the consequences of making design and architecture changes. Security teams have a vital role to play here: Rather than have them gatekeeping they are expected to use developer's existing platforms to introduce tighter security controls without slowing developers down.
The truth is that in modern organizations developers need to have more responsibility for security. Instead of just being security 'champions', developers need to have more visible roles in building secure software. This is a huge part of making DevSecOps actionable. No matter how many guardrails or how much alerting security implements, developers will find a way around if their work is disrupted. Security will have to work with developers to strike the right balance. By being more involved in security conversations, developers will dictate what tools are chosen and may even start to hold legacy security tooling accountable for good developer experiences. As part of this shift, we also expect to see more engineering teams and individual contributors start to own KPIs beyond just lines of code or features released, but also how secure or security issue-free their software is.
Image Credit: frank_peters/ Shutterstock