In DevOps, there is a practice called Shift Left where activities that you would do in the later stage of a developmental process you would do in earlier stages, hence shift left.
This usually refers to the testing and quality assurance parts of the developmental lifecycle. The idea is by ensuring quality practices earlier in the process, you can reduce quality issues in the end products. Defect detected at the end more painful and expensive to fix compared to errors detected earlier in the lifecycle.
In most instances, this is meant to address the functionality and stability of the software, but this should extend to the security of the application as well.
Security is not a technical issue; it’s a quality one.
In many organisations, I find that only at the end of the project, do they perform any security assessments. While I agree that there should security testing at the end – such as penetration testing – if you plan and design your implementation with security in mind, you can reduce the chances of severe security flaws at the end.
I extend this to not only software development projects but any IT projects, even hardware projects like networking.
IT projects generally follow a plan, design, implement and operate methodology. Testing is usually done at the end. But if at every stage I cater for security, then I will end up with an implementation that is secure by design and we do not have to retrofit security features afterwards.
This means planning for all aspects of security at the planning stage and ensuring that the design caters specifically for security as a requirement. That at implementation, security practices are being followed, and at operations, it is understood what needs to happen to maintain security.
I’ve seen too many implementations where service accounts were running with weak passwords, and that’s because, in initial setup, a simple password was used that became increasingly difficult to change as the project went along. At the end, an audit flagged the weak account password (actually it flagged that everyone knew the password first, then realised the weakness) and had to go through a painful process of changing the passwords across the deployment.
This is what I’ve been trying to do within my own enterprise in attempting to build that culture of planning and designing around quality and security. But old ways are set. But if we want to be agile, then we need to develop methods of testing during the entire project lifecycle.
Let’s move it to the left.