7. Automated Application Security Testing

Introduction and Context

DevSecOps treats security as a continuous engineering responsibility rather than a final inspection performed immediately before release. Automated application security testing is central to this approach because modern software is assembled from source code, third-party libraries, APIs, containers, cloud resources, infrastructure definitions, and dynamically configured services. Each of these elements creates opportunities for defects and vulnerabilities. Testing must therefore be distributed across the software delivery lifecycle and must produce results that developers, security specialists, operations teams, and managers can interpret and act upon.

Security testing automation does not mean that every available scanner should be executed against every commit. Excessive scanning can slow delivery, create alert fatigue, and produce large numbers of findings that are technically correct but operationally unimportant. Effective DevSecOps combines different testing techniques according to their purpose, timing, coverage, confidence, and cost. It also connects findings to ownership, exploitability, business impact, remediation workflows, and feedback loops.

This chapter examines the principal forms of automated application security testing: static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST), software composition analysis (SCA), API security testing, fuzz testing, container security testing, and infrastructure-as-code (IaC) security testing. It also explains how these techniques can be integrated into pipelines, how false positives can be managed, and how remediation can be prioritized using evidence rather than severity labels alone.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Distinguish the purposes, strengths, and limitations of SAST, DAST, IAST, SCA, API, fuzz, container, and IaC testing.

2. Select security tests appropriate to application architecture, delivery stage, and risk profile.

3. Design a layered testing workflow for a DevSecOps pipeline.

4. Interpret findings using confidence, exploitability, exposure, business impact, and reachability.

5. Reduce false positives without weakening security controls.

6. Establish developer feedback and remediation processes that support rapid, accountable correction.

7. Evaluate governance, ethical, regulatory, and operational issues in automated security testing.

The Testing Landscape: Different Questions Require Different Tests

A security test is useful only when its question is understood. SAST asks whether insecure patterns or data flows exist in source code, bytecode, or binaries. DAST asks how a running application behaves when it receives crafted requests. IAST observes application execution from within the running process. SCA examines the risks associated with open-source and proprietary dependencies. API testing examines interfaces, schemas, authentication, authorization, and business logic. Fuzzing explores application behavior using unexpected, malformed, or high-volume inputs. Container testing examines images and their operating-system and application contents. IaC testing evaluates declarative definitions for insecure configurations before cloud resources are created.

These methods overlap, but they do not substitute for one another. A SAST tool may identify a potentially unsafe SQL construction without proving that the endpoint is reachable from an attacker-controlled network. A DAST tool may discover an exposed endpoint but fail to identify vulnerable code paths that require unusual authentication or business sequences. SCA may report a vulnerable library, although the vulnerable function is not reachable in the deployed application. Container scanning may find an operating-system package vulnerability that is mitigated by the application’s runtime restrictions. Sound interpretation therefore requires technical context.

A useful model is to view testing as a set of evidence-producing activities. Each finding should ideally answer five questions: What asset is affected? What weakness exists? Can an attacker reach it? What could be achieved? How confident are we that the result is valid? These questions support risk-based decisions more effectively than a scanner’s severity category alone.

Static Analysis: Examining Code Before Execution

SAST

Static Application Security Testing analyzes source code, bytecode, or compiled artifacts without executing the application in its normal runtime environment. SAST tools use pattern matching, abstract syntax trees, control-flow analysis, data-flow analysis, and taint analysis. Taint analysis follows data from a source, such as an HTTP parameter, to a sensitive sink, such as a database query, command interpreter, file operation, or HTML response.

SAST is valuable early in development because it can identify vulnerabilities while the relevant code is being written. A pull-request scan may detect hard-coded credentials, unsafe deserialization, path traversal, weak cryptography, injection risks, and insecure error handling. Results can be linked to the exact file and line, enabling developers to correct problems before they are integrated.

Its limitations are equally important. Static analysis may lack runtime configuration, fail to understand framework-specific behavior, or report a dangerous pattern that is neutralized elsewhere. It can also miss vulnerabilities whose meaning depends on deployment topology, authorization state, or business logic. SAST quality depends heavily on language support, framework modeling, rule quality, and configuration.

SAST should be integrated progressively. Fast, high-confidence rules are suitable for pull requests; deeper whole-repository analysis can run on a scheduled basis or at release gates. Teams should establish a baseline for accepted legacy findings while preventing new high-risk findings from entering the codebase.

