Is Your Code Secure in Delivery? (Most Execs Say No)

By Prakash Sethuraman, Chief Information Security Officer, CloudBees

If you think your software supply chain is secure, you might want to think again. Not every supply chain is as secure as it should be. In fact, within each pipeline there are manual steps that present a risk of human error that can lead to a possible security breach. The more steps in a pipeline, the more opportunity for risk. 

On top of that, most C-suites don’t even know what to do when a security issue arises in production. According to the recent CloudBees Global C-Suite Security Survey, 58% of respondents say that if they experienced a supply chain vulnerability, they have no idea what their company would do—this despite 95% reporting they think their software supply chains are secure. 

Yes, thinking about a secure software supply chain in the context of your organization can be overwhelming, and there are many factors to consider. But if you want your supply chain to be as secure as possible, you’ll need security in every step—which is where the concept of Secure in Delivery comes in.

Secure in Delivery means ensuring your software delivery process is secure and of the utmost integrity. But it’s also about making sure you’ve taken all the necessary steps to get there. Within the delivery process, secure delivery means asking questions like, 

• “Did these steps happen in the right order?”

• “Do we understand what it means when this particular thing fails?”

• “What do we do if we have this particular issue pop up?” 

Essentially, Secure in Delivery is controlling for all the things that can go wrong in the delivery process aside from the code itself. Remember, even if your code is rock solid, without a secure pipeline, you’re still at risk of harm from bad actors and human error.

1. Automate everything: Or as much as you can. Automation is the single most important step to securing your software supply chain. Simply put, automation is everything that needs to be done (and to what standard) to predictably and repeatedly deliver software. If you cannot describe all the steps—or if they are locked away in institutional knowledge or outdated runbooks—then you cannot automate it, you cannot improve or measure it, and most importantly, you cannot secure it.

2. Create access and privilege controls for the code and the pipeline itself: As part of automating your supply chain, you will be forced to examine your current access and privilege policies. Getting on the right track for security means making sure that the right people have access to the right things. Start by asking yourself, “who has (and should have) access to the automation?” and “who has access to the approval levels for stamping code to go on to the next level?”

3. Create and update a catalog of immutable objects: Making sure you’re only using approved immutable objects is a big security step, and your fully automated pipeline plays a big role here. Immutable objects are secure objects in a repository that cannot be changed after they are created. Why are these so important? Immutable objects prevent people from going in and tweaking code after it’s deployed. While this might not matter as much in a testing environment, drift makes all the difference once you’re in production. Checking and updating immutable objects on a regular basis via your automated pipeline adds another layer of security to the delivery process and ensures the software you put into production is exactly what you wanted.

Remember, your code and your pipeline are only as good as your security measures. Implementing security in every step of the process—from development to delivery to production—will give you a stronger, more secure supply chain. 

To read the full Global C-Suite Security Survey, download it here.