By Prakash Sethuraman, Chief Information Security Officer, CloudBees
DevOps practitioners like to talk about shifting left—a process that’s much easier to ponder than to execute. If you’re unfamiliar with the term, shifting left is the effort to catch vulnerabilities in your code as early as possible. And, it also usually means that DevOps teams look to developers to find and resolve code issues, which places a hefty burden on the developer. I believe we must focus on making sure developers don’t produce insecure code in the first place.
You may be wondering where code issues originate since developers don’t intend to write vulnerable code. When developers use open source code, plugins, and tools in their software development work, they can inadvertently introduce security vulnerabilities. In my experience as a software security practitioner, I’ve realized most organizations don’t validate the code for security issues until they’re at the end of the development process. In my role as the CloudBees Chief Information Security Officer, I want to focus on what I call “Secure in Development,” which is much more than shifting left.
The Importance of Clean Code
Before I dig into Secure in Development, it’s important to lead with the significance of clean code, i.e., secure code. Clean code is the backbone of overall application security, development efficiency, and release velocity. If your code isn’t clean, it can cause a mountain of downstream problems, especially when you find an issue after your code is released into production. If this happens, identifying and resolving the problem can be much more challenging.
What Do I Mean By “Secure in Development?”
It means you've taken all possible steps to ensure you develop clean code from the start, which usually includes identifying and fixing errors by checking dependencies, analyzing code, signing binaries, and so forth. In other words, you’re embedding security validation measures early in your development process.
While Secure in Development resembles shifting left, there is a critical difference. Shifting left overlooks the rest of the software supply chain. I mentioned earlier that shifting left places a significant burden on developers. It’s important for developers to understand preventative security measures as they create code, but imposing the software security burden only on developers doesn’t put enough emphasis on security in delivery and production processes.
What Can You Do Now?
If you’re wondering how you can put this Secure in Development concept into action, here are a few thoughts.
Make sure your code is secure by design. In other words, know the provenance of any pre-built artifacts you use to make sure they are validated, verified, and secure.
Do not let your software supply chain get compromised. The software supply chain affects every aspect of how you control your idea state going forward.
Enroll your controller in Jenkins Health Advisor by CloudBees™. It’s a free tool that helps you proactively monitor your Jenkins environment to pinpoint problems so you can resolve them as quickly as possible. If you’re a CloudBees customer, this tool automatically comes with CloudBees CI.
Automate your software delivery ecosystem as much as possible. This eliminates human errors and missed steps that will cause hiccups, headaches, and security issues later.
For more information on creating a secure software supply chain, read “Securing the Software Supply Chain: Starting With the Basics.”