DAST

Dynamic Application Security Testing evaluates a running application from the outside. A scanner may crawl pages, submit forms, send malicious payloads, inspect responses, and test common weaknesses such as injection, cross-site scripting, insecure headers, exposed files, and authentication misconfiguration. Because DAST interacts with a deployed system, it can reveal vulnerabilities that are visible only through runtime behavior.

DAST is especially useful in integration, staging, and pre-production environments. Authenticated scanning is essential for applications whose sensitive functionality is not publicly accessible. Test accounts should represent different roles so that authorization boundaries can be examined. Test data must be synthetic or carefully controlled, and scanning must be rate-limited to avoid service disruption.

DAST commonly suffers from incomplete coverage. Crawlers may not discover routes hidden behind client-side navigation, complex workflows, or event-driven interactions. A scanner may also identify a symptom without explaining the vulnerable code location. DAST should therefore complement, not replace, code-level analysis and targeted manual review.

IAST

Interactive Application Security Testing instruments or observes an application while it is running and being exercised by functional tests, DAST, or user-journey tests. Because the tool can observe internal execution, it may connect an external request to a code path and sensitive operation more precisely than a purely external scanner.

IAST can improve confidence and reduce some false positives because it combines runtime evidence with internal context. It is useful in integration testing when automated test suites exercise important functions. However, its coverage depends on the quality of those tests. An untested authorization branch remains unobserved. Instrumentation can also affect performance, compatibility, privacy, or build complexity. IAST is therefore most effective when treated as an additional source of evidence rather than a universal replacement for SAST or DAST.

Dependencies, Interfaces, and Generated Inputs

Software Composition Analysis

Software Composition Analysis inventories direct and transitive dependencies, matches them against vulnerability and license information, and supports software bill of materials (SBOM) generation. Modern applications frequently contain more third-party code than original code, making dependency governance essential.

An SCA finding should be interpreted using more than the published vulnerability severity. Important factors include whether the affected component is actually present in the shipped artifact, whether the vulnerable function is reachable, whether a fix is available, whether the component is exposed, and whether compensating controls exist. Dependency versions must also be verified accurately; imprecise version detection creates both false alarms and missed vulnerabilities.

SCA operates at several points: during dependency resolution, in pull requests, during image construction, and against deployed artifacts. Organizations should define policies for vulnerable direct dependencies, transitive dependencies, abandoned packages, prohibited licenses, and exceptions. Lock files, private registries, dependency pinning, update automation, and SBOMs improve traceability.

API Security Testing

APIs are security boundaries, not merely technical connectors. API testing should validate authentication, authorization, input validation, rate limits, schema conformance, error handling, object-level access control, mass assignment protection, and business workflows. It should include positive and negative tests and should use an API specification such as OpenAPI as a testing source where appropriate.

A particularly serious class of API weakness occurs when a user can access or modify another user’s object by changing an identifier. Automated tests can create two users, record ownership of an object, and verify that the second user cannot retrieve or alter it. Such tests are more meaningful than simply checking whether an endpoint returns a response code. API testing should also examine token audience and expiry, privilege transitions, replay behavior, pagination limits, and excessive data exposure.

Fuzz Testing

Fuzz testing supplies unexpected, malformed, random, mutated, or boundary-case inputs and observes crashes, hangs, memory errors, resource exhaustion, and incorrect behavior. Mutation-based fuzzing modifies valid inputs, while generation-based fuzzing constructs inputs from a grammar or schema. Coverage-guided fuzzing uses execution feedback to explore new paths.

Fuzzing is particularly effective for parsers, file processors, protocol handlers, serialization libraries, and APIs. It requires an oracle: a way to recognize failure. Oracles may include crashes, invariant violations, unexpected status codes, resource thresholds, or security assertions. Fuzzing can generate large volumes of results, so deduplication, reproducibility, corpus management, time limits, and triage procedures are essential.

Securing the Delivery Substrate

Container Security Testing

Container testing should examine both the image and its runtime assumptions. Image analysis identifies vulnerable operating-system packages, application dependencies, embedded secrets, unsafe permissions, unnecessary tools, and configuration weaknesses. Policy checks may also verify non-root execution, immutable or minimal base images, restricted capabilities, read-only filesystems, and approved registries.

