Security embedded into dev life cycle Step 2- Develop

Congratulations, the planning is done and now you are ready to venture into the world of development. This is where the engineers come to life and start showing off their capabilities in building the product that was planned.

A security driven development strives to have the security pitfalls avoided as early as can be (shift left) since the farther they are down the line, the more costly they become. The key takeaways in this step include:

Secure components: Usage of components which are vetted, robust and have security built in to them will lead to a better hardened piece of software. For example the usage of SafeC libraries that increase the security of C/C++ code. Adding to this, make sure of using upgrade components that adhere to the latest crypto/cypher will is crucial

Third Party Software (TPS): A big part of today’s work includes the usage of many TPS libraries, this need to be reviewed, indexed and tracked for upgrades and vulnerabilities.

Code Quality: Perform static analysis and report all security issues that arise. One of the approaches is to deny the commit of new code into the branch when it includes static analysis violations, this keeps the relevant branch clean.

Enforcement: Consider using a tightly secure code commit mechanism. All code trying to be commit must be reviewed and pass a security gate which will prevent the delivery of a vulnerable code. Basically validating all the items from above will achieve two things

• Education - The dev team will be forced to gain the practices of secure coding since the system will block him from doing anything else other than that
• Sanitation - Keeping the branches clean, thus maintaining the security of the product

 Clearly this is not an exhaustive list so please add your thoughts in the comments section. Just keep in mind that we are simply talking about the developing, we have not spoken about the deployment yet. Onward and forward!