DevSecOps Scanning Tools Integrated with CI/CD

It has been estimated that 90% of security incidents result from attackers exploiting known software bugs. Needless to say, squashing those bugs in the development phase of software could reduce the information security risks facing many organizations today. To do that, a number of technologies are available to help developers catch security flaws before they're baked into a final software release. They include SAST, DAST, IAST, and RASP.

SAST vs DAST

SAST, or Static Application Security Testing, also known as "white box testing" has been around for more than a decade. It allows developers to find security vulnerabilities in the application source code earlier in the software development life cycle. It also ensures conformance to coding guidelines and standards without actually executing the underlying code.

DAST, or Dynamic Application Security Testing, also known as "black box" testing, can find security vulnerabilities and weaknesses in a running application, typically web apps. It does that by employing fault injection techniques on an app, such as feeding malicious data to the software, to identify common security vulnerabilities, such as SQL injection and cross-­site scripting. DAST can also cast a spotlight in runtime problems that can't be identified by static analysis­­ for example, authentication and server configuration issues, as well as flaws visible only when a known user logs in.

SAST & DAST Are Usually Used in Tandem

SAST and DAST are often used in tandem because SAST isn't going to find runtime errors and DAST isn't going to flag coding errors, at least not down to the code line number. SAST performs well when it comes to finding an error in a line of code, such as weak random number generation, but usually not very efficient in finding data flow flaws. In addition, SAST solutions are notorious for the larger amount of false positive or false negatives. 

Abstract Interpretation: Some success in reducing or entirely eliminating false positives has been achieved with something called Abstract Interpretation. However, to get the best results, abstract interpretation algorithms need to be tailored to codes using an application's domain, which includes its architecture, how it uses certain numerical algorithms and the types of data structures it manipulates.

Despite SAST's imperfections, it remains a favorite among development teams. They like that it allows them to scan a project at the code level, which makes it easier for individual team members to make the changes recommended by the technology. it also lets them find flaws early in the development process, which helps reduce the costs and ripple effects that result from addressing problems at the end of the process.

What's more, SAST can be automated and transparently integrated into a project's workflow. That removes some of the hassle typically associated with testing apps for security and contrasts sharply with DAST where, for large projects, a special infrastructure needs to be created, special tests performed and multiple instances of an application run in parallel with different input data.

DAST, though, understands arguments and function calls so it can determine if a call is behaving as it should be. SAST can't check calls and in most cases, is unable to check argument values.

Interactive Application Security Testing (IAST)

IAST or Interactive Application Security Testing. Because both SAST and DAST are older technologies, there are those who argue they lack what it takes to secure modern web and mobile apps. For example, SAST has a difficult time dealing with libraries and frameworks found in modern apps. That's because static tools only see the application source code they can follow. What's more, libraries and third­party components often cause static tools to choke, producing "lost sources" and "lost sinks" messages. The same is true for frameworks. Run a static tool on an API, web service or REST endpoint, and it won't find anything wrong in them because it can't understand the framework.

IAST is designed to address the shortcomings of SAST and DAST by combining elements of both approaches. IAST places an agent within an application and performs all its analysis in the app in real-time and anywhere in the development process ­­ IDE, continuous integrated environment, QA or even in production.

Because the IAST agent is working inside the app, it can apply its analysis to the entire app ­­ all its code; its runtime control and data flow information; its configuration information; HTTP requests and responses; libraries, frameworks and other components; and backend connection information. Access to all that information allows the IAST engine to cover more code, produce more accurate results and verify a broader range of security rules than either SAST or DAST.

Run-time Application Security Protection (RASP)

RASP, or Run-time Application Security Protection As with IAST, RASP, or Run­time Application Security Protection, works inside the application, but it is less a testing tool and more a security tool. It's plugged into an application or its run­time environment and can control application execution. That allows RASP to protect the app even if a network's perimeter defenses are breached and the apps contain security vulnerabilities missed by the development team. RASP lets an app run continuous security checks on itself and respond to live attacks by terminating an attacker's session and alerting defenders to the attack.

An issue particular to RASP is it can create a sense of false security within a development team. They may not adhere to security best practices thinking, "If we miss something, RASP will pick it up."

The problem with technologies like IAST and RASP is they can have an adverse effect on application performance, although boosters of the tech any performance hits are minimal. An issue particular to RASP is it can create a sense of false security within a development team. They may not adhere to security best practices thinking, "If we miss something, RASP will pick it up." But even if RASP finds a flaw, the development team still has to fix the problem and while they do, the application may have to be taken offline, costing an organization time, money and customer goodwill.

Regardless of the challenges found in technologies like SAST, DAST, IAST and RASP, using them can create software that's more secure and do it in a way that's faster and more cost ­effective than tacking all security testing to the tail of the development process.