Ok, confession time. The blog title is misleading. Software Development Lifecycles aren’t exactly “fun”, and nothing I can write will change that! It is an interesting topic though: consider that you could ask 20 different DevSecOps engineers “how do you secure your SDLC?”, and the answers you get may outline 20 different ways of doing things… and what’s even more interesting is that all 20 may be correct and valid approaches.
As with skinning cats, it’s the case that there’s more than one way to operate a secure SDLC, but in my experience, there are some fundamental building blocks that you need:
- Cultural Awareness – the success of your SDLC may hinge on whether or not your organisation as a whole has bought into the importance of security
- Secure Design – assuming you have that level of cultural buy-in, you need to embed security in your design from the outset.
- Secure Coding – it stands to reason that your secure design needs to be securely coded for it to work as intended.
- Robust Testing – less bugs at this stage usually means you’ve done a good job with the previous three – provided your security testing regime is comprehensive.
- Effective Monitoring – things change so you always need to keep an eye out for anything that goes wrong, but again, if you’ve nailed the previous stuff, you shouldn’t see many problems here, and monitoring should give you peace of mind instead of cause for concern.
Obviously, these building blocks can and will contain many different facets depending on the nature of your organisation. For example, if I was to examine Testing in detail… well, that’s a whole series of blogs in itself, and I don’t want to get too bogged down with the relative merits of SCA, SAST and DAST, etc. I think it’s fair to say though that if you stick to the fundamental building blocks listed above, and do them all well, you’ll significantly reduce the likelihood of suffering a security incident.
Of course in the real world, I’ve found it can take years to get to the stage where you’re comfortable that all of these fundamentals are being covered adequately. Your available resources are finite – headcount, time, money – and this will invariably restrict the amount of work you can do, so you can end up playing security Whack-A-Mole unless you know what to focus on. In order to establish this, there are 3 key questions you need to ask:
1 – Where is our biggest risk?
Knowing your organisation is vital to understanding which part of your Software Development Lifecycle is riskiest. Start at the beginning and evaluate how your team approaches each of the 5 building blocks in turn. Once you have identified where your weaknesses are, you can start to address them. For example, maybe you look at your development team and see a bunch of people who understand the importance of secure design and secure code. However, maybe they also use a large amount of open source libraries for their code, because… well, doesn’t everyone? Given the interdependencies that exist between libraries, this will inevitably lead to huge security vulnerabilities. You can’t change this fact, but acknowledging it is key, as you can then focus on managing these risks by using a Software Composition Analysis (SCA) tool.
2 – Can we automate?
You can have your team do everything manually. It’ll take a lot of time though. And bear in mind you’ll need to account for the manual errors that they make. And unless your manual workers are clones (which would be weird), each of them will probably do things slightly differently. That’s why it makes sense to automate where you can – you’ll get faster, error-free and more consistent results. Look at your SDLC and examine what aspects of it can be automated. It’ll pay off in the long run.
3 – Can we shift left?
If your monitoring and testing is routinely showing up issues, you can spend lots of time and money fixing these issues. But this is a response to detective work, and leads to firefighting in perpetuity. There’s always a root cause and that root cause won’t be fixed unless you shift your focus left. The earlier you can embed security into your SDLC, the less remediation you’ll have to do. Whenever you’re looking at a problem, ask yourself if you could shift the problem left… get to it earlier and before long you’ll eradicate the root cause.
Akeero can’t make your organisation adopt a strong security culture, but the fact that you’re still reading this blog suggests that at least one person in your organisation does (ie you!). What Akeero can do, through our intuitive user interface and native integrations, is allow your organisation to shift way left and embrace automated Secure Design. You can identify security and compliance requirements for complex cloud architectures in minutes, with minimum impact to existing security and development toolsets and processes.
If you’ve any feedback on the topics I’ve covered in this blog, or want to learn more about Akeero, please reach out to me – I’d love to hear from you.