The SolarWinds cyberattack, discovered in December 2020, remains one of the most consequential software supply chain compromises in history. Attackers inserted a malicious backdoor into SolarWinds’ Orion software build pipeline, which was then signed by SolarWinds’ own code-signing infrastructure and distributed as a legitimate update to approximately 18,000 customers, including major US government agencies. The attack directly informed EO 14028, the NIST Secure Software Development Framework (SSDF), and CISA’s Secure by Design initiative, reshaping how organizations think about build pipeline security, code signing controls, and software supply chain visibility. The incident also intensified the debate about where security ownership should reside: in a separate InfoSec function, in DevOps teams, or in an integrated DevSecOps model. The recommended action: the SolarWinds attack was not an InfoSec failure or a DevOps failure in isolation; it was a build pipeline integrity failure that required both security expertise (to define the controls) and development operations (to implement them). The answer is DevSecOps, with InfoSec owning policy and architecture and development teams owning implementation of those policies in the pipeline. For the Secure Software Development Framework that directly emerged from this incident, see Secure Software Development Framework To Ensure The Correctness Of The Code. For code signing controls that protect build pipeline integrity, see CodeSign Secure.
Quick Answer: Where Should Security Live After SolarWinds?
The SolarWinds attack demonstrated that the InfoSec vs DevOps question is a false choice. The attack exploited a gap that neither a traditional InfoSec model nor a DevOps model without security integration would have closed: InfoSec teams do not typically monitor build pipeline processes in real time, and DevOps teams without security controls do not implement build integrity monitoring by default. The answer is a DevSecOps model where InfoSec sets security policy, architecture standards, and compliance requirements; DevOps implements those requirements through automated security gates in the CI/CD pipeline; and both teams share accountability for software supply chain integrity. Code signing with HSM-protected keys and build environment integrity monitoring are the two controls most directly responsive to the SolarWinds attack pattern.
The SolarWinds Attack: What Happened
Discovered in December 2020, the SolarWinds cyberattack involved attackers compromising SolarWinds’ Orion software build pipeline and inserting a sophisticated backdoor named SUNBURST into the software update mechanism. The build process then compiled and packaged the malicious code normally, and SolarWinds’ code-signing infrastructure signed the resulting update with valid SolarWinds certificates, making the compromised update indistinguishable from a legitimate release. The update was distributed to approximately 18,000 SolarWinds customers, including the US Department of Homeland Security, the Treasury Department, and numerous other government agencies and private companies.
The SolarWinds attack was a supply chain attack: attackers targeted a third-party software vendor rather than the organizations themselves, using that vendor’s trusted distribution channel to deliver malicious software to the vendor’s customers. This attack vector is particularly effective because customers have no reason to distrust software updates that carry a valid signature from a trusted vendor. The attack highlighted the critical importance of software supply chain security and specifically the build pipeline integrity controls that prevent unauthorized code from being signed and distributed as legitimate software.
InfoSec and DevOps: What Are They?
Before addressing the question of where security should live, it is important to understand what InfoSec and DevOps are and what each model is optimized for.
InfoSec (Information Security) involves protecting information systems, networks, and data from unauthorized access, use, disclosure, disruption, modification, or destruction. InfoSec teams identify vulnerabilities, develop security policies, and educate users on best practices. They are typically structured as a function that provides oversight, audit, and policy governance across the organization, independent of any individual development team or project.
DevOps is an approach to software development that emphasizes collaboration and communication between development and operations teams. It aims to streamline the development process by automating tasks, continuously testing code, and integrating workflows for faster, reliable software releases. DevOps teams are directly responsible for the pipeline that produces and delivers software, making them the logical owners of any security controls embedded in that pipeline.
Where Should Security Live: InfoSec or DevOps?
The SolarWinds attack raises the question of whether security should live in InfoSec or DevOps. Some argue that security should be the responsibility of InfoSec teams, while others argue that security should be integrated into the DevOps process. Both arguments have merit, and the reality is that neither model alone would have prevented SolarWinds.
Arguments for InfoSec
-
Focus on risk management
InfoSec teams are trained to focus on risk management and threat mitigation. They have a deep understanding of potential vulnerabilities and threats, and they are equipped to develop and implement the policies and procedures that protect against those threats. For supply chain attacks, InfoSec teams provide the threat modeling expertise to recognize that build pipeline integrity is a security concern and to define the controls needed to address it.
-
Independence
InfoSec teams are independent of the development process, which allows them to provide an unbiased perspective on security issues. They are not subject to the pressures of meeting development deadlines and can prioritize security concerns without compromising the development process. This independence is valuable when security requirements conflict with delivery velocity.
Arguments for DevOps
-
Security as code
DevOps teams are responsible for creating and deploying code, so they are best positioned to integrate security into the development process. By incorporating security controls into the CI/CD pipeline as code, DevOps teams can ensure that security is built into the software from the beginning rather than being bolted on as an afterthought. Build pipeline integrity monitoring, SAST, SCA, and secret scanning are all implemented by DevOps teams in practice.
-
Faster response times
DevOps teams deploy code quickly and efficiently. By integrating security into the development process, they can respond more quickly to security issues and vulnerabilities. When a CVE is published in a dependency, a DevOps team with SCA in the pipeline can detect and remediate it in hours; the same process through a separate InfoSec gate can take weeks.
Decision Factors: Choosing the Right Security Ownership Model
-
Organizational culture
Depending on whether the organization prioritizes security and compliance or innovation and agility, either InfoSec or DevOps ownership may be better suited as the primary model. Organizations with strong compliance requirements in finance and healthcare typically maintain a dedicated InfoSec function; organizations with rapid release cycles in SaaS typically embed security in DevOps through automation.
-
Development methodology
In a waterfall development methodology, a separate InfoSec team providing stage-gate reviews may be more appropriate. With Agile or DevOps methodologies, integrating security measures into the development pipeline through automation is more feasible and more effective than periodic gate reviews.
-
Regulatory compliance
If the organization must adhere to stringent regulatory requirements such as HIPAA, PCI DSS, or DORA, a separate InfoSec function with documented policy ownership is typically necessary to satisfy audit requirements. A DevOps-only model may lack the formal documentation and independent audit trail that regulators expect.
-
Skillset and resources
Organizations with a large, experienced InfoSec team benefit from leveraging that expertise for policy governance and architecture review. If the InfoSec team is small or if security needs are rapidly evolving (as with supply chain security requirements post-SolarWinds), embedding security into DevOps through automation may be more practical than scaling the InfoSec headcount to match.
Supply Chain Security Controls That SolarWinds Made Mandatory
The SolarWinds attack demonstrated the specific controls that are needed to protect the software build pipeline, regardless of whether they are owned by InfoSec, DevOps, or a shared model:
- Build environment isolation and integrity monitoring: The build environment should be isolated from general-purpose networks and monitored for unauthorized process execution or file modification that could indicate build pipeline compromise
- Code signing with HSM-protected keys and dual authorization: Code signing private keys should be stored in FIPS 140-3 validated HSMs with dual-authorization controls requiring multiple approvals before a key can be used; this limits the ability of a compromised build system to produce trusted signatures without detection. See CodeSign Secure for implementation
- Software Bill of Materials (SBOM) generation: Every software release should include an SBOM documenting all components and their provenance, enabling rapid identification of compromised components after a supply chain breach
- Reproducible builds: Build processes should be deterministic so that the compiled output can be independently verified to match the signed source code
- Secret scanning in CI/CD: Credentials, API keys, and private key material should be scanned from repositories and build environments to prevent their accidental exposure through build artifacts
- SSDF compliance: The NIST Secure Software Development Framework, published in direct response to SolarWinds, provides the complete practice framework for addressing all of these controls. See Secure Software Development Framework To Ensure The Correctness Of The Code
Update Log
| Date | Event / Update |
|---|---|
| December 2020 | SolarWinds Orion supply chain compromise discovered; SUNBURST backdoor identified in signed update distributed to approximately 18,000 customers |
| May 2021 | EO 14028 signed, directing federal agencies to improve software supply chain security and requiring software vendors to attest to SSDF compliance |
| February 2022 | NIST publishes SP 800-218 (SSDF), the Secure Software Development Framework, directly addressing build pipeline integrity and software component provenance |
| May 2023 | Original blog post published analyzing the InfoSec vs DevOps security ownership question in the context of SolarWinds |
| September 2026 (this update) | Content updated with technical depth on SUNBURST attack mechanism, supply chain security controls, InfoSec vs DevOps decision table, SSDF context, update log, and FAQ section |
Conclusion
The question of where security should live, in InfoSec or DevOps, is not straightforward. Both approaches have merits, and the best approach depends on the organization and its specific context. What the SolarWinds attack definitively demonstrated is that neither a traditional InfoSec gate-keeping model nor a DevOps pipeline without security integration would have prevented it. InfoSec did not monitor the build pipeline in real time; DevOps did not have controls to detect unauthorized code injection before signing. The most effective model integrates both: InfoSec teams own security policy, architecture standards, and compliance oversight; DevOps teams implement those standards through automated security gates in the CI/CD pipeline. This is DevSecOps, and it is the model that provides both the depth of security expertise and the operational velocity needed to protect modern software supply chains. For the NIST framework that directly codifies these lessons, see Secure Software Development Framework To Ensure The Correctness Of The Code. For code signing and build artifact integrity controls, see CodeSign Secure.
Frequently Asked Questions
What was the SolarWinds cyberattack and how did it work?
The SolarWinds attack, discovered December 2020, was a supply chain attack in which attackers compromised SolarWinds’ Orion build pipeline and inserted a backdoor (SUNBURST) into the update mechanism. The backdoor was compiled normally and signed by SolarWinds’ own code-signing infrastructure, making the compromised update indistinguishable from a legitimate release. It was distributed to approximately 18,000 customers including major US government agencies, giving attackers persistent access to victim networks.
What is the difference between InfoSec and DevOps as models for owning security?
InfoSec teams specialize in security policy, risk assessment, compliance, and security monitoring; they provide depth of expertise and independence from delivery pressure, but operate outside the development pipeline where code decisions are made. DevOps teams own the software delivery pipeline and are positioned to embed security automation there, but typically lack deep security expertise. DevSecOps integrates both: InfoSec sets policy and architecture, DevOps implements it through automated pipeline security gates.
What specific security controls would have reduced SolarWinds-style supply chain risk?
Controls that directly address SolarWinds-style supply chain risk include: build environment integrity monitoring to detect unauthorized code injection before signing; code signing with HSM-protected keys and dual-authorization controls; SBOM generation for component provenance tracking; reproducible builds for independent verification; network segmentation of the build environment; and behavioral monitoring of build artifacts. The NIST SSDF (SP 800-218) provides the practice framework that addresses all of these controls.
How did the SolarWinds attack change software supply chain security practices?
SolarWinds directly informed EO 14028 (May 2021), NIST SP 800-218 SSDF (February 2022), and CISA’s Secure by Design initiative. EO 14028 required software vendors to attest to SSDF compliance for federal procurement and mandated SBOM requirements. The attack is now the canonical reference case for why build pipeline integrity, code signing controls, and supply chain visibility are essential elements of enterprise security programs.
What is DevSecOps and how does it differ from traditional InfoSec or DevOps models?
DevSecOps integrates security into the DevOps pipeline rather than treating it as a separate gate-keeping function. InfoSec owns policy, architecture, threat modeling, and compliance oversight; development teams own implementation and remediation; automated security testing (SAST, DAST, SCA, secret scanning) runs as a CI/CD quality gate with immediate feedback. Security becomes continuous rather than episodic, and both InfoSec and DevOps teams share defined security accountabilities.
