As the complexity of IT operations continues to increase, the need to shift cybersecurity left into development and CI/CD pipeline is fast becoming a priority for many IT organizations.
Of course, the idea of shifting security left isn’t new. It was first introduced as far back as the 1970s (long before the first line of malware code was written). It also is what gave rise to the idea of DevSecOps and the earlier concept of secure by design. But this approach to software development is still relatively new and has only been adopted by about a third of development organizations today.
While secure by design is primarily focused on ensuring secure code, with DevSecOps a predetermined set of security services are rolled out when an application or workload is deployed. This includes things like network security, multi-factor authentication, access rights, and the like.
To ensure that production applications are as secure as possible going forward, both approaches will likely have to be adopted en-masse by developers and IT organizations.
Adoption is slow for a lot of reasons
Developers have traditionally leaned on IT security and operations teams to secure the code they create. But there are plenty of things happening today that make that hard. Hyper-targeted and sophisticated cyber attacks, containerized, hybrid compute environments, and a porous, hard-to-define network edge all make it impossible to treat cybersecurity as a bolted-on afterthought.
The rapid adoption of microservices architectures and serverless compute in the cloud has created an environment where understanding network architectures and application dependencies gets exponentially more difficult every year. The pressure on developers to produce code, generate updates, and create new features and functionality is also increasing every year as organizations turn to digital technologies.
High expectations coupled with the widespread adoption of Agile and DevOps means that developers are relying on platform- and infrastructure-as-a-service providers and infrastructure-as-code deployment to move more code into production faster than ever. Developers are also having to rely on more complex toolchains to get their work done.
Adding more fuel to the fire is a lack of cybersecurity knowledge among many developers and a critical shortage of skilled cybersecurity professionals on the IT side. The worrisome rise of ransomware as the go-to malware of the 2020s, means that cyber attacks are getting more expensive both in economic and reputational terms.
IT needs greater visibility
From IT’s perspective, the lack of visibility into how code is developed and where it’s being deployed (including in development environments far from production servers) creates blind spots that can make it difficult to know where to start when recovering from a cybersecurity attack.
Even though there are run books specifically designed to help incident response teams figure out what is going on, the speed at which new features and functionality are introduced into production means that documentation isn’t always up-to-date or even available.
Another very good reason to begin shifting cyber security left is developer environments are increasingly seen as good targets for cyber criminals to infiltrate the organization. Developers use a lot of open source code and complex, automated tools chains that, when misconfigured or misused, can open the door for attackers to get a foothold within the organization.
Developers may also forget about and leave test environments running long after they have served their purpose. The Solarwinds supply chain hack of 2020 is a good example of what can happen when hackers get ahold of source code before release.
Once the development environment is compromised, it’s much easier for attackers to do things such as embed ransomware into the organization’s backups. When IT attempts to recover from the ransomware attack either they find that the data they need has been corrupted or they relaunch the attack from malware stored in the backups.
3 steps to shifting left
Too many organizations still do security testing just before the software is released to production. Continuous vulnerability testing introduced earlier in the SDLC results in software that has fewer bugs and security holes. By moving this process into that CI/CD pipeline, two things happen: there is greater assurance that the organization’s security standards will be followed and it gets developers involved earlier in the SDLC.
The first step is to conduct automated static application security testing whenever code is compiled. Most organizations doing CI/CD will have the tools and frameworks in place already to make this happen. Make sure the scan results are uploaded to a vulnerable component database made available via a CI engine dashboard in a way that is traceable back to the original build. This will help with compliance, reporting, and research purposes while giving you a constant assessment of your application.
Next, make sure you are conducting software composition analysis studies to understand all application and third-party dependencies at build time.
Finally, it’s best practice to do dynamic application security testing.
If you aren’t already doing these practices, it can be expensive to get started. But they will keep your organization out of the headlines. That’s worth every penny.
