In the past article we expose the necessity of secure the software you, your team or your company build and deploy in your infrastructure. Today we are going to describe how to design it in a high-level way.

The Commitment

Either you made an analysis detecting a lack of security in your software or some regulations made you to put in position to improve your security what is true is that there is a need of communicate to the teams and the stakeholders that some new (and extra) work to implement embrace a new process.
Please be gentle, be supportive, conduct the agreements needed to succeed on implementing the cycle.

The Process

First come first, defining a transversal process with clear defined phases for every single piece of code you created is mandatory.
In the new cycle what is not accepted is a false perception of moving forward so as soon as some pipeline fail... break it!
There is no moving forward until the developers, teams and organizations embrace the new way to do the thing. And this is the point where the SSDLC sponsors/supported needed to be strong and no accept any single attempt of negotiation to go back previous status.

Phases

Assuming you have an automated pipeline based on any tool out there named gitlab/github etc. you can follow the next stages:

Pipeline with four stages: build, lint-security, test and deploy

Forget about the programming language and the pipeline tool and let’s focus on the stages.

1. Build

The simplest, just compile the thing

2. Lint-Security

Here you get the point. For sure you can delude the security in the compile phase, but defining it as a different phase emphasize the importance of the security.
Here you combine your quality gates linting the software and then apply your static analysis (SAST) and software composition analysis (SCA) tools. Please note the plural in tools, do not trust in a single tool but use more than one if you can.

3. Test

Execute the tests you need to validate the change but now it is done knowing that the code compiles and it is secure.

4. Deploy

Deploy it the code to your software repository manager re but here is when you have to close the door to insecure software. Make you pipeline tool the only capable of deploy to the repository or you will have opened the biggest backdoor in the process.

Conclusion

Moving organizations and teams to a whole new process wouldn't be quick, it wouldn’t be easy. You need to use you left hand and you need to design a realistic road map of where you are and where you want to be. What is true is that it will be worth it for you, for your security colleagues and for sure for your organization. Next post, we will try to expose a real example of how to implement it.