An image vulnerability is not automatically an exploitable application vulnerability. Interpretation requires knowledge of whether the affected package is installed, loaded, reachable, and exposed in the deployed container. Nevertheless, high-risk findings in externally reachable images deserve urgent attention because containers are often rebuilt frequently and can be patched through base-image updates.

Scanning must occur at build time and, where appropriate, in registries and deployment admission controls. Runtime monitoring remains necessary because image scanning cannot detect every kernel, orchestration, credential, network, or workload behavior issue.

Infrastructure-as-Code Security Testing

IaC security testing analyzes definitions for cloud and platform resources, including Terraform, Kubernetes manifests, Helm charts, CloudFormation, and policy files. It can identify publicly accessible storage, unrestricted network rules, missing encryption, excessive identity permissions, disabled audit logging, insecure Kubernetes privileges, and unprotected secrets.

IaC scanning is most valuable before deployment because remediation is cheaper and safer in version-controlled configuration than in a live environment. However, static IaC analysis may not fully evaluate variables, modules, inherited policies, provider defaults, or interactions among resources. A plan-aware scan, policy-as-code, and post-deployment validation provide stronger assurance.

A Layered Pipeline for Automated Testing

A practical pipeline separates tests according to speed and purpose. On a developer workstation or pre-commit hook, lightweight secret detection, dependency checks, formatting-related security rules, and selected SAST checks can provide immediate feedback. Pull-request checks can add high-confidence SAST, SCA, IaC validation, API contract tests, and container checks. Integration stages can execute IAST, authenticated DAST, API authorization tests, and selected fuzz campaigns. Release or scheduled stages can perform comprehensive DAST, deep dependency analysis, image verification, and broader adversarial testing.

Gates should be risk-based. Blocking every medium-severity informational result encourages bypasses and exceptions. A more mature policy may block a new critical finding with high confidence and confirmed exploitability, require review for a high-risk reachable issue, and record lower-risk findings for planned remediation. Emergency releases should use an auditable exception process with an owner, justification, expiry date, and compensating controls.

Results should be normalized into a common vulnerability-management system. The system should preserve the original evidence, map findings to repositories and services, assign ownership through code or service metadata, track status, and prevent duplicate tickets for the same underlying issue. Pipeline feedback must be fast enough to influence the developer who introduced the change.

Interpreting Findings and Controlling False Positives

A false positive is a reported condition that does not represent a security issue in the relevant context. False positives arise from incomplete program understanding, framework behavior, unreachable code, generated code, inaccurate dependency matching, or missing deployment context. They consume attention and can cause teams to ignore genuine weaknesses.

False-positive management should not mean deleting inconvenient findings. A disciplined process includes validation, classification, documented suppression, periodic review, and rule improvement. Suppression should be narrow and explain why the result is not exploitable or is otherwise controlled. It should identify an owner and, where appropriate, an expiration date. Blanket suppression of a rule across a repository is generally unsafe unless its applicability has been formally disproven.

Confidence and severity should be separated. Severity estimates potential impact; confidence estimates the likelihood that the finding is valid. A high-severity, low-confidence result may require rapid investigation, while a medium-severity, high-confidence vulnerability in a public administrative endpoint may deserve earlier remediation. Evidence such as exploit demonstrations, data-flow traces, runtime observations, reachability analysis, and asset exposure should improve decisions.

Prioritizing Remediation

Risk-based remediation can be expressed conceptually as:

Priority = impact × likelihood × exposure × confidence, adjusted for exploitability, business criticality, and available mitigation.

This is not a precise mathematical truth; it is a decision aid. Impact may include confidentiality, integrity, availability, safety, privacy, and regulatory consequences. Likelihood may consider exploit maturity, attack complexity, authentication requirements, and attacker opportunity. Exposure distinguishes an internet-facing service from an isolated development component. Business criticality accounts for revenue, essential operations, and sensitive data.

Teams should prioritize reachable vulnerabilities in production-facing assets, active exploitation indicators, exposed credentials, authorization failures, and weaknesses that permit remote code execution or significant data access. Remediation can involve upgrading a dependency, changing code, restricting network access, correcting identity policy, removing a secret, adding authorization checks, or compensating temporarily through a web application firewall or feature disablement. Compensating controls reduce risk but should not obscure the underlying defect.

