The developer experience and modus operandi have shifted significantly in the last decade. Development and operations teams are no longer siloed but instead work hand-in-hand under DevOps culture. Continuous integration and deployment (CI/CD) has become the status quo, enabling developers to reduce lead time to deployment and reducing work in progress (a leading indicator of bottlenecks for development teams).
These shifts in dev culture have been coming for a long time. For years, disjointed development and operations teams created frustration for all stakeholders, and manual deployment methods exacerbated project lead times, forcing organizations to reap unnecessary delay costs.
But yesterday’s inefficiencies don’t fully explain our shifting development culture. Equally as crucial to the story? Modern digital consumers crave a seamless experience and have generated high demand for smooth, continuous updates. Think about it: When users log into their favorite video game, or application, they don’t want to encounter service outages or network interruptions. However, they do want to benefit from performance upgrades and improvements to the user experience (UX).
Many organizations have prioritized speed during the software development and delivery process to meet these evolving expectations. That’s great news for consumers. Unfortunately, it’s also great news for bad actors, who are well-positioned to capitalize on modern development’s enlarged attack surfaces. With UX, speed and quality all balanced on the edge of a pin, can development teams still protect their software from supply chain cyber-attacks?
The short answer is yes — but to do so, they’ll need extensive knowledge of the software threat landscape and a plan to fortify their development best practices.
Attacks on the software supply chain are increasing. But why?
By 2025, Gartner predicts 45% of organizations worldwide will experience an attack on their software supply chain — a threefold increase from 2021. Yet many leaders continue to operate under the assumption their software isn’t a vulnerability. In fact, fewer than 30% of development decision-makers believe their software supply chain presents a security risk, according to IDC.
The takeaway here? Key stakeholders, including security experts, regard software supply chain attacks as an “if” and not a “when.” But I foresee this mindset shifting as more organizations fall prey to malicious, exploitable vulnerabilities in software libraries like log4j and OpenSSL.
Beyond speed, many reasons explain why the software supply chain has become easier and more lucrative for bad actors to exploit:
-
-
- Rise of third-party components: Open-source code is a boon for developers and consumers alike, as it expedites the development process and usually improves code quality. However, third-party components, libraries and frameworks are also popular vulnerabilities for hackers to exploit.
- Lackluster visibility: Internet-sourced utilities and code are far more mysterious than internally derived code. Often, developers cannot identify vulnerabilities until it’s too late because they don’t understand the code’s dependencies or changes. Not to mention the lack of signing from development to production. Limited visibility into their software supply chain makes it more challenging for developers to investigate, pinpoint and resolve issues, and prevent pre-deployment breaches.
- Minimal threat intelligence: Attacks are increasing in number and complexity by the day, but many organizations remain focused on addressing the cyber threats of yesteryear. Regularly updated security tools and protocols are needed to drive down unforeseen vulnerabilities. Moreover, the industry sorely requires further research into the complexities of third-party vulnerabilities.
-
Spurred by the rise in speedy deployments and agile development methodologies, these developments have widened software’s attack surface, leaving many organizations vulnerable to breaches. But it doesn’t have to be this way. Leaders can address emergent threats by shifting their organization’s development mindset left and implementing leading security protocols.
Securing your software supply chain requires collaboration…
Ferris Bueller famously said: “Life moves pretty fast around here. If you don’t stop and look around once in a while, you could miss it.” This wise axiom is certainly true for developers, who are constantly on the hook for the next patch or release, ad nauseam. In all that commotion, concerns deemed “secondary” to deployment — like security — often get forgotten in the shuffle.
No leader would claim security is unessential to the software development lifecycle (SDLC). Yet time and again, leading development methodologies prioritize speed over security. I’m challenging this line of thinking with a powerful alternative to the development MO: DevSecOps.
DevSecOps is the natural evolution of DevOps. It bakes security into the SDLC instead of displacing it as an afterthought. How? DevSecOps teams work as a single unit of developers, security personnel and operations experts. These team members work toward a singular goal of achieving high-quality, timely and secure deployments, so identifying and eliminating zero-day vulnerabilities is easier.
The result? A far more seamless SDLC and more secure deployments that don’t sacrifice speed or quality.
But DevSecOps is only successful if leaders fully embrace change. When leaders transition to a DevSecOps mentality, they should never tack security tools onto existing development practices. Nor should developers be expected to operate business as usual. Leaders must provide developers with the full context of security concerns to enable them to address issues in tandem with more robust processes and protocols.
…and a robust cybersecurity-development framework.
No developer is an island. Accordingly, organizations must prioritize a security framework that empowers developers. But how?
As Armory’s SVP of Product & Marketing, I’ve worked to answer this question for years. I’ve hosted frequent discussions about software security with customers, partners and co-workers, and through those conversations, I’ve developed a keen understanding of the evolving threat landscape.
Here are the non-negotiable actions leaders must take to enable fortified, agile and secure deployments today:
-
-
- Automate threat detection: Automated testing is a powerful way to thwart hackers during all stages of the SDLC. Testing should be dynamic and analyze the entire envelope of a deployed application, not just its source code. Examples of common automation tools include OWASP security scanners and automated penetration tests.Automated testing doesn’t preclude developers from identifying vulnerabilities independently — it merely reduces the chances of a vulnerability slipping through the cracks. A core component of DevSecOps, automated testing ensures security measures won’t take a backseat during the SDLC.
-
-
-
- Audit dependencies: Developers need visibility into the provenance of their third-party components. Contextual dependencies in these libraries may impact code unexpectedly, creating vulnerabilities that hackers can exploit. Automated testing helps to provide heightened visibility, but developers should adopt additional tools with centrally controlled and auditable deployment pipelines to ensure only users with the correct permissions alter code.
-
-
-
- Protect the production environment: Obviously, developers strive to prevent vulnerabilities from reaching the production environment. But setting and accomplishing this goal are two completely different ballparks. That’s why it’s critical to implement a security framework preventing code from reaching production before it passes various security checks.Many continuous deployment tools provide this functionality. Additionally, consider adopting deployment tools that enable you to sign and audit the end-to-end trail including all hand offs, of your deployment. These image signing features ensure that deployed code has passed rigorous security and authorization checks before it reaches end-users.
-
-
-
- Conduct frequent threat modeling: Every choice made during the SDLC presents a new host of possible threats. Consider that each open-source package contains an average of 77 dependencies. (For reference, the average enterprise uses more than 40,000 open-source packages — making for many dependencies.)Continuous threat modeling informs developers about the potential risks associated with every decision. Through this process, developers can identify significant gaps in their existing controls. Common threats eradicated by modeling include spoofing, tampering, repudiation, information disclosure and denial of service.
-
Looking beyond 2023
Experts agree that software supply chain attacks will increase in the coming years. This suggests a robust security framework will become even more essential as we approach 2024.
By responding to the volatile, insecure nature of the software supply chain today, organizations build the groundwork for a more resilient tomorrow. That process begins with keen threat intelligence, a cultural shift left toward DevSecOps and — perhaps most importantly — investment in tools and practices prioritizing always-on security. I implore leaders to read the writing on their digital walls and fortify their operations now — before it’s too late.
