If your company is writing its own code — and these days, it probably is — then you need to make sure your developers are practicing secure coding so that your applications are built to be safe.
However, the traditional process of forcing developers to do continuous application security testing, often under the eyes of security teams, can be counterproductive. It may result in endless testing to find the most obscure bugs and may breed resentment between teams.
Instead, you may be better off if you train developer teams to be security-minded themselves and to designate their own "security champions" who can lead a team's efforts.
How constant security testing can be counterproductive
Developer teams have a variety of tools and testing methods available to examine code for potential security vulnerabilities. Perhaps the best-known method is static application security testing (SAST), which scans code to look for security flaws and other bugs.
SAST can be very thorough and can be used early in the software development life cycle (SDLC), but it's far from perfect. First, you'll need a different SAST tool for every programming language you use. Second, SAST can generate a lot of false positives, and your developers and security team may end up wasting a lot of time tracking down bugs that are ultimately harmless.
Another method is dynamic application security testing (DAST), which monitors programs’ inputs and outputs while they run. DAST is platform-agnostic and catches actual working flaws rather than just theoretical ones.
The downsides are that DAST works only on compiled binaries and doesn't have any insight into the internal workings of a program, treating each piece of software as an impenetrable black box. You'll see that something's wrong, but you'll have to figure out what's causing the problem on your own. You also won't be able to spot security vulnerabilities that don't immediately result in outputs or inputs.
DAST vs. SAST: Fact check on static and dynamic application security testing
A hybrid testing method is called interactive application security testing (IAST), which combines aspects of SAST and DAST. It simultaneously monitors running applications and analyzes code, spotting trouble and giving insight into what might be causing it. In theory, IAST both sees problems and shows you how to fix them.
But as with SAST, you'll likely need a separate IAST tool for each programming language you use. And as with DAST, you'll be able to use it only on working binaries rather late in your SDLC.
The bigger problem is that testing alone, whether it's SAST, DAST or IAST, can’t catch every flaw and will often generate too many potential vulnerabilities to be followed up on, many of them false positives. In other words, application testing can be both not enough and too much.
Compound those frustrations with meddling by a security team, and the entire secure-coding process may drive your developers out of their minds. "You can't simply give developers a checklist and say: 'Follow this list to be secure'," wrote Invicti's Zbigniew Banach in a February 2021 blog post. "Or rather you can — but it won't work."
How to get your developer teams trained in security
The solution is to have developer teams raise their own security awareness and build security-mindedness into their daily routine. In that way, security becomes a constant part of the overall development process instead of something than only comes up during the testing stage.
"Security is all about seeing the big picture while closing every gap, so to be effective, secure coding practices need to be absorbed deeply into the company culture," Banach wrote. "Good coding practices are like scales when learning a musical instrument or technique exercises in sports training: You should know them so well that you don't have to think about it."
To get your developers thinking constantly about security, use training courses, education and hands-on experience. There are plenty of training courses available for developers offered by Immersive Labs, Secure Code Warrior, Avatao and other providers. GitLab also offers its own training.
As for hands-on experience and overall education, those have to come from within the company itself. Security has to be stressed at every part of the development process, from laying out requirements to final delivery of code.
"Secure coding starts before the first line of code is even written," wrote Banach. "The real challenge is building a security-first development culture."
Ultimately, you want to build secure coding and a security-first mindset into an overall framework sometimes referred to as "DevSecOps," a modification to the DevOps notion of continuous coding and deployment.
Other aspects of DevSecOps can include beefing up server security, patching external programs, deploying a web application firewall and using best practices for identity and access management (IAM). You can build secure coding into your continuous integration/continuous delivery (CI/CD) pipeline of code deployment with automated testing as soon as new code is integrated into your staging servers.
Ultimately, you want secure coding to be such an integral part of your software development life cycle that you can expand the acronym to SSDLC — "secure software development life cycle." Think of SSDLC as an extra ring around the traditional SDLC cycle, as illustrated below.
"All security testing must be tightly integrated into the software development lifecycle (SDLC) so developers can get rapid feedback on security risks in their code and improve software security in the long run," wrote Invicti's Banach.
The importance of security champions
Not every single person on the development team needs to be up to their eyeballs in security knowledge and best practices. Instead, find one or more developers on your team who are genuinely interested in secure coding — and are also clear communicators who can inspire and lead other team members.
Designate those persons to be "security champions" who can monitor the development team's efforts and liaise with the security team, and then hone their security skills with extra training and face time with security personnel.
"A security champion isn't someone who wins hacking contests (though that's certainly a plus) but one who champions the security message," wrote Invicti's Meaghan McBee in an August 2022 blog post. "They work daily to relay essential updates, surface and resolve common pain points, lean in on threat and vulnerability management, and provide more clarity on security needs to everyone from leadership down."
Or, as the Infosec Institute's Stephen Moramarco put it in April 2021, a security champion "serves as both mentor and cheerleader of sorts, engaging with and encouraging all employees to learn, adopt, and remain committed to security protocols."
"These champions may not have as deep an understanding of security as someone in infosec or IT," added Moramarco, "but they know enough to answer basic questions and serve as a bridge between the infosec gurus and the ordinary employees."
It's very important for security champions to have the full support of management, whether or not the position is official or comes with extra benefits. Security champions will have to set aside part of their time to focus on security initiatives and communications with the security team and won't be able to keep up with other developers' output.
The trade-off, and management has to see this as a bonus, will be that code will be more secure and, once you factor in the time saved by not having to fix bugs, will result in less development time overall.
"Security champions are far-reaching as another line of defense between your sensitive data and the bad guys," wrote Invicti's McBee. "They're also natural communicators as they help amplify critical security messages throughout various teams — which is something organizations can't skimp on when it comes to weaving security into modern software development."