Metrics should measure outcomes rather than scanner activity alone. Useful measures include mean time to remediate by risk class, age of open critical findings, percentage of findings with assigned owners, recurrence rate, false-positive rate, coverage of critical services, and the proportion of releases passing defined security gates. Metrics must not encourage teams to close findings without addressing risk.

Developer Feedback and Organizational Practice

Security feedback is most effective when it is specific, timely, and actionable. A finding should explain the weakness, show relevant evidence, describe potential consequences, identify the owning team, and provide a safe remediation pattern. Secure coding examples, reusable libraries, approved pipeline templates, and office hours reduce the burden on individual developers.

Security teams should work as enablement partners and risk stewards. Developers retain responsibility for code changes, while security specialists provide threat expertise, tool governance, and escalation support. Platform teams maintain scanners, build infrastructure, identity integration, artifact repositories, and policy enforcement. Managers resolve priority conflicts and fund remediation of systemic issues.

Feedback loops should include learning from recurring findings. If the same secret exposure appears repeatedly, a training session alone may be insufficient; secret-scanning hooks, secret managers, and improved deployment interfaces may be required. If authorization defects recur, standardized authorization middleware and security-focused API tests may provide a stronger control.

Illustrative Case Study: Securing an Online Claims Platform

Background

An insurance organization operates a cloud-based claims platform composed of web applications, REST APIs, containerized services, and infrastructure managed through Terraform. The platform is updated several times each week. Previous security reviews were performed before major releases and frequently produced large reports that developers addressed late in the cycle.

Situation and Problem

A new release passed the existing SAST scan but later disclosed customer claim metadata through an API endpoint. At the same time, the organization received hundreds of dependency and container findings, making it difficult to identify the most urgent issues. Security leaders wanted stronger automation without creating a pipeline that developers would bypass.

Analysis

The incident revealed three weaknesses. First, the existing SAST rules detected dangerous coding patterns but did not test object-level authorization. Second, DAST ran without authenticated multi-user workflows and therefore did not exercise the vulnerable claim-access path. Third, SCA and container results were prioritized almost entirely by published severity, without reachability or internet exposure.

Approach

The organization introduced a layered process. Pull requests received high-confidence SAST, SCA, secret detection, IaC checks, and API schema validation. Integration tests created two customer accounts and verified that each account could access only its own claims. Authenticated DAST and IAST ran against a staging environment using role-specific test accounts. Container scans distinguished reachable runtime packages from unused build packages, while critical base-image issues blocked release.

A finding service connected repository ownership, service criticality, deployment exposure, and vulnerability evidence. A new critical finding with high confidence blocked the pipeline. Existing accepted findings were baselined with owners and review dates. API authorization failures received higher priority than a non-reachable library vulnerability in an internal build image.

Outcome

The platform team reduced duplicate alerts and improved the proportion of findings with clear owners. More importantly, authorization testing became part of every relevant service’s regression suite rather than a one-time security exercise. The organization did not eliminate manual review; instead, automated evidence allowed specialists to concentrate on business logic, threat modeling, and unusual attack paths.

Learning Points

The case demonstrates that a successful program depends on test diversity, workflow-aware API testing, contextual prioritization, and governance of exceptions. Automation is valuable not because it replaces expertise, but because it makes repeatable evidence available earlier and more consistently.

Challenges, Governance, and Professional Responsibilities

Automated testing creates operational and ethical responsibilities. Scanners must be authorized to access environments, and fuzzing or DAST must not be directed at third-party systems without permission. Test data should avoid exposing real personal information. Credentials used by scanners require least privilege, rotation, monitoring, and secure storage. Findings should be protected because vulnerability reports can themselves become high-value attack information.

Regulated organizations may need evidence of secure development, vulnerability management, change control, software provenance, and timely remediation. SBOMs, signed artifacts, audit logs, exception records, and policy histories can support governance, but compliance evidence should not be confused with security effectiveness. Teams must also consider accessibility, privacy, discriminatory impact of automated decisions, and the risk that security gates disproportionately burden smaller teams without platform support.

Common mistakes include selecting tools before defining risks, scanning only source code, treating severity as priority, running unauthenticated DAST against authenticated applications, failing to scan deployment configuration, ignoring transitive dependencies, blocking pipelines on unvalidated noise, and allowing permanent exceptions. Another mistake is measuring the number of findings rather than the reduction of meaningful risk.

Emerging Directions

Security testing is becoming more context-aware. Modern platforms correlate source code, dependency graphs, SBOMs, runtime telemetry, cloud exposure, identity relationships, and deployment metadata. Reachability analysis can distinguish vulnerable but unused functions from exposed execution paths. Continuous validation can test deployed controls after infrastructure changes rather than relying only on pre-deployment scans.

Artificial intelligence is increasingly used to summarize findings, suggest remediation, generate test cases, and identify patterns across repositories. Such assistance requires human review because generated fixes may introduce new defects, misunderstand business logic, or weaken authorization. AI-generated code also increases the importance of provenance, code review, secret protection, dependency control, and regression testing.

The strongest direction is not a single superior scanner. It is the integration of multiple forms of evidence into developer-centered workflows, supported by policy-as-code, reproducible environments, artifact attestations, and continuous measurement of risk reduction.

Best-Practice Guidelines

1. Match each testing technique to the question it can answer.

2. Place fast, high-confidence checks early and deeper tests later in the pipeline.

3. Test authenticated roles and business workflows, not only public pages.

4. Combine severity with confidence, reachability, exposure, and business impact.

5. Maintain SBOMs and scan both direct and transitive dependencies.

6. Scan container images and IaC before deployment, then validate runtime posture.

7. Baseline legacy findings but prevent uncontrolled growth of new risk.

8. Document suppressions with rationale, ownership, and review dates.

9. Give developers actionable evidence and safe remediation patterns.

10. Protect scanner credentials, test data, findings, and security infrastructure.

11. Measure remediation quality and coverage rather than raw alert volume.

12. Use automation to extend expert judgment, not to eliminate it.

Chapter Summary

Automated application security testing is a layered discipline within DevSecOps. SAST examines code before execution; DAST tests running behavior; IAST adds internal runtime evidence; SCA manages dependency and license risk; API testing evaluates interfaces and authorization; fuzzing explores unexpected inputs; container testing examines images and runtime assumptions; and IaC testing identifies insecure cloud and platform definitions. Each technique has distinctive coverage and limitations.

Effective implementation places tests at suitable pipeline stages, uses risk-based gates, normalizes findings, and connects results to accountable owners. False positives must be validated and documented rather than ignored. Remediation priority should incorporate impact, likelihood, confidence, reachability, exposure, and business criticality. Developer feedback must be timely and actionable, while governance must protect environments, credentials, data, and vulnerability information. The mature objective is not maximum scanning, but reliable reduction of exploitable risk through continuous evidence and learning.

Key Terms

SAST: Static analysis of source code, bytecode, or binaries to identify potential security weaknesses without normal program execution.

DAST: Testing of a running application from an external perspective using crafted requests and observed responses.

IAST: Runtime security analysis that observes application execution while tests or requests exercise the system.

SCA: Analysis of software dependencies for vulnerabilities, licensing concerns, provenance, and component inventory.

SBOM: A structured inventory of software components and their relationships within an artifact or application.

API security testing: Evaluation of interfaces for authentication, authorization, validation, data exposure, and business-logic weaknesses.

Fuzz testing: Automated generation or mutation of inputs to discover crashes, incorrect behavior, and security defects.

Container scanning: Examination of container images and related configuration for vulnerabilities, secrets, and insecure settings.

IaC security testing: Analysis of declarative infrastructure definitions for insecure resource and policy configurations.

Taint analysis: Tracking of data from potentially untrusted sources to security-sensitive operations.

Reachability: The degree to which vulnerable code or a dependency can actually be invoked in a deployed system.

False positive: A reported security condition that is not a genuine vulnerability in the relevant context.

Exploitability: The practical likelihood and difficulty of taking advantage of a weakness.

Security gate: A pipeline condition that permits, warns on, or blocks progression according to defined security policy.

Baseline: A documented set of existing findings excluded from new-finding comparisons while awaiting remediation.

Compensating control: An alternative safeguard that reduces risk when direct remediation is temporarily unavailable.

Policy as code: Machine-readable security or compliance rules that can be evaluated automatically.

Vulnerability exception: An authorized, documented decision to defer or accept remediation under stated conditions.

Taint source: An input location considered potentially untrusted, such as a request parameter or uploaded file.

Sensitive sink: An operation where unsafe data may cause harm, such as a database query or command execution.

Review Questions

Short Answer Questions

1. What question does SAST answer, and why can it produce false positives?

2. Why is authenticated testing important for DAST and API security testing?

3. Distinguish vulnerability severity from confidence.

4. What information does an SBOM provide?

5. Why should IaC be tested before deployment?

Long Answer Questions

1. Compare SAST, DAST, and IAST in terms of timing, evidence, strengths, and limitations.

2. Explain how SCA findings should be prioritized using reachability and deployment context.

3. Design a layered security-testing workflow for a containerized web application.

4. Discuss the role of API authorization tests in detecting object-level access-control failures.

5. Explain how an organization can manage false positives without weakening security.

Analytical / Application Questions

1. A public API has a confirmed authorization flaw, while an internal image contains a high-severity but unreachable library vulnerability. Which should be remediated first, and what evidence supports the decision?

2. A team receives thousands of DAST findings because the scanner is unauthenticated and repeatedly crawls dynamic URLs. Propose a corrective testing and triage strategy.

3. A Terraform change opens a storage bucket to the internet for operational convenience. Identify the relevant testing controls, governance questions, and possible remediation options.

22. Multiple Choice Questions with Answers

Question 1

Which testing technique primarily analyzes source code without executing the application in its normal runtime environment?

A. DAST

B. SAST

C. Fuzz testing

D. Container scanning

Correct Answer: B. SAST

Question 2

Why can an SCA finding require additional analysis before immediate remediation?

A. SCA never identifies transitive dependencies

B. A vulnerable component may not be reachable in the deployed application

C. SCA applies only to infrastructure code

D. SCA cannot produce component inventories

Correct Answer: B. A vulnerable component may not be reachable in the deployed application

Question 3

Which test best examines whether one authenticated API user can access another user’s object?

A. A multi-user authorization workflow test

B. A container base-image scan

C. A compiler warning check

D. A license inventory

Correct Answer: A. A multi-user authorization workflow test

Question 4

What is a principal limitation of DAST?

A. It cannot observe any runtime behavior

B. It may fail to discover hidden or complex application workflows

C. It analyzes only dependency licenses

D. It cannot send crafted requests

Correct Answer: B. It may fail to discover hidden or complex application workflows

Question 5

Which combination provides the strongest basis for prioritizing a vulnerability?

A. Scanner name and number of lines of code

B. Severity alone

C. Impact, exploitability, exposure, confidence, and business criticality

D. Age of the repository only

Correct Answer: C. Impact, exploitability, exposure, confidence, and business criticality

Question 6

What is the most appropriate treatment of a validated false positive?

A. Delete all findings from the rule permanently

B. Document a narrow suppression with rationale and review controls

C. Block every future pipeline indefinitely

D. Ignore the finding without recording a decision

Correct Answer: B. Document a narrow suppression with rationale and review controls

Question 7

Which activity is most directly associated with fuzz testing?

A. Generating malformed or unexpected inputs and observing failures

B. Creating an SBOM from dependency manifests

C. Reviewing cloud identity policies manually

D. Comparing source files with coding style rules

Correct Answer: A. Generating malformed or unexpected inputs and observing failures

Question 8

What is the main purpose of IaC security testing before deployment?

A. To measure developer productivity

B. To identify insecure infrastructure configurations while they are still easy to change

C. To replace all runtime monitoring

D. To test only application user interfaces

Correct Answer: B. To identify insecure infrastructure configurations while they are still easy to change

Question 9

A high-severity SAST result has low confidence, while a medium-severity API authorization failure is confirmed on an internet-facing service. Which is generally the stronger immediate priority?

A. The confirmed authorization failure

B. The low-confidence SAST result automatically

C. Neither finding should be investigated

D. The finding with the longer description

Correct Answer: A. The confirmed authorization failure

Question 10

Which practice best supports effective developer feedback?

A. Providing only a numerical severity score

B. Sending all findings to a central mailbox without ownership

C. Providing evidence, affected code or endpoint, consequences, and a remediation pattern

D. Blocking every build regardless of finding validity

Correct Answer: C. Providing evidence, affected code or endpoint, consequences, and a remediation pattern