There’s a common misconception among developers that my job, as a (application) Security Engineer, is to just search for security bugs in their code. They may well have seen junior security engineers doing this kind of thing. But, although this can be useful (and is part of the job), it’s not what I focus on and it can be counterproductive. Let me explain.

If I’m coming into a company as the sole or lead application security engineer (common), especially if they haven’t had someone doing that role for a while, my first task is always to see how mature their existing processes and tooling are. If we find a vulnerability, how quickly are they likely to be able to fix it and get a patch out? The fixing-the-bug part of this is the easy part. Developers usually have established procedures in place for fixing bugs. Often, organisations that don’t have established processes for security get bogged down in the communication to customers phase: nobody knows who can sign-off a security advisory, so things tend to escalate. It’s not unusual to find people insisting that everything needs to be run past the CEO and Legal.

All this is to say that for companies with low security maturity, finding security bugs comes with a very outsized overhead in terms of tying up resources. If your security team is one or two people, then this makes it harder to get out of this rut and into a better place.

So my primary job is to improve the processes and documentation so that these incidents become a well-oiled machine, and don’t tie up resources any more than necessary. I generally use OWASP SAMM as a framework to measure what needs to be done (sticking largely to the Design, Implementation & Verification functions), but it boils down to a number of phases to raise the bar:

1. Firstly, stopping the rot. If there has not been a culture of security previously, then developers may still be implementing features in a way that introduces new security issues in future. There are few techniques as effective as having your developers know and care about security. Specific tasks here include revamping the secure development training (almost always crap, I tend to develop something in-house, tailored to the org), introducing threat modelling, and adding code review checklists/guidelines.
2. Develop internal standards for at least the following (and then communicating them to developers!):
   • Secure coding and code review
   • Use of cryptography
   • Vulnerability management (detection, tracking, prioritisation, remediation, and communication)
3. Identifying a “security champion” in each team and teaching them how to triage and score vulnerabilities with CVSS, so this doesn’t become another bottleneck on the appsec team/individual. This also helps foster the idea that security is developers’ responsibility, not something to off-load to a separate security person.
4. Securing build pipelines, and adding standard tooling: SCA first, then secret scans, and then SAST. Report-only to begin with, with regular meetings to review any High/Critical issues and identify false positives. Only start failing the build once confidence in the tool has been earned.
5. Finally, after all this is in place, then I will start actively looking for security bugs: via more aggressive SAST, DAST (e.g. OWASP ZAP), internal testing/code review, and competent external pen tests. (Often orgs have existing tick-box external pen testing for compliance, so this is about finding pentesters who actually know how to find bugs).

In both SAMM and my phases above, looking for bugs is way down the list. There will be bugs. There will be lots of bugs, and some of them will be really serious. If you go looking for them, you will find them, and that will feel good and earn some kudos. And it will make the product a little bit more secure. But if you instead wait and do the boring grunt work first to improve the security posture of the organisation, then when you do find the security bugs you will be in a better place to fix them systematically and prevent them coming back. Otherwise you risk perpetually fighting just to keep your head above water fixing one ad-hoc issue after another, which is a way to burn out and leaving the org no better off than when you joined.