Securing the Software Development Lifecycle Workflow

“Here is a sponge,” the product manager tells you. “It picks up water. But I don’t want it to pick up random water that touches it! Please make sure it picks up only the right water.”

It is hard to secure a sponge, you explain. If you want fine control over what water to pick up, a turkey baster or a syringe would be more appropriate.

“Yeah, but the devs already made a sponge.”

Fixing insecure code is like trying to sew up all the holes in a sponge. Writing code that’s secure in the first place is hard, but less hard.

That’s the principle behind DevSecOps. Deal with security concerns throughout the software development workflow. That way you don’t have to scramble to sew up lots of security holes late in the cycle.

DevSecOps is an extension of DevOps, which deals with production concerns throughout the software development workflow. DevOps practices are great for releasing code that works in production faster. But the faster you release code, the faster you can release vulnerabilities.

So, how do you integrate security into your software development workflow?

Add automated tests!
Start with automated security tests. Early, not just right before production. In a 2018 survey, about 40% of 2,300 respondents said they run automated security tests throughout the entire development lifecycle.

Static Application Security Testing (SAST) is an appropriate tool here. SAST is a way to inspect an application’s source code early, when fixing vulnerabilities is easier and cheaper. It’s effective for finding vulnerabilities to many common attacks, like cross-site scripting, injection (SQL or otherwise), and buffer overflow.

Test every where, not everything
The goal is to integrate tests throughout the development lifecycle, so problems get caught early. That doesn’t mean testing every line of code over and over.

If you do SAST on nightly builds, you should probably only scan changes committed that day, not the entire source code. I’m not saying integration tests aren’t important! But automated scans over a huge codebase tend to produce more heat than light. Wasting money on cloud compute to find nothing. Or, worse, turning up false positives that waste time and break your ability to keep up with daily changes.

Don’t make your devs cry
SAST tools allow developers to scan code as they write it, so they get instant feedback on potential security problems. Think of the way hospitals put reminders to wash hands all over the place. Simple, not a hassle, reduces infections.

Hospitals don’t paint every square inch of linoleum with warning signs of irritable bowel syndrome, diagrams of which end of the scalpel is pointy, etc.

When you introduce security testing tools, it’s tempting to turn on checks for every imaginable security issue at once. Don’t! Start with one or two security checks at a time, for particularly common issues. (SQL injection vulnerabilities are a good one!) Ease your devs into making security rules part of their workflow. If you throw tons of information at people constantly, they get distracted from what’s relevant. Or they tune out all your reminders.

QA can benefit from automated tests too
Dynamic application security testing (DAST) looks for vulnerabilities while the application runs, rather than looking for vulnerabilities in the code itself. This is usually a QA department’s responsibility, rather than developers’ responsibility.
DAST can catch issues that aren’t apparent in static analysis, like poorly enforced access controls, misconfigured security, and broken authentication. If code that looks fine always worked in production, we would all be retired sipping cocktails on a beach by now.

Use Software Composition Analysis on your dependencies
Open source saves countless hours of effort. Open source also makes you vulnerable to left-pad, grad students deliberately introducing vulnerabilities so they can write a paper, and so on. Like Wikipedia, open source code is mostly pretty good, but has obscure corners written by the sloppiest people on the Internet.

A 2019 report found that 84% of applications were at least half open-source code; and that only 27% of respondents had processes for automatically identifying known flaws in open-source software.

Software Composition Analysis (SCA) tools ID open source code and map known vulnerabilities. Simple SCA tools just check the names of libraries you load. More advanced ones scan for snippets copied from known sources. Yes, everybody copy-pastes from Stack Overflow sometimes. Yes, copy-pasting from Stack Overflow can and does introduce vulnerabilities.

Train your devs on secure coding
“Developers often don’t know they’re coding in an insecure way. It still is not taught very often, and is not a priority for the development team,” writes Ryan O’Leary of WhiteHat Security. Continuous integration puts a premium on speed. Testing for security early creates friction that few devs welcome. But it’s better than a breach.