Security requirements

A few years ago I was brought in to help with security for a project at a large retailer in the UK. They were building out some web APIs that listed which products a customer might want to buy, based on previous orders they’d made. One of the first questions I asked was “How are we managing GDPR requirements?”. A look of concern came across everyone’s faces. The team had done a lot of work on setting up functional requirements and tests but didn’t know security and regulatory requirements were a thing. A couple weeks of rejigging the architecture and a few late nights later, the API was updated to include “right to be forgotten” functionality.

This was hard evidence that the “shift left” mantra that security folks have been banging on about has some merit. Those late nights could have been avoided if we included security in the requirements phase of software development. Yes, that includes Agile!

The goal here is to identify risks early and embed security requirements into the project from the very start.

What happens in this phase?

Identify security requirements

Whether you use Scrum, Kanban, Waterfall, something else… it doesn’t matter. They all have steps where security requirements can be injected early on in the software development lifecycle.

Examples of security requirements:

It’s difficult to know if your security controls are working unless you test them. One thing I like to do is write my requirements so that they can be tested programmatically. For the requirements above, the associated tests might look like this:

Define success metrics

If you can’t measure it, you can’t manage it

In addition to testing your security controls against the requirements, we also need to understand what success looks like. It helps to set quantifiable goals during this phase of the SSDLC, so everyone knows what to work towards.

Some examples of success metrics:

• SAST tool shows zero vulnerabilities.
• DAST tool shows zero vulnerabilities.
• Penetration test results with all Critical, High and Medium issues remediated.
• App is onboarded to our bug bounty program.
• Compliance checklist: Ensure every requirement is tested and reviewed.

Outputs

By the end of this phase, you should have:

1. A comprehensive list of security requirements and their associated tests (in text form)
2. Clear metrics for success to track throughout the lifecycle.
3. Buy-in from all stakeholders, ensuring security isn’t just a side task but part of the plan from day one.

Skipping or rushing security requirements phase can turn a development sprint into a marathon of security fixes later on. Bake security in from the start!