What Is Application Security Testing (AST)?

Application security testing is the set of methods used to find security defects in an application, ranging from examination of its code to exercise of the running system and inspection of the components it depends on. Practitioners shorten it to AST. The work sits inside the wider discipline of application security as one activity among design, configuration and response.

Functional testing asks whether the software does what the specification says. Security testing asks what else it does, which is a question with no finite answer and therefore no passing grade. That difference governs how results get read, since a clean functional suite means the known requirements hold, while a clean security scan means only that one method found nothing this time.

Why the AST Acronyms Do Not Match the Standards

Not one of the familiar acronyms was coined by a standards body. NIST's software security group publishes its own tool classes, naming each one for the artifact it reads. A source code security analyzer is described there as a tool that reads source code and reports the weaknesses capable of becoming vulnerabilities.

Bytecode scanners sit beside that class rather than inside it, as do binary code scanners, and NIST notes that they resemble it while working at lower levels. Web application scanners are a separate class again. The market acronym that covers the first three as a single product category performs a merge the published taxonomy never made.

The four classes named so far are a fraction of the whole taxonomy. NIST's tool survey runs to more than a dozen classes with pages of their own. They range from requirements verification and architecture design through dynamic analysis, database scanning, and intrusion detection. Each carries a lifecycle phase and an action, the actions being to preclude, detect, mitigate, or react.

A reader shopping with the acronym inherits the cost of that compression. Two products sold under the same three letters can read entirely different artifacts. The useful question for a vendor is which artifact the tool ingests rather than which category it occupies.

How NIST Splits Code Review From Code Testing

NIST's Secure Software Development Framework cuts the same space along a different line again. Inside its Produce Well-Secured Software group, practice PW.7 covers review and analysis of human-readable code, defined there as source code, scripts, and anything else an organization deems human-readable. Practice PW.8 covers the testing of executable code.

Read the second definition closely, and the tidy split dissolves. Executable code under PW.8 includes binaries, directly executed bytecode and source code, so one file can fall under either practice depending on what its owner deems it to be. Each organization draws that boundary for itself, whatever tool it bought.

One further distinction in PW.7 disappears entirely from the acronyms. It separates code review, where a person looks directly at the code, from code analysis, where tools do the finding either automatically or alongside a person. A category name covering automated analysis says nothing about whether anybody read the code. PW.7 asks for expert reviewers specifically where malicious content is the concern.

What Application Security Testing Tools Actually Read

Every method is bounded by the artifact in front of it, the one rule surviving every change of vocabulary. Static analysis reads source or bytecode, which lets it reason about paths that never execute.

Dynamic testing reads requests and responses, knowing nothing of the code that produced them. Interactive testing reads the application's own execution, which is why its findings carry a location and an observation at once. Neither of those can report on a component that was never exercised during the test.

Dependency work makes the rule plainer than any other case does. Software composition analysis reads the dependency declarations and reports what a project says it uses. A component declared but never loaded still appears in the output.

Grouping application security testing tools by acronym hides the property that matters, since nothing in a product name says what it opens and reads. The question that recovers it is what the tool opens when it runs.

Can One Tool Cover Application Security Testing?

NIST built a way of asking that question and then declined to answer it. Its Static Analysis Tool Exposition has run six times since 2008, most recently reported in September 2019, with participating vendors running their analyzers over a set of programs while NIST-led researchers examine the outputs. The stated purpose is not to evaluate or choose the best tools, on the grounds that tools have different strengths. A disclaimer carries the same position onto the class pages, noting that naming a product does not imply "that the products are necessarily the best available for the purpose."

What it offers instead is a method others can use to work out which tools fit their own requirements. The three goals listed are empirical research on large test sets, improvement of the tools themselves, and public awareness built by demonstrating them against real software. None of those is a ranking, and the framework leaves the same decision open in the same way.

PW.7.1 asks an organization to settle whether code review, code analysis, or both should be used, and PW.8.1 asks the same about executable code along with which types of testing to apply. One of PW.8's examples goes further, asking that test plans account for the infrastructure and technology stacks the software will run on in production. Each practice then expects the issues found to be triaged into the team's existing workflow, with a remediation attached. Buying a tool satisfies none of that on its own.

Treating application security testing as a shopping list inverts the order the standards use. They ask which questions the software needs answered, then what will answer them, and last of all where the answers go.

Every method above reads something other than the running application under real traffic. Raven works from inside the process while production requests move through it, so what executed, what it touched, and where it happened arrive together. Book a demo to see that view of your own stack.

‍