Bottom line: Insecure applications put organizations at risk in multiple ways—financial, legal, brand damage, and more. Which is something everybody should know all the time, not just during NCSAM.
But there is a major gap between “should know” and “do know,” not to mention that many who do know still don’t do what they should. So, given that the online world in which we live remains riddled with application vulnerabilities, and that the theme of the month is “Own IT. Protect IT. Secure IT,” it makes sense to turn some extra focus on one of the most fundamental elements of how to do that: application security, or AppSec.
Secure application development is a well-established “thing.” Every major security conference features dozens of presentations or keynotes on its importance and ways to do it better. There are well-established tools to help developers “shift left,” or “build security in” to the software development life cycle (SDLC).
Know what’s in your code
For starters, if you’re going to “own IT,” you have to know what you own. While most organizations create proprietary software, virtually all—99%, according to the 2018 Synopsys Open Source Security and Risk Analysis (OSSRA) report—also use open source.
Which is why software composition analysis (SCA) is useful. It helps find open source components in an app while it’s in development.
Know how your apps will be used
Beyond knowing that, developers need to know how an app is going to be used. “The core challenge is that appropriate tooling and strategies will depend upon your development paradigm,” said Tim Mackey, technical evangelist at Synopsys.
“For example, in a highly agile DevOps-centric engineering team where the applications are deployed as microservices in containers, there are capabilities within containerized deployments that can be described as security mitigation models—the result of which are more difficult to attain when developing IoT firmware or mobile applications.”
So it’s critical for engineering teams to “understand how their applications are deployed and incorporate that info into their threat models,” he said.
Use the right tools
There are also multiple tools for software security testing throughout the SDLC: SAST (static application security testing), DAST (dynamic application security testing), IAST (interactive application security testing), RASP (runtime application self-protection), and penetration testing. They all play a role in delivering a product that, while it won’t be bulletproof (nothing is), will be secure enough to discourage all but the most motivated and expert hackers.
While it may seem like splitting hairs, it is important to note that these tools don’t “build” anything on their own, any more than a hammer, saw, screwdriver, and drill build a cabinet on their own. They help the builder.
But, of course, those tools have to be used. So do software testing tools. And the reality is that security testing is too often perceived as a drag on development—that it slows it down and makes teams less likely to meet their deadlines.
Create security requirements
One reason for that, according to Sammy Migues, principal scientist at Synopsys, is that security testing isn’t always written into the specifications for an app.
“Building security in slows you down only if you weren’t going to do it in the first place,” he said. “If you were going to build security in, then doing it takes exactly the expected amount of time. That’s not a perception issue; it’s a fact.”
He notes that while product managers specify what features an app should have, which also take time to build, nobody frets about features slowing down development.
“When the product management industry learns to write nonfunctional security requirements, then developers will build security in, allotting the proper time estimates to achieve the acceptance criteria that include building security in. So, no friction,” he said.
Tanya Janca, co-founder and CEO of her recently launched company Security Sidekick, said security tools are evolving to meet the need for speed. “The most up-to-date tools and strategies all focus around the following goals: automating as much as possible, not slowing down developers, eliminating entire bug classes and customizing solutions/fixes if you feel the need to,” she said.
But she also sees a need for a culture change to improve understanding between security and development. “When I was a developer, I never had the chance to work with a security person who knew how to build software, and I heard a lot of ‘no, you can’t do that,’ with few suggestions of what I could do,” she said. “Security still has a lot of culture around ‘no’ and gatekeeping, rather than the newer approaches (which are working quite well) of building guardrails.”
There are also incentives—or a lack of incentives—to push development teams to make security a priority. Mackey said if a software vulnerability that could have been caught and fixed leads to an exploit, it’s not the development team that suffers the consequences, at least at first. “When a security incident occurs, it’s the production operations team that bears the bulk of the cost in remediating the issue, not the development team,” he said. “The core cost to development teams occurs after the forensic analysis is complete, when they need to rework or refactor their code.”
“So anything not deemed a ‘feature’ will be perceived as a speed bump to functional feature development.”