The cyber security attack on Solarwinds has been a bit of a wake-up call for security and risk professionals. The Solarwinds Orion™ software was used as a point of entry into numerous companies and government agencies, resulting in undisclosed damages to the agencies and immeasurable damage to the Solarwinds reputation. It has very poignantly demonstrated that most traditional application security programs fall woefully short in today’s era of DevOps and the automated processes that accompany it. The attack has also reiterated the fact that basic security constructs like password hygiene continue to get overlooked – and attackers continue to successfully exploit these fundamental details. What’s at the root of this risk? How can enterprises actually harness DevOps automation to better protect themselves?
First, it’s important to understand the changes in software development and what underlies the DevOps movement. It centers around breaking down silos between developers and operations, and more recently, also security teams. Software is approached like a factory, from planning through creation, development, testing, and operations, with repeatable, measured processes that can be improved over time. Automation plays a key role, not only for efficiency but for consistency. Continuous integration (CI) is an automated DevOps process where code changes are checked into the source code management system and where compilation and testing occurs.
When application security testing is automatically applied during continuous integration, it’s often referred to as DevSecOps. A key benefit of shifting security testing upstream, earlier in the process, is that the developer who created the security flaw can fix it while they are still working on the code. It’s more efficient for the developer to fix it there rather than coming back to it in another project weeks later, and it’s more efficient for security teams who may not need to get involved when vulnerabilities can be resolved immediately.
Another aspect of DevOps automation is provisioning resources. Instead of developers asking operations to set up environments in which to work, DevOps tools enable developers to set things up themselves. Scripts simplify the effort so the developer need not be an operations expert and projects are initiated in a consistent manner, following resource allocation policies. To make things even more efficient and consistent, entire environments may be set up in containers and the containers simply invoked and reused. Again, it’s the continuous integration engine that manages this.
The Continuous Integration pipeline is at the very heart of the software factory. It’s essentially the software assembly line where the engineer’s code is married to subroutines developed by third parties, and the resources needed to run the software are applied. These methods have enabled engineers to deliver more software faster than ever before. In fact, the pandemic has further accelerated this velocity. GitLab’s annual DevSecOps survey found that 60% of developers are releasing code 2x faster than before, up 25% from (pre-pandemic) 2021. Companies like HackerOne have achieved even faster deployments when integrating security into CI.
Using this automated CI engine can bring greater risk but it can also be used to improve security. Let’s look at how.
The software factory itself is an attack surface. It’s one that often falls beyond the domain of the security team. CI is usually managed by the application, engineering, or DevOps teams, often with little involvement from security. It represents a new frontier that security absolutely needs to understand and pay attention to. A metaphor may provide helpful insight. Consider if this assembly line were in a physical manufacturing environment. You would carefully control access, preventing unqualified individuals from assembling the product and ensuring only authorized parts are used in the construction. You would quality test subcomponents to ensure faulty parts down cripple your end product making it unsafe or disfunctional. This same rigor must be applied to software development processes.
When properly managed, the CI pipeline can be used to apply this rigor. CI can ensure that every code change is tested for new security vulnerabilities, preventing new technical debt and reducing vulnerabilities in production. Exceptions can be handled consistently, according to policies which are also automatically applied. Compliance and auditing is greatly simplified in such an environment.
When considering application security, scanning for security vulnerabilities in the code is most organization’s chief concerns, whether it is done within the CI pipeline or done the old fashioned way after the software is ready for use. While scanning remains critical, the Solarwinds attack has shown us that it is no longer sufficient. In that attack, it was not vulnerabilities in the software itself but rather lack of basic password hygiene and corruption of the build process itself that allowed attackers to inject a back door to the software, turning it into a trojan horse. Security teams must do four things:
- Harness CI automation to automate and ensure compliance with their security policies and those of regulatory bodies.
- Expand security programs to include threat detection beyond the code itself – inspecting containers (such as Docker), orchestrators (such as Kubernetes), third party code, APIs that connect applications together, and templates (such as Terraform).
- Protect the integrity of the software factory itself via access management, code attestations, and improved auditability of the end-to-end software factory.
- Reevaluate security fundamentals. Can automation be used for mundane tasks that remain very exploitable – things like password rotation, secrets detection, and role-based access control.
By looking at the automation that accompanies DevOps as a powerful tool to automate and scale your security program, you can reduce risks rather than succumb to new ones.