6. Static Application Security Testing (SAST)

"SAST solutions are used to incrementally scan (test) uncompiled code for vulnerabilities during the SDLC itself. The code is still in its uncompiled state and static testing is designed to find flaws, like SQL injection, much more easily. SAST solutions are great at providing code-level guidance as to where and how to fix vulnerabilities in source code. SAST fits well into integrated development environments (IDEs), issue trackers, and build tools to support CI/CD workflows. SAST fits well in DevOps since it doesn’t introduce delays," Rose says.

[ Some common DevOps wisdom falls flat. Read 7 pieces of contrarian DevOps advice. ]

7. Integrated Application Security Testing (IAST): 

"IAST solutions are better at detecting deployment configuration flaws in running applications found during functional testing – before the application is deployed. It would be imprudent to assume that applications will be vulnerability-free after the development phase, or that code in run-time doesn’t need to be tested. IAST understands how all the pieces of an application work together and operate at runtime, so it can’t detect vulnerabilities in running applications that attackers may be able to exploit. IAST fits well into DevOps since it doesn’t introduce delays beyond the time needed to perform functional testing," Rose says.

8. Dynamic Application Security Testing (DAST): 

"DAST tools detect vulnerabilities in running applications by externally attacking the application. DAST coverage is limited to reflective types of vulnerabilities since DAST solutions are essentially blind as to what is happening inside an application. DAST results offer no code-level guidance as to where software vulnerabilities are located, making it difficult for developers to easily fix identified vulnerabilities. DAST tools can’t effectively achieve the fast turnaround times required. DAST does not fit well into DevOps since it often introduces lengthy delays," Rose says.

After all this testing, there is terminology related to what teams should do next. Here are a couple phrases you should know.

9. Rollback

“If a newly released build has introduced a bug that is detrimental to the production environment, the DevOps team may decide it’s beneficial to perform a rollback. This process reverts the build to the prior instance.This allows the user community to work unimpeded while the development team resolves the underlying issue to prepares for a new release.” – Mark Runyon, principal consultant, Improving

10. Failing forward

“If a problem does arise in a new release, the first reaction is to revert back to the most recent good version. But that may not be possible or advisable. In a fail-forward mode, a new production environment is created alongside the existing production system. Using a canary rollout process (See essential DevOps terms), traffic is gradually sent to the new system. If a problem arises, the new environment is pulled out, and original environment continues as normal. Teams can quickly identify and mitigate issues instead of falling back on old versions that create delays and slow progress.” – Rani Osnat, VP strategy, Aqua Security

[ Learn the do’s and don’ts of cloud migration: Get the free eBook, Hybrid Cloud for Dummies. ]

Pages