Security maintenance planning
TL;DR - plan to spend 10% of your engineering capacity on security.
“Code ages like milk, not wine.”
This - or some variant of it - is a commonly-stated refrain in technology and cybersecurity circles. And for the most part, it is true.
As software changes, the interaction of its various components, knowledge of vulnerabilities in them, and understanding regarding security best practices will evolve. Engineering tasks related to cybersecurity can include:
Triaging and fixing vulnerabilities in first-party code.
Evaluating CVEs in third-party code to determine exploitability.
Updating third-party code to fix such CVEs, as required by your vulnerability management policy.
Responding to customer and prospect security question(aires) where there is no pre-made content ready.
As a result, security is never “done” and managing the relevant risk is a continuous process. Thus, organizations are well-advised to allocate a certain amount of their engineering budget to regularly maintaining and improving the security of their application(s).
I have found that being able to plan your security allocation ahead of time with some sort of defensible number is extremely useful when communicating with business colleagues focused on revenue generation. Especially if they are skeptical regarding the value that security provides to the organization, you can can engage with them in a constructive manner, explaining roughly how much of your resources your efforts consume, as well as (hopefully - if you have been reading some of my other posts) the value of the cyber risk they mitigate. Conversely, if you are under pressure to reduce your risk exposure, you will be able to ask for additional resources in an informed manner.
“How much engineering capacity should I allocate to security,” you ask?
As is often the case, the answer will be “it depends,” but there are certainly benchmarks you can use to get a general idea.
All maintenance activities, including but not limited to security, take 30% of total development time according to one study. Such efforts include resolving functional bugs, code refactoring, and otherwise reducing technical debt. This figure rings true based on my experience, and thus it seems like security-related maintenance must be substantially less than this.
To determine how much effort you will need to conserve for any given period of time (fiscal year, sprint, release cycle), consider the following:
What is your organizational cybersecurity risk tolerance?
What are your compliance requirements as they relate to resolution of known vulnerabilities or the delivery of security-related features?
What are your customers’ demands with respect to the above?
How many methods of vulnerability detection are you using and what is their coverage?
How prone are your engineering teams to introducing security vulnerabilities into the product?
These qualitative factors will give you a general idea of the order of magnitude of the effort, and you may simply stop here if you don’t have any more time to dedicate to this estimate.
Should you decide to continue, though, you can apply a more advanced technique:
Use your bug tracking tool (Jira, ServiceNow, etc.) to specifically identify security-related issues by fields or labels.
Ensure that the state transition changes (e.g. “In Development” → “In Test”) accurately reflect when certain teams hand off issues to others.
Calculate the total amount of time security issues spend in the relevant state(s).
Divide this amount by the total amount of time all issues spent in the relevant states for your time period of interest.
Those of you who have actually worked in software development will likely have some skepticism that the time various issues spend in various states actually reflects the true amount of effort spent on them. That is understandable, and I broadly agree that these measurements will not be useful in an absolute sense (unless your organization is maniacal about tracking development metrics). What is useful though, is the relative time spent specifically on security (or other) issues compared to the total amount of time logged. This is because, while it is unlikely that the absolute amount of time recorded will be correct, unless you have reason to believe that security issues are tracked in a disproportionally sloppy way, the percentage you derive from the above calculation will give you a relatively accurate proportion.
Having done the above before, I can tell you that 10% is a reasonable number. Thus, if you don’t have the time or ability to run such a calculation yourself, feel free to use this as a straw man figure. As you mature, you can run this and other analyses yourself - potentially even at the team or individual level - to help understand what your true “spend” is like.