Static application security testing (or SAST) used to be a term coined by the security team, to help developers test their code early in the software development life cycle (SDLC). Unlike dynamic testing, it does not require a working application, which allows developers to identify security vulnerabilities while they code, so they can spot them as soon as they appear and fix them when it's easiest and fastest to do so. This cuts down their future workload by decreasing the backlog of issues they'll have to address later. 

Sounds too good to be true? It was. The problem with traditional SAST products is that they do not work for developers: they are too slow, with scans that can take several hours; they have poor accuracy, returning too many false positives, creating hours of wasted time as false alarms are chased down. This erodes developer trust in the tool and they require security expertise to make their output actionable in order to remediate the issues they find.

With developers increasingly pressed for time and cybercrime on the rise - global cybercrime costs are expected to reach $6 trillion in 2021 - SAST isn't something developers can afford to ignore any longer. So, how can they ensure they're using SAST in a way that helps rather than hinders their work?

Choosing the right tools for and by developers

Not all SAST tools are the same, and developers should be looking for a mix of tools that answer the needs of their project. When choosing tools for your team, here are three factors to consider:

Developers should want to work with it, causing no interruption or increased workload.

Software composition analysis works across different languages and libraries, so you should make sure the tools you choose are compatible with the languages that your team works with. Next, does it make sense for a developer to work with the new security hurdle? Using IDE plugins, it takes minimal effort to include it in their everyday working environment. Traditional SAST tools require manual import into developer tooling or take longer to provide results. Lastly, you don't want to cause more workload, so make sure the new tooling helps your team with a proactive solution to any potential security vulnerability. It helps to choose tools that are actively developed, so any issue changes are addressed, and tools which offer developer teams support, if needed.

Accuracyfirst

We cannot rule out artificial intelligence anymore in tooling such as SAST. Common feedback according to research that Snyk, a cybersecurity company, did among their customers was annoyance at the amount of false positives.

Don't slow down the SDLC

Speed is a critical differentiator to support rapid, agile development. Real-time speed allows the SAST solution to be leveraged while developers are working in the IDE, as well as during code review in the SCM, rather than a slow and unnecessary extra step. New dev-first SAST using AI models can work 10-50x faster than traditional SAST products, enabling developers to use it while they develop, rather than after, adding a slow and disruptive step to their work.

Choosing the right times

Static program analysis should be embedded across the software development life cycle (SDLC). 

For example, most Integrated Development Environments (IDEs) support plugins for linters, which give direct feedback to developers while they are working on code - although these should be run within a useful performance margin so as to provide actionable feedback without creating too many interruptions. Compiler messages should also be analysed, preferably within the IDE directly.

Another point to run analysis is before a pull request. Some IDEs - like JetBrains IntelliJ - have a list of built-in static program-checking tools that aren't suitable for constant running during standard work as they have a longer run time. The time to run them, then is before a pull request or during a code review.

But during, or just after, a pull request is a further key point for analysis. After a pull request is made, all the tool goodness from before should be rerun to inform the reviewer. Tools that have a longer run time can be used here, but make sure the reviewer knows how long they will take to generate a result so they can account for this. Analysis should also be run during daily builds and, of course, before deployment, when a full test suite that combines both static and dynamic tests should be applied.

It should be noted that static code analysis has the potential to hinder test-driven development (TDD) due to overstating the obvious, when code is deliberately being written at a lower quality. The way to allow both to work in tandem is for developers to shift left on quality - but not too far.

Actioning results and analysing SASTccessful

When analysing the efficacy of SAST, KPIs should be built around bugs fixed, not open bugs found. Focusing success around the number of possible issues will drive behaviour towards collecting more and more open bugs which will bury developers and frustrate their work. Instead, KPIs should be geared around applied fixes and the severity of issues addressed. 

The latest SAST tools, such as Snyk Code, allow developers to fix security vulnerabilities fast and in their preferred working environment, before they grow into bigger problems. But their application and the way results are handled require careful consideration, such as languages used. If developers want to make the most of their benefits they need to choose the right tools, use them at the right times and know how to act on their findings for maximum success, and a dev-first SAST tooling cannot be missed on the list.