Part 1 of the security requirements series
When it comes to a new feature, software teams can usually describe what it does in a single sentence, but few can say where its security requirements are kept. In many organizations, teams never write these down for each ticket, leaving the feature’s protections up to whatever each developer remembers.
This is the first post in a three-part series about what that leads to, and it follows one ordinary password reset story from the backlog through the rest of the series.
A ticket that looks complete
Consider this ticket, which could come from almost any development backlog.
As a customer, I want to reset my password by email so that I can get back into my account if I forget it.
It states who the user is and why they want the feature. The product owner writes the ticket and the developer builds what it describes, so the feature is released within a week with no sign that anything went wrong.
However, the ticket leaves out several details that determine whether the feature is secure.
-
The reset link must contain a token that cannot be guessed and can be used only once, and the token must expire after a short time, such as 15 minutes.
-
The response must be the same whether or not an account exists for the email address, so that attackers cannot use the form to find out who has an account.
-
The number of reset requests must be limited for each account and each IP address.
-
All active sessions must end once the password is changed.
The ticket doesn’t have any of these requirements. It’s unlikely anyone deliberately left them out, since nothing earlier in the process asked for them to be specified.
Two kinds of requirements
Most people who talk about what a feature needs are talking about functional requirements, which describe what a system must do for its users.
Security requirements describe the protections a system needs to stay safe when someone tries to misuse it, including what it must never allow.
Product owners tend to write functional requirements well because they are central to their role. However, security requirements don’t always belong to anyone in particular, so organizations expect developers to think of them or a reviewer to catch them later.
Where security requirements are found
When a team is asked where its security requirements are kept, the answer seems to be spread across several places.
-
The knowledge of the one engineer who has worked most on authentication.
-
A secure coding standard on an internal wiki that was last updated a couple of years ago.
-
A compliance framework, such as PCI DSS or OWASP ASVS, that applies to the organization as a whole but was never matched to individual tickets.
-
A penetration test report that covered a different feature.
All of these contain useful security information, but none of them is in the ticket the developer is working from, so developers often cannot use it while building the feature.
Why requirements go unwritten
Working out what’s needed isn’t particularly difficult for someone who understands how account recovery is attacked and how the feature works. They could probably write the requirements in about ten minutes.
The harder part is getting that person involved. People with the relevant understanding are generally busy, and a password reset story doesn’t look unusual enough to warrant a security review. In many cases, nobody asks for their input, so the requirements do not get added to the ticket. There’s no process to ensure they get written down.
What happens when a requirement is missing
Without a written requirement, there’s nothing to check the finished code against, making it harder to find missing controls.
Token expiry is a good example. If the requirement isn’t documented, whether a developer adds it depends on what they already know. A reviewer may overlook it while checking the rest of the change, and automated scanners might not report it because a missing business rule doesn’t fit a standard vulnerability category.
If an auditor asks how the organization makes sure reset tokens expire, saying experienced developers handle it isn’t much of an answer. It doesn’t show that the requirement is consistently met.
Documenting the requirement gives everyone who works on the feature the same reference point. Otherwise, each person relies on their own knowledge and memory, which differ from person to person.
What changes with AI-assisted development
For most of software’s history, teams could live with this situation. Software changed at a pace that let experts review a manageable share of the work, and the code volume was small enough for people to read most of it.
Today, many teams face a very different situation. When more code is produced in less time, relying on individual developers to remember every security requirement becomes harder to sustain. Requirements need to be part of the development process, so that security doesn’t depend on who happens to work on a ticket.
The next post in this series continues the password reset story with an AI coding assistant building the feature, and explains why requirements that weren’t written down become a larger problem.
Supporting secure software development
SecureFlag helps organizations improve application security by giving developers the expertise and practical skills to build more secure software. It supports development and security teams with hands-on training, automated threat modeling with ThreatCanvas, and tools that bring security into everyday engineering workflows.
