Introduction
It is a truism, in software engineering, that developing software is hard. Developing secure systems is even harder, as shown by the evolution in the number of vulnerabilities in software systems. As the complexity of modern software increases, so does its number of failure modes in an ever-expanding attack surface. Cybercriminals have taken notice and are increasingly focused on exploiting software vulnerabilities.
The cybersecurity market has responded with a wide range of solutions for managing and testing the security of applications (appsec), across the entire Software Development Lifecycle (SDLC.)
A wide range of tools with exotic acronyms like SAST, DAST, IAST, RASP, ASOC, and ATM are now available in the cybersecurity arsenal, promising to bring the initiative back to the defending side.
These types of tools have different capabilities and are focused on finding distinct kinds of vulnerabilities at distinct phases of the SDLC. This article is about those kinds of tools: what they are for, and how they fit into the distinct phases of the SDLC. Let’s figure this puzzle out:
Shifting Security Left
First, a word about the concept of shift-left in applicational security. To keep pace with the velocity of modern agile development, it is necessary to shift security left in relation to the SDLC phases. This practice avoids the expensive mistake of dealing with security issues at the later stages of the SDLC, or goodness forbid, in production, where the impact of a security breach can be awfully expensive or even constitute an existential risk (examples of companies that went under because of a security breach.)
Shifting security left is all about managing software security before the first line of code is even laid into a programmer’s IDE.
Although, when that first line of code is typed, a SAST tool should already be in place and integrated with the IDE to check for security defects and code quality issues early in development. When the code is first built in the CI/CD pipeline, there should already exist automatic security tests being run at code check-in or on pull requests. The results of these tests need to be centralised, correlated, and analysed, providing an overview of the software risk and its vulnerability and remediation trends as the development of the application progresses.
Automated Threat Modeling (ATM)
ATM tools streamline the process of traditional threat modeling, bringing speed and agility to the process.
Threat Modeling is the process of identifying, characterizing, and evaluating the risk of potential vulnerabilities in a system. This is done by analyzing the system’s attack surface, its data flows, and its process interactions, and is mostly useful for preventing vulnerabilities at the architectural and project levels.
Threat Modeling is focused on understanding the security properties and risks of a system by analyzing an abstract and evolving model of the system and adopting an adversarial mindset.
ATM tools automate the building of the initial model and the enumeration of vulnerabilities, weaknesses, and mitigations. They also check for compliance over multiple security frameworks and security standards like PCI-DSS, HIIPA, SOC 2, etc.
This kind of analysis should be done as an inter-team effort involving software architects, security engineers, developers, and other key stakeholders.
How does ATM fit into the SDLC?
Threat Modeling should start at the design phase of the SDLC, so that security considerations are fully integrated into all aspects of the development of the system. Early threat modeling will also help ensure that risks are avoided or mitigated at the architectural level, avoiding expensive mistakes before the development effort even begins.
Threat modeling results should also be used to produce security requirements for the application and to help determine the application sececurity testing strategy. The results should also be used to inform top-level management and key stakeholders of the cybersecurity risk associated with the application.
ATM tools continue to be useful across the entire SDLC, as they automatically update the threat model, keeping it up to date with changes in the production infrastructure and providing an excellent framework for exploring the security risks associated with the application.
Static Application Security Testing (SAST)
SAST tools are used to identify potential security flaws by looking at the application’s source code (1), usually without requiring a build and never requiring that the application be run. This is accomplished by using a multitude of methods and techniques for flagging potential issues in the source code.
Usually, a SAST tool will feature a set of independent scanners that can be parameterized regarding depth and completeness of analysis, and specifically tuned to the security requirements of the application. Individual scanners implement techniques like lexical analysis, data flow and control flow analysis, symbolic execution, and taint analysis, tracing inputs, outputs, and simulating the process execution while applying algorithms and heuristics for the detection of security vulnerabilities.
How does SAST fit into the SDLC?
Ideally, SAST tools should be used right from the beginning of the development phase and integrated into the programmers’ IDE (2), providing immediate and interactive feedback on security defects, code quality issues, and ensuring compliance with Secure Coding Standards (3).
Longer and more intensive scans should be integrated in the CI/CD pipeline and at Source Code Management (SCM) level by running batch jobs after a commit or a pull request.
This early integration has many advantages. It makes developers more independent of security specialists, speeds up manual code reviews, and can help ensure a high-quality codebase right from the start, avoiding code debt and lowering the cost of fixing security issues at later phases of the SDLC.
Dynamic Application Testing (DAST)
DAST tools are used to test for security vulnerabilities at run-time, thus they require a build of the application and a testing environment where to run it.
There are multiple classes of DAST tools, like fuzzers, attack injectors, and scanners for detecting vulnerability signatures in the application’s inputs, outputs, and process behavior. A typical DAST solution will combine all these kinds of DAST tools and provide mechanisms for writing custom tests, so that engineering and security teams can target the application’s business logic and any customized security mechanisms.
How does DAST fit into the SDLC?
Because DAST tools require a successful build of the application and a testing environment, they are mostly apt to be run after some initial development efforts, between the development and testing phases of the SDLC.
Software Composition Analysis (SCA)
SCA tools, sometimes also called Open-Source Security, are used to produce a Software Bill of Materials (SBoM) listing all the 3rd-party components and dependencies of the application. These tools are usually focused on evaluating two types of risks associated with those components: security risks and licensing risks.
Security risks are associated with known vulnerabilities in the software components; and licensing risks are associated with the legal requirements imposed by the software licenses under which the components are distributed.
SCA tools can also provide insight into the security and operational risks of 3rd-party components by doing accounting and doing trend analysis over known vulnerabilities. Plus, some tools can facilitate the analysis of the component’s release history, and provide measures for code stability or staleness, and give insight into the number and identities of code contributors.
How does SCA fit into the SDLC?
SCA tools can be used early in the design phase to analyze the risk of 3rd-party code before a specific software component has been elected as a dependency to be used in the development phase. These tools also play a key role across the entire SDLC lifecycle because they can produce a complete and accurate listing of the application’s dependencies, the so-called Software Bill Of Materials, or SBOM, track their known vulnerabilities, and produce alerts whenever a new vulnerability is discovered in a component of an application already in production.
Interactive Application Security Testing (IAST)
How does IAST fit into the SDLC?
IAST tools require interaction with the running application, initiated either by manual or automatized tests, so it fits into the testing phase of the SDLC. Nonetheless, IAST tools can and should be used during the development phase. Their use can even be extended to the production phase, if the performance impact is low and the risk of disrupting the production environment is deemed acceptable.
Runtime Application Self-Protection (RASP)
RASP tools are focused on detecting and thwarting attacks at runtime. These tools can provide telemetry and alarmistic useful for threat hunting and threat intelligence, while deploying active countermeasures designed to prevent the exploitation of existing vulnerabilities that might have illuded earlier appsec efforts.
Effectively, RASP reduces the risk of a cyberattack resulting in a data breach or a business disruption.
This is accomplished by deploying an agent in the application’s run-time environment and using attack detection mechanisms like behavioral analysis of inputs, of outputs, and of process execution; deploying memory canaries; monitoring heap allocations, etc.
RASP tools also deploy attack prevention mechanisms like address space layout randomization (ASLR), integrity verification, input filtering, anti-debugging traps, and control flow obfuscation. These kinds of mechanisms are designed to stop attacks, or at least greatly increase the effort required to exploit existing vulnerabilities.
How does RASP fit into the SDLC?
RASP tools are mostly useful at the production phase of the SDLC, because they are not particularly useful for the detection of potential vulnerabilities in Testing or QA environments, where DAST and IAST can really shine.
Application Security Orchestration & Correlation (ASOC)
ASOC tools serve as command-and-control platforms for managing applicational security.
A comprehensive appsec program needs to run a panoply of testing tools, each one potentially detecting the same security issues at different code locations.
These tools provide a centralized platform for aggregating, correlating, deduplicating, and triaging issues detected by other appsec tools. This satisfies the need to gather and match all the appsec testing results in a single place where the issues can be analyzed, corresponded with each other, and prioritized using a combination of ML automation and manual review.
Besides providing issue management functionality to security, engineering, and testing teams, these tools also feature a wide range of workflow integrations with ITSM and ticketing systems like Jira.
The orchestration functionality is used to bring applicational security to the CI/CD. This is accomplished by defining policies and providing integration mechanisms for running appsec tests, and optionally break the build if a serious vulnerability is detected.
ASOC tools also provide reporting functionality and visibility over software risk trends, compliance status, and remediation efforts.
How does ASOC fit into the SDLC?
ASOC tools are mostly useful at the beginning of the development phase of the SDLC, so that issues detected by SAST and SCA are centralized and tracked by the ASOC platform. This will ensure full visibility over risk and remediation trends since the inception of the development effort.
Conclusion
We have seen that there are a lot of important Application Security solutions, each playing a distinct role at distinct phases of the SDLC.
Although there are no silver bullets or magical solutions in cybersecurity, deploying the right tools at the right time can have a tremendous impact on the effectiveness of a software security program and in the productivity of security and engineering teams.
Because appsec tools are never one-size-fits-all, choosing the right products also requires expert-level knowledge of the solution space and thorough understanding of the project’s requirements.
As an end note, let’s never forget that building a comprehensive appsec program is hard and requires more than tools: it requires the right alignment between people, processes, and technology; It requires expertise, a sensibility for security, and support from the top-level executives down; But most of all, it requires the desire to do better and build a safer digital world.
