# AppSec Santa — Guides (Plain-Text) This file lists the canonical 'What is X' educational guides on AppSec Santa. For tools, research, and category hubs see the parallel /llms-*.txt files. All content is authored by Suphi Cankurt and may be cited with attribution to AppSec Santa (appsecsanta.com). Base URL: https://appsecsanta.com License: Content may be cited with attribution --- # What is AI Security? URL: https://appsecsanta.com/ai-security-tools/what-is-ai-security Description: AI security protects LLM applications from prompt injection, jailbreaks, and model attacks. Covers OWASP Top 10 for LLMs, red teaming tools, and guardrails. ## What AI security means {#what-ai-security-means} AI security is the practice of protecting artificial intelligence systems from adversarial attacks, misuse, and unintended behavior. It covers everything from preventing prompt injection in chatbots to scanning ML model files for malicious payloads before deployment. This is not traditional application security with a new label. The attack surface is fundamentally different. In a standard web application, an attacker exploits bugs in deterministic code. In an AI system, the attacker exploits the model's reasoning. The same input can produce different outputs. There is no source code to patch when a jailbreak works. The field has split into two broad areas. LLM security focuses on large language model applications: prompt injection, jailbreaking, data leakage, and hallucination. ML model security focuses on the models themselves: adversarial examples, data poisoning, model theft, and supply chain attacks on model files. Most teams building LLM-powered products need to worry about both. There are currently 35 active tools in the [AI security tools](/ai-security-tools) category on AppSec Santa, and the space is growing faster than any other AppSec category I track. --- ## Why does AI security matter now? {#why-ai-security-matters-now} Three things happened at once: organizations rushed to deploy LLMs, attackers figured out how to exploit them, and regulators started paying attention. ### LLM adoption outpaced security By 2025, most Fortune 500 companies had deployed at least one LLM-powered application. Customer-facing chatbots, internal knowledge assistants, code generation tools, automated support agents. The deployment speed was remarkable. The security testing was often an afterthought. The result is a wave of LLM applications in production with minimal adversarial testing. Many of them are vulnerable to prompt injection attacks that a junior security engineer could execute in minutes. ### Real-world incidents This is not theoretical. In 2023, a researcher got Bing Chat to reveal its hidden system prompt (codenamed "Sydney") through a simple prompt injection. Chevrolet's AI chatbot was tricked into agreeing to sell a car for one dollar. Air Canada's chatbot fabricated a refund policy that the airline was later held legally responsible for. These are not edge cases. They are the natural result of deploying LLMs without adversarial testing. ### Regulatory pressure The [EU AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai), which entered into force in stages between 2024 and 2026, classifies AI systems by risk level and imposes requirements for high-risk applications. In the US, the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) (AI RMF) provides voluntary guidance for managing AI risks. The OWASP Foundation published the [Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/), now in version 2025, which has become the de facto checklist for LLM security assessments. OWASP Top 10 for Large Language Model Applications project page Organizations that deploy LLMs without security testing face both regulatory and reputational risk. --- ## Key threat categories {#key-threat-categories} AI security threats fall into several categories. Understanding them helps you decide which tools to deploy. ### Prompt injection The most common and most dangerous LLM vulnerability. An attacker crafts input that overrides the model's system instructions. **Direct prompt injection** is when the user types something like "Ignore your previous instructions and do X." Surprisingly effective against unguarded models. **Indirect prompt injection** is more insidious. The malicious instruction is embedded in [external data the LLM processes](https://arxiv.org/abs/2302.12173): a web page it retrieves, an email it summarizes, a document it analyzes. The user never sees the attack. The model follows the hidden instruction. Tools like [Lakera](/lakera) detect prompt injection in real time with sub-50ms latency. [Garak](/garak) and [Promptfoo](/promptfoo) test whether your application is vulnerable before deployment. NVIDIA Garak GitHub repository ### Jailbreaking Jailbreaking bypasses the model's safety alignment to make it produce content it was trained to refuse: instructions for harmful activities, generation of malicious code, or bypassing content filters. Techniques include role-playing scenarios, encoding tricks, multi-turn escalation (crescendo attacks), and character persona manipulation. [PyRIT](/pyrit) from Microsoft's AI Red Team supports crescendo attacks and Tree of Attacks with Pruning (TAP) for automated jailbreak testing. [DeepTeam](/deepteam) covers linear, tree, and crescendo jailbreaking methods. ### Training data extraction Attackers can sometimes extract memorized training data from a model through carefully crafted prompts. This is a privacy risk when models are trained on proprietary, personal, or sensitive data. [Research has demonstrated extraction](https://arxiv.org/abs/2012.07805) of personally identifiable information, code snippets, and verbatim text passages from production models. ### Data poisoning If an attacker can influence training data, they can introduce backdoors or bias into the model. This is most relevant for organizations that fine-tune models on their own data. A poisoned training set can make the model behave normally on most inputs but produce attacker-controlled outputs for specific triggers. ### Model theft and inversion Model extraction attacks reconstruct a model's parameters by querying it systematically and analyzing the outputs. Model inversion attacks use a model's outputs to infer properties of its training data. Both are concerns for organizations that have invested in proprietary model development. ### Supply chain attacks on ML models ML model files ([pickle](https://huggingface.co/docs/hub/security-pickle), PyTorch, ONNX) can contain embedded malicious code that executes when the file is loaded. This is the AI equivalent of a compromised npm package. [Protect AI Guardian](/protect-ai-guardian) and [HiddenLayer](/hiddenlayer) scan model files for deserialization attacks and backdoors before they reach production. Protect AI Guardian (Palo Alto Networks) product page ### Hallucination exploitation LLMs generate plausible but fabricated information. Attackers can exploit this by designing scenarios where the model's hallucinations cause real harm: fabricating legal citations, inventing API endpoints that redirect to malicious servers, or generating package names that an attacker has registered (package hallucination). ### Excessive agency When LLMs are connected to tools and APIs (agents), a compromised model can take real-world actions: sending emails, modifying databases, executing code. The OWASP Top 10 lists excessive agency as a distinct risk. [Akto](/akto) focuses specifically on securing AI agents and MCP (Model Context Protocol) servers. --- ## How do AI security tools work? {#how-ai-security-tools-work} AI security tools fall into four categories based on when and how they operate. ### Red teaming and probing These tools test your LLM application before deployment by sending adversarial inputs and evaluating the outputs. Think of them as penetration testing tools for AI. [Garak](/garak) is NVIDIA's open-source LLM vulnerability scanner with 37+ probe modules covering prompt injection, jailbreaks, data leakage, and hallucination. [Promptfoo](/promptfoo) is an evaluation and red teaming CLI with 50+ vulnerability types, used by 300,000+ developers. [PyRIT](/pyrit) is Microsoft's framework for multi-modal AI red teaming across text, image, audio, and video. [DeepTeam](/deepteam) covers 40+ vulnerability types mapped to the OWASP Top 10 for LLMs. Promptfoo GitHub repository For a detailed comparison of the two most popular open-source options, see [Garak vs Promptfoo](/ai-security-tools/garak-vs-promptfoo). For a practical guide to building and running red team exercises against LLM applications, see the [LLM red teaming guide](/ai-security-tools/llm-red-teaming). ### Guardrails and filters These tools sit between the user and the model in production, filtering inputs before they reach the LLM and scanning outputs before they reach the user. [Lakera](/lakera) provides a real-time API with 98%+ prompt injection detection across 100+ languages. [LLM Guard](/llm-guard) offers 15 input scanners and 20 output scanners as an open-source Python library. [NeMo Guardrails](/nemo-guardrails) uses a domain-specific language (Colang) to define programmable safety policies and dialog flows. Lakera AI security platform homepage ### Runtime monitoring Runtime tools watch AI systems in production and detect anomalous behavior, adversarial inputs, and policy violations in real time. [HiddenLayer](/hiddenlayer) provides runtime defense for enterprise ML models without requiring access to model weights. [Akto](/akto) monitors AI agent workflows and MCP servers for tool poisoning and unauthorized actions. ### Model scanning These tools analyze ML model files for embedded malicious code, architectural backdoors, and deserialization vulnerabilities before deployment. [Protect AI Guardian](/protect-ai-guardian) scans 35+ model formats and has scanned over 4 million models on Hugging Face. [HiddenLayer](/hiddenlayer) ModelScanner also covers 35+ formats including PyTorch, TensorFlow, and ONNX. --- ## OWASP Top 10 for LLM Applications {#owasp-top-10-for-llms} The OWASP Top 10 for LLM Applications (2025 edition) is the most widely referenced framework for LLM security risks. Here is what each risk covers and which tools help address it. **[LLM01: Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/).** Manipulating an LLM through crafted inputs to override instructions. Covered by [Lakera](/lakera), [LLM Guard](/llm-guard), [Garak](/garak), [Promptfoo](/promptfoo). **LLM02: Sensitive Information Disclosure.** LLMs revealing confidential data from training or context. Covered by [LLM Guard](/llm-guard) (PII scanners), [Lakera](/lakera) (data leakage detection). **LLM03: Supply Chain Vulnerabilities.** Compromised model files, training data, or plugins. Covered by [Protect AI Guardian](/protect-ai-guardian), [HiddenLayer](/hiddenlayer) (model scanning). **LLM04: Data and Model Poisoning.** Tampering with training data to introduce backdoors or bias. Addressed through model scanning and data pipeline validation. **LLM05: Improper Output Handling.** Treating LLM output as trusted without validation. Covered by [LLM Guard](/llm-guard) (output scanners), [NeMo Guardrails](/nemo-guardrails) (output rails). **LLM06: Excessive Agency.** Granting LLMs too many permissions, tools, or autonomy. Covered by [Akto](/akto) (agent security), [NeMo Guardrails](/nemo-guardrails) (execution rails). **LLM07: System Prompt Leakage.** Extracting hidden system instructions through adversarial queries. Tested by [Garak](/garak), [Promptfoo](/promptfoo), [DeepTeam](/deepteam). **LLM08: Vector and Embedding Weaknesses.** Manipulating RAG systems through poisoned embeddings or retrieval manipulation. **LLM09: Misinformation.** LLMs generating false or misleading content. Tested by [Garak](/garak) (hallucination probes), [NeMo Guardrails](/nemo-guardrails) (fact-checking rails). **LLM10: Unbounded Consumption.** Denial-of-service through resource-exhausting prompts. Addressed through rate limiting and input validation. No single tool covers all ten risks. A practical approach combines a red teaming tool for pre-deployment testing with a guardrail tool for runtime protection and a model scanner for supply chain security. --- **Looking for tools?** See our complete [AI security tools comparison](/ai-security-tools) with 15 tools rated and reviewed. --- ## Getting started {#getting-started} If you are deploying an LLM application and have done no adversarial testing, here is a practical path. Run a red team scan. Pick [Garak](/garak) or [Promptfoo](/promptfoo) and point it at your LLM endpoint. Both are free, install in minutes, and will immediately show you how your application handles prompt injection, jailbreaks, and data leakage attempts. Expect to be surprised by the results. Add input/output guardrails. Deploy [LLM Guard](/llm-guard) or [NeMo Guardrails](/nemo-guardrails) as a middleware layer between users and your model. Filter prompt injection attempts before they reach the LLM. Scan outputs for PII leakage, toxicity, and hallucinated content before they reach the user. Review the OWASP Top 10 for LLMs. Walk through each risk and assess whether your application is exposed. Pay particular attention to prompt injection (LLM01), sensitive information disclosure (LLM02), and excessive agency (LLM06) if your LLM has access to tools or APIs. Scan your model supply chain. If you download models from Hugging Face or other registries, scan them before loading. [Protect AI Guardian](/protect-ai-guardian) and [HiddenLayer](/hiddenlayer) detect deserialization attacks and backdoors in model files. A malicious pickle file can execute arbitrary code the moment you load it. Test continuously. AI security is not a one-time audit. Models get updated, prompts change, and new attack techniques emerge regularly. Run red team scans in CI and monitor guardrail metrics in production. Consider the full stack. AI security does not replace traditional AppSec. Your LLM application still needs [SAST](/sast-tools) for code vulnerabilities, [DAST](/dast-tools) for runtime issues, and [SCA](/sca-tools) for dependency risks. AI security is an additional layer, not a replacement. --- ## FAQ {#faq} --- # What is API Security? URL: https://appsecsanta.com/api-security-tools/what-is-api-security Description: API security covers discovery, testing, and runtime protection for your APIs. Includes OWASP API Top 10 breakdown, testing types, and top tools for 2026. ## What API security means {#what-api-security-means} API security is the practice of protecting application programming interfaces (APIs) from misuse, abuse, and unauthorized access. It covers three layers: discovery (knowing your APIs exist), testing (finding weaknesses before attackers do), and runtime protection (blocking attacks on live API traffic). The [OWASP API Security Top 10](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) — currently the 2023 edition — is the canonical reference for the risk categories the discipline targets. API security is about finding and fixing vulnerabilities in your APIs before attackers exploit them, and stopping attacks against those APIs at runtime. APIs are not web pages. They are machine-to-machine interfaces that expose data and business logic directly. When a mobile app fetches your bank balance, it calls an API. When a partner system places an order, it calls an API. When a microservice authenticates a user, it calls an API. Every one of these interactions is a potential attack vector. The vulnerabilities that matter for APIs are different from traditional web application flaws. SQL injection and XSS still apply, but the real API-specific risks are authorization failures, excessive data exposure, and business logic abuse. A [DAST](/dast-tools) scanner might find an injection flaw in your API, but it will not catch that your `/api/users/123/orders` endpoint lets any authenticated user view any other user's orders just by changing the ID. That is [Broken Object Level Authorization (BOLA)](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/), and it is the number one risk on the OWASP API Security Top 10. API security covers the full lifecycle: auditing API specifications at design time, testing APIs for vulnerabilities during development, discovering all APIs in your environment (including the ones nobody documented), and monitoring API traffic at runtime for anomalies. --- ## Why does API security matter? {#why-api-security-matters} APIs are now the primary attack surface for most organizations. That is not a vendor talking point. It is the reality of how modern software is built. Akamai's 2025 State of the Internet report found a 33% year-over-year increase in web attacks targeting APIs, with API attacks accounting for a growing share of all web attacks. Gartner predicted in 2021 that APIs would become the most frequent attack vector by 2024, and the data supports that prediction. The breaches tell the story. [T-Mobile had 37 million customer records exposed through an API in January 2023](https://www.t-mobile.com/news/business/customer-information). Optus lost 9.8 million customer records through an unauthenticated API endpoint in 2022. Twitter had 5.4 million user records scraped through an API vulnerability that same year. These were not sophisticated zero-day exploits. They were basic authorization and authentication failures in APIs. Why does this keep happening? Organizations have thousands of API endpoints, many undocumented, and traditional security tools were not built to understand API-specific risks. A WAF might block SQL injection payloads, but it has no concept of whether user A should be allowed to access user B's data through a legitimate API call. According to Salt Security's State of API Security report, 95% of organizations experienced API security problems in production APIs in the past 12 months. The number of APIs is growing faster than security teams can manually keep up with. --- ## OWASP API Security Top 10 {#owasp-api-security-top-10} The OWASP API Security Top 10 (2023 edition) is the standard reference for API-specific risks. If you are evaluating API security tools, this is the baseline of what they should detect. ### API1:2023 — Broken Object Level Authorization (BOLA) The most common and most exploited API vulnerability. The API exposes object IDs in requests (`/api/users/123/records`), and the server does not verify that the authenticated user is authorized to access that specific object. An attacker changes `123` to `124` and gets someone else's data. It is trivially easy to exploit and invisible to traditional scanners. ### API2:2023 — Broken Authentication [Weak authentication mechanisms in APIs](https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/): missing rate limiting on login endpoints, tokens that never expire, API keys transmitted in URLs, weak password policies on API-accessible accounts. Authentication is harder to get right for APIs than for web applications because there is no browser managing sessions. ### API3:2023 — Broken Object Property Level Authorization The API returns more data than the client needs ([excessive data exposure](https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/)), or accepts property modifications it should not (mass assignment). An API that returns a user profile might include internal fields like `role` or `is_admin` that the frontend just ignores but an attacker can read. Or a user update endpoint might accept a `role` field in the request body that the UI never sends but an attacker can add. ### API4:2023 — Unrestricted Resource Consumption [APIs that lack rate limiting, pagination limits, or request size constraints](https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/). An attacker can exhaust server resources, run up cloud costs, or perform denial-of-service by calling an expensive API endpoint in a tight loop. ### API5:2023 — Broken Function Level Authorization The API does not enforce authorization at the function level. A regular user can call admin endpoints by guessing the URL pattern. `GET /api/users` is allowed for everyone, but `DELETE /api/users/123` should only work for admins, and [the API does not check](https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/). ### API6:2023 — Unrestricted Access to Sensitive Business Flows Automated abuse of legitimate API functionality: mass account creation, inventory hoarding, automated purchasing. The API works as designed, but uncontrolled automation turns it into a vulnerability. ### API7:2023 — Server-Side Request Forgery (SSRF) The API accepts a URL as input and fetches it server-side. An attacker points that URL at [internal services, cloud metadata endpoints, or other resources the server can reach but the attacker cannot](https://cwe.mitre.org/data/definitions/918.html). ### API8:2023 — Security Misconfiguration Missing security headers, verbose error messages, unnecessary HTTP methods enabled, CORS misconfiguration, default credentials on API gateways. The same category as web misconfiguration, but API-specific configurations add more surface area. ### API9:2023 — Improper Inventory Management The organization does not know which APIs exist, which versions are running, or which are exposed to the internet. Old API versions with known vulnerabilities stay live because nobody tracks them. This is [the shadow API problem](https://owasp.org/API-Security/editions/2023/en/0xa9-improper-inventory-management/). ### API10:2023 — Unsafe Consumption of APIs [Your application trusts data from third-party APIs without validation](https://owasp.org/API-Security/editions/2023/en/0xaa-unsafe-consumption-of-apis/). If a partner API is compromised or returns unexpected data, your application becomes vulnerable because it does not sanitize or validate the response. --- ## Types of API security testing {#types-of-api-security-testing} API security testing happens at different stages of the lifecycle. Each stage catches different problems. ### Design-time: specification auditing Before writing code, test the API specification itself. Tools like [42Crunch](/42crunch) audit OpenAPI/Swagger specs against 300+ security checks and assign a score from 0 to 100. They catch problems like missing authentication requirements, overly permissive schemas, and sensitive data in URL parameters before any code is written. This is the cheapest place to find issues. A flawed API contract produces flawed implementations across every team that builds against it. ### Build-time: SAST for APIs Static analysis applied to API code. Traditional [SAST tools](/sast-tools) catch injection flaws in API handlers the same way they do for web controllers. Some API security tools add API-specific rules: checking that authorization middleware is applied to every route, verifying that response schemas do not leak internal fields. ### Test-time: dynamic API testing Running security tests against a deployed API. This is where dedicated API security tools differ most from generic DAST. Tools like [APIsec](/apisec) and [42Crunch](/42crunch) Conformance Scan import your API specification, understand the expected behavior, and test every endpoint for deviations: authentication bypass, authorization failures, input validation gaps, and response data leakage. [APIsec](/apisec) runs 1,200+ security playbooks against APIs, including business logic tests like BOLA and RBAC violations that generic fuzzers miss. For a complete walkthrough of API testing methods and OWASP API Top 10 coverage, see the [API security testing guide](/api-security-tools/api-security-testing-guide). ### Runtime: discovery, monitoring, and protection The always-on layer. Runtime API security tools sit in the traffic path (or analyze traffic mirrors) and do the following: **Discovery** — Inventory every API in your environment by analyzing actual traffic. Find shadow APIs, zombie APIs (old versions still receiving traffic), and undocumented endpoints. **Behavioral detection** — Baseline normal API traffic patterns and flag anomalies. A user who normally calls the profile API once per session suddenly calling it 10,000 times with sequential IDs is a BOLA attack in progress. **Protection** — Block malicious requests inline. [Wallarm](/wallarm) and [Cequence](/cequence) offer native inline blocking capabilities that can stop attacks without relying on an external WAF. --- ## How do API security tools work? {#how-api-security-tools-work} API security platforms have capabilities that traditional application security tools do not. Here is what the major ones do under the hood. ### API discovery You cannot protect APIs you do not know about. Every API security program starts with discovery. Tools analyze traffic from API gateways, load balancers, cloud environments, and service meshes to build a complete API inventory. [Salt Security](/salt-security) pulls metadata from AWS, Azure, GCP, and gateways like Kong and Apigee. [Akamai API Security](/akamai-api-security) monitors both north-south (external) and east-west (internal service-to-service) traffic. The output is an inventory of every API endpoint, including its parameters, data types, authentication mechanisms, and whether it handles sensitive data like PII or financial information. ### Posture management Once APIs are discovered, posture management checks them against security standards. Are all endpoints authenticated? Do they conform to their OpenAPI specification? Are they compliant with OWASP API Security Top 10? Are they exposing sensitive data? [Akamai API Security](/akamai-api-security) maps posture against compliance frameworks. [Salt Security](/salt-security) offers a Policy Hub with roughly 100 pre-loaded posture rules covering PCI DSS, HIPAA, GDPR, and SOC 2. ### Behavioral threat detection Signature-based detection misses API-specific attacks because the requests look legitimate. A BOLA attack uses the same endpoint with the same HTTP method and valid authentication. The only difference is the object ID. API security tools use machine learning to baseline normal behavior and detect deviations. [Salt Security](/salt-security) and [Akamai API Security](/akamai-api-security) build behavioral models from traffic patterns and flag anomalies that indicate attacker activity: sequential ID enumeration, unusual access patterns across endpoints, spikes in error rates from specific clients. ### Runtime protection Some platforms go beyond detection and block attacks inline. [Wallarm](/wallarm) combines WAF capabilities with API-specific protection, handling API abuse, bot management, and DDoS protection across 160,000+ APIs. [Cequence](/cequence) processes over 10 billion API interactions daily with native inline blocking and behavioral fingerprinting. --- ## API security vs DAST {#api-security-vs-dast} Generic [DAST tools](/dast-tools) can scan APIs. Most modern DAST scanners import OpenAPI specs and test API endpoints for injection flaws and misconfigurations. So why would you need a dedicated API security tool? The answer comes down to what each approach can detect. **What DAST catches in APIs:** injection vulnerabilities (SQL injection, command injection, XSS in API responses), security misconfigurations (missing headers, verbose errors, unnecessary HTTP methods), some authentication issues (weak tokens, missing rate limiting). **What DAST misses:** BOLA and BFLA (the scanner does not understand your authorization model), excessive data exposure (the scanner does not know which fields should be in the response), shadow API discovery (DAST tests known endpoints, it does not find unknown ones), business logic abuse (rate abuse, inventory hoarding, automated scraping), behavioral anomalies at runtime. If your API surface is small, a handful of internal services with clear specifications, DAST plus manual penetration testing covers most risks. Add a spec linter like [42Crunch](/42crunch) for design-time checks. If you have dozens or hundreds of APIs, external-facing endpoints, microservices architectures, or regulatory requirements around API data handling, you need a dedicated platform. Discovery, behavioral analysis, and continuous runtime monitoring are things DAST was never designed to do. --- **Looking for tools?** See our complete [API security tools comparison](/api-security-tools) with 9 tools rated and reviewed. --- ## Getting started {#getting-started} If you have not invested in API security before, here is a practical path. Know what you have. You cannot secure APIs you do not know exist. Start with an inventory. If you have an API gateway, pull the list of registered routes. If you use Kubernetes, check your Ingress and Service definitions. For a quick manual assessment, that gets you partway there. For a thorough inventory including shadow APIs, you need a tool that analyzes actual traffic. Audit your API specifications. If you have OpenAPI specs, run them through [42Crunch](/42crunch) using the free IDE extension. Fix the issues it finds. If you do not have OpenAPI specs, writing them is a valuable exercise that forces you to document authentication, authorization, and data schemas. Test your most critical APIs. Pick your highest-risk APIs: the ones that handle authentication, payments, or personal data. Run them through [APIsec](/apisec) or a manual penetration test focused on OWASP API Security Top 10 risks. BOLA testing alone will likely find issues. Add runtime monitoring. Deploy an API security tool that monitors traffic to your APIs. Start with discovery to validate your inventory, then enable behavioral detection. [Salt Security](/salt-security), [Akamai API Security](/akamai-api-security), and [Wallarm](/wallarm) all offer this. Integrate into CI/CD. As your API security program matures, add specification auditing and security testing to your pipeline. [42Crunch](/42crunch) conformance scans and [APIsec](/apisec) automated testing both integrate with CI/CD systems. Do not try to do everything at once. Inventory first, test the critical APIs, add monitoring, then automate. You will find real issues at every step. --- ## FAQ {#faq} **What is API security?** API security is the practice of protecting application programming interfaces (APIs) from misuse, abuse, and unauthorized access across discovery, testing, and runtime layers. It targets the risks captured in the OWASP API Security Top 10 — broken object-level authorization, broken authentication, excessive data exposure, and the rest — using a mix of design-time, development-time, and production-time controls. **What is the OWASP API Top 10?** The OWASP API Security Top 10 is the canonical risk reference for APIs, published by the Open Web Application Security Project. The current version is the 2023 edition, which lists BOLA (broken object-level authorization), broken authentication, broken object property level authorization, unrestricted resource consumption, broken function-level authorization, unrestricted access to sensitive business flows, server-side request forgery, security misconfiguration, improper inventory management, and unsafe consumption of APIs as the top risks. I dig deeper into each in my [API security testing guide](/api-security-tools/api-security-testing-guide). **How is API security different from web application security?** Web application security tools — including most [DAST](/dast-tools) scanners — were built for HTML pages, browser sessions, and form-based input. APIs expose machine-to-machine endpoints with structured payloads, and the highest-impact risks (BOLA, broken function-level authorization, business-logic abuse) are not detectable by signature-based web scanners. The "API security vs DAST" section above covers this in more detail. **What are the 9 types of API testing?** The discipline usually divides into nine types: validation testing (request and response shape), functional testing (does the endpoint behave correctly), UI testing (the consuming client), load testing (volume and concurrency), runtime testing (live traffic monitoring), security testing (OWASP API Top 10 scans), penetration testing (manual or automated adversary simulation), fuzz testing (malformed input generation), and interoperability testing (third-party integrations). Most modern API security tools combine three or four of these — typically discovery, security testing, runtime monitoring, and fuzz testing. **How do you test API security?** Start with the API inventory — most teams underestimate the count by 30–40% once shadow APIs are included — then layer security testing for OWASP API Top 10 categories on top, and finally add runtime monitoring against the live traffic. Tools like [42Crunch](/42crunch) handle contract-first conformance, [APIsec](/apisec) automates pentests against running endpoints, and [Salt Security](/salt-security) or [Akamai API Security](/akamai-api-security) cover runtime detection. **What are common API security risks?** The dominant category in production incidents is broken object-level authorization (BOLA — OWASP API1:2023), where one authenticated user accesses another user's data by manipulating an object identifier. Broken authentication, excessive data exposure, lack of resources and rate limiting, broken function-level authorization, and security misconfiguration round out the risk set most teams encounter, and all six are tokenized in the [API security tools comparison](/api-security-tools). --- # What is ASPM? URL: https://appsecsanta.com/aspm-tools/what-is-aspm Description: ASPM aggregates SAST, DAST, SCA, and other scanner findings into one risk-prioritized view. Learn key capabilities, top platforms, and when your team needs it. ## What ASPM is {#what-aspm-is} Application Security Posture Management (ASPM) is a category of tools that provides a unified view of security risk across all the applications an organization develops. Instead of forcing security teams to check SAST dashboards, SCA reports, DAST results, IaC scanners, and container security tools separately, ASPM pulls all of those findings into a single pane of glass. The term was formalized by Gartner in 2023 to describe the growing need for an orchestration layer above individual AppSec tools. The problem it solves is straightforward: modern development teams generate findings from a dozen different scanners, and nobody has the time to manually correlate and prioritize thousands of alerts scattered across separate interfaces. ASPM ingests vulnerability data from across the software development lifecycle, from code commit to production runtime. It deduplicates overlapping findings, enriches them with context like asset criticality and exploit availability, and produces a prioritized risk score that reflects actual business impact rather than raw CVSS numbers. Gartner projects that 40 percent of organizations developing proprietary applications will deploy ASPM frameworks by 2026 ([Gartner, Innovation Insight for Application Security Posture Management, 2023](https://www.gartner.com/en/documents/4022323)). For organizations in regulated industries, that figure rises to 80 percent by 2027. --- ## Why does ASPM matter? {#why-aspm-matters} The average enterprise development team runs between five and fifteen distinct security tools (industry estimate). Each tool produces its own findings in its own format with its own severity scale. The result is alert fatigue, duplicated effort, and a security team that cannot answer a simple question: "What is the most important thing to fix right now?" ASPM solves three specific problems: **Alert fatigue and deduplication.** A single vulnerability in a shared library might trigger alerts in your SCA tool, your container scanner, and your IaC checker. Without ASPM, a developer might receive three separate tickets for the same issue. ASPM correlates these into a single finding. **Context-aware prioritization.** A critical CVE in a library that is only used in a test environment is not the same as a critical CVE in a library that handles payment processing in production. ASPM combines vulnerability severity with business context, asset exposure, reachability analysis, and exploit intelligence to produce a risk score that reflects reality. **Governance and visibility.** Security leaders need to report on posture across the entire application portfolio. ASPM provides dashboards and metrics that show trends over time, team-level performance, compliance coverage, and mean time to remediation, all without manual spreadsheet aggregation. --- ## What are the key ASPM capabilities? {#key-capabilities} Not every ASPM platform offers the same depth. Here are the core capabilities to evaluate: | Capability | What It Does | Why It Matters | |---|---|---| | **Tool integration** | Ingests findings from SAST, DAST, SCA, IaC, CSPM, container, secrets scanners | More integrations = more complete risk picture | | **Deduplication** | Identifies overlapping findings from multiple tools | Reduces noise by 30-70% in most deployments (industry estimate based on vendor benchmarks) | | **Risk scoring** | Combines CVSS, EPSS, reachability, asset criticality, and exploit data | Moves prioritization from severity to actual risk | | **Policy engine** | Defines rules for SLAs, ownership, and auto-triage | Enforces consistent standards across teams | | **Developer workflow** | Creates tickets in Jira, GitHub Issues, or Slack with remediation guidance | Keeps developers in their existing tools | | **Compliance mapping** | Maps findings to SOC 2, PCI DSS, NIST, ISO 27001 | Simplifies audit evidence collection | | **SBOM management** | Tracks software components across the portfolio | Supports supply chain transparency requirements | The more mature platforms also offer attack-path analysis (tracing how a vulnerability could be exploited from the internet to sensitive data) and AI-assisted remediation suggestions that reduce the time developers spend researching fixes. --- ## ASPM vs traditional tools {#aspm-vs-traditional-tools} ASPM is not a replacement for your existing security scanners. It sits on top of them. Here is how it compares to the tools you already have: | Aspect | Traditional AppSec Tools (SAST, SCA, DAST) | ASPM | |---|---|---| | **Scope** | Single vulnerability type or phase | Entire SDLC, all vulnerability types | | **Output** | Raw findings with tool-specific severity | Correlated, deduplicated, risk-ranked findings | | **Prioritization** | CVSS-based, no business context | Business impact, reachability, exploit data | | **Visibility** | Per-tool dashboards | Portfolio-wide risk posture | | **Governance** | Manual aggregation for reporting | Automated compliance mapping and SLA tracking | | **Remediation** | Developer must switch between tool UIs | Unified workflow with ticket creation and tracking | The analogy that works best: traditional AppSec tools are individual security cameras. ASPM is the monitoring room where all feeds come together and an operator can focus on what actually requires attention. One common question is whether ASPM overlaps with CSPM (Cloud Security Posture Management). CSPM focuses on cloud infrastructure misconfigurations (S3 buckets, IAM policies, network rules). ASPM focuses on application-level vulnerabilities (code flaws, dependency risks, API weaknesses). Some vendors are merging both under broader posture management platforms, but the focus areas remain distinct. --- **Looking for tools?** See our complete [ASPM tools comparison](/aspm-tools) with 15 tools rated and reviewed. --- ## Getting started {#getting-started} Adopting ASPM requires preparation. Here is a practical path: **Inventory your current tools.** List every security scanner you run, the vulnerability types it covers, and where in the SDLC it sits. This becomes your integration checklist. If you are running fewer than three tools, ASPM may be premature. **Define your risk model.** Decide what "critical" means for your organization. Which applications handle sensitive data? Which are internet-facing? Which serve revenue-generating functions? ASPM needs this business context to prioritize effectively. **Start with integration, not replacement.** Connect your existing scanners to the ASPM platform. Do not rip out tools you already use. The value of ASPM comes from correlation across tools, and that only works if the tools are feeding data in. **Establish ownership and SLAs.** ASPM is most effective when every finding has a clear owner and a remediation deadline. Map applications to teams, set SLA targets by severity, and let the ASPM platform enforce them. **Iterate on triage rules.** The first week will surface noise. Tune your deduplication rules, suppress confirmed false positives, and adjust risk weights. Most teams reach a stable configuration within the first month. **Measure progress.** Track mean time to remediation, open vulnerability counts by severity, and SLA compliance rates. ASPM gives you these metrics automatically. Use them to demonstrate value and justify continued investment. --- ## FAQ {#faq} --- # What is CNAPP? URL: https://appsecsanta.com/iac-security-tools/what-is-cnapp Description: CNAPP unifies CSPM, CWPP, and CIEM into one cloud security platform. Learn how it works, when you need it over point solutions, and the top platforms in 2026. > **CNAPP (Cloud-Native Application Protection Platform) is a unified cloud security platform that combines CSPM, CWPP, CIEM, DSPM, AI-SPM, and IaC scanning into a single product.** It correlates findings across cloud configuration, workloads, identities, data, AI assets, and infrastructure code so security teams can prioritise by attack-path risk instead of triaging the same incident across five separate tools. ## What CNAPP is {#what-cnapp-is} A Cloud-Native Application Protection Platform (CNAPP) is a unified security solution that combines cloud posture management, workload protection, identity security, and vulnerability scanning into a single integrated platform. Gartner coined the term in 2021 to describe the convergence of several previously separate cloud security categories. The problem CNAPP solves is tool sprawl. Before CNAPP existed, securing a cloud environment meant buying and managing separate products for infrastructure misconfiguration (CSPM), workload protection (CWPP), identity management (CIEM), container security, IaC scanning, and vulnerability assessment. Each tool had its own dashboard, its own alert format, and its own blind spots. Security teams drowned in alerts with no way to connect a misconfigured IAM role to a vulnerable container running in a public-facing subnet. CNAPP puts all of that context into one platform. A single risk graph connects infrastructure misconfigurations, vulnerable software, overly permissive identities, and exposed network paths. Instead of investigating six separate tools to understand one attack path, security teams see the full picture in a single view. The market has grown rapidly. Wiz, Palo Alto Networks Prisma Cloud, and Orca Security are among the leaders. Nearly every major security vendor now offers or is building a CNAPP product. --- ## Core components {#core-components} CNAPP brings together several security capabilities that used to live in separate products. Understanding each component helps you evaluate what a specific CNAPP platform does well and where it has gaps. ### CSPM (Cloud Security Posture Management) CSPM continuously monitors cloud infrastructure for misconfigurations: publicly accessible storage buckets, overly permissive security groups, unencrypted databases, disabled logging. It compares your actual cloud configuration against best-practice benchmarks like CIS and against compliance frameworks like PCI DSS, HIPAA, and SOC 2. For a detailed comparison of standalone CSPM and integrated CNAPP platforms, see the [CSPM vs CNAPP guide](/application-security/cspm-vs-cnapp). ### CWPP (Cloud Workload Protection Platform) CWPP protects the workloads running in your cloud: virtual machines, containers, and serverless functions. It handles vulnerability scanning, malware detection, runtime threat detection, and integrity monitoring. CWPP answers the question: "Is anything bad running inside my workloads?" ### CIEM (Cloud Infrastructure Entitlement Management) CIEM analyzes identity and access permissions across cloud environments. It finds overly permissive roles, unused service accounts, cross-account access risks, and privilege escalation paths. In most cloud breaches, excessive permissions are a contributing factor, and CIEM addresses that directly. ### DSPM (Data Security Posture Management) DSPM discovers and classifies sensitive data across cloud storage and databases, then maps which identities, workloads, and network paths can reach it. The output is the answer to "where is our PII / PHI / cardholder data, and who can read it?" Wiz, Prisma Cloud, and Orca Security all ship DSPM as a core CNAPP component in 2026. ### AI-SPM (AI Security Posture Management) AI-SPM is the newest CNAPP pillar, added across most platforms in 2025-2026. It inventories deployed AI models, training pipelines, and vector databases; flags shadow AI usage; and detects misconfigurations specific to AI workloads (over-permissioned model endpoints, unprotected training data, prompt injection exposure). [Wiz AI-SPM](/wiz), Prisma Cloud AI Security Posture Management, and CrowdStrike Falcon Cloud AI-SPM are the most-cited offerings. ### Additional capabilities Most CNAPP platforms also include: | Capability | What It Covers | | -------------------------------------- | ------------------------------------------------------------------------------------ | | **IaC scanning** | Detects misconfigurations in Terraform, CloudFormation, and Pulumi before deployment | | **Container and Kubernetes security** | Image scanning, admission control, runtime policies, KSPM | | **Cloud Detection and Response (CDR)** | Real-time detection of threats and suspicious activity in cloud environments | | **API security** | Discovers and monitors APIs running in cloud environments | --- ## How does CNAPP work? {#how-cnapp-works} CNAPP platforms typically use two approaches to gain visibility into your cloud environment: agentless scanning and agent-based monitoring. **Agentless scanning** connects via cloud provider APIs and reads configuration data, snapshots, and metadata without installing anything on your workloads. This gives broad visibility with minimal deployment effort. Most CNAPP platforms start here. Wiz popularized the agentless-first approach and demonstrated that you can get deep visibility, including vulnerability scanning of running workloads, without installing agents. **Agent-based monitoring** installs lightweight agents on workloads for real-time runtime protection, file integrity monitoring, and process-level visibility. Agents provide deeper runtime context but require deployment and maintenance. Most modern CNAPP platforms use both: agentless for broad posture assessment and agents for runtime protection where needed. The data from both approaches feeds into a **unified risk graph**. This graph maps relationships between cloud resources: which compute instances run which containers, which identities can access which storage, which network paths are exposed to the internet. When the platform finds a vulnerability in a container image, it checks whether that container is actually running, whether it is internet-facing, whether the identity associated with it has access to sensitive data, and whether there is a known exploit. That multi-factor analysis is what separates CNAPP from individual scanners. --- ## How does CNAPP compare to point solutions? {#cnapp-vs-point-solutions} The case for CNAPP over individual tools comes down to context and operational efficiency: | Aspect | Point Solutions (CSPM + CWPP + CIEM separately) | CNAPP | | ------------------ | ----------------------------------------------------- | ----------------------------------------------------------------------------------------- | | **Deployment** | Multiple tools to install, configure, maintain | Single platform with unified deployment | | **Risk context** | Each tool sees its own slice; no cross-correlation | Unified risk graph connects misconfigs, vulnerabilities, identities, and network exposure | | **Alert volume** | High; same issue may trigger alerts in multiple tools | Correlated; one alert per attack path, not per finding | | **Prioritization** | Severity-based within each tool | Multi-factor: exploitability, exposure, permissions, data sensitivity | | **Team overhead** | Multiple dashboards, multiple vendor relationships | Single pane of glass, one vendor to manage | | **Cost** | Sum of individual tool licenses | Typically lower total cost (bundled pricing) | The tradeoff is depth. A dedicated CSPM product may have deeper coverage of cloud provider-specific misconfigurations than the CSPM component inside a CNAPP. Similarly, a specialized container security tool may detect more runtime anomalies than a CNAPP's CWPP module. Organizations with very specific requirements in one area sometimes keep a specialized tool alongside their CNAPP. --- ## Top CNAPP tools {#top-cnapp-tools} The CNAPP market is one of the most competitive in security. Based on AppSec Santa's analysis, here are the platforms worth evaluating: - **[Wiz](/wiz)** — The fastest-growing CNAPP vendor. Agentless-first architecture that gained adoption for its speed of deployment and unified risk graph. Strong across CSPM, CWPP, CIEM, DSPM, AI-SPM, and container security. [Pending acquisition by Google Cloud](https://blog.google/company-news/inside-google/company-announcements/google-agreement-acquire-wiz/) (announced 2024, expected to close 2026). - **[Orca Security](/orca-security)** — Agentless cloud security platform covering CSPM, CWPP, CIEM, DSPM, and AI-SPM. The patented [SideScanning technology](https://orca.security/platform/agentless-sidescanning/) reads workload data directly from cloud provider block storage without agents. Strong fit for organisations that want deep visibility with zero agent deployment. - **[Prisma Cloud](/prisma-cloud)** — Palo Alto Networks' CNAPP offering. One of the broadest platforms covering code-to-cloud security, including CSPM, CWPP, CIEM, IaC scanning ([Checkov-powered](https://www.checkov.io/)), API security, AI-SPM, and runtime defense. Benefits from integration with the broader Palo Alto security ecosystem. - **CrowdStrike Falcon Cloud Security** — CNAPP module of the Falcon platform. Combines agentless cloud posture with the same agent-based runtime detection technology behind Falcon EDR. Strongest runtime detection story in the CNAPP space; deep AWS / Azure / GCP coverage. - **[Aqua Security](/aqua-security)** — One of the original CWPP vendors, now full CNAPP. Deepest container and Kubernetes security stack, plus CSPM, CIEM, and IaC scanning. Open-source roots ([Trivy](https://github.com/aquasecurity/trivy), kube-bench) give it credibility with engineering-led security teams. - **[Sysdig Secure](/sysdig-secure)** — Runtime-first CNAPP built on [Falco](https://www.sysdig.com/opensource/falco). Strongest at detecting in-progress attacks via syscall-level telemetry, plus CSPM, CIEM, container scanning, and IaC. Differentiator: real-time runtime insights drive vulnerability prioritisation ("is this CVE actually exploitable in the running workload?"). - **Lacework FortiCNAPP** — [Acquired by Fortinet in 2024](https://www.fortinet.com/corporate/about-us/newsroom/press-releases/2024/fortinet-completes-acquisition-of-lacework) and rebranded FortiCNAPP. Behavioural analytics and anomaly detection via the Polygraph technology that builds baselines of normal cloud behaviour. Strong for runtime detection and compliance automation. - **Tenable Cloud Security** — Tenable's CNAPP, built on the [Ermetic acquisition](https://www.tenable.com/press-releases/tenable-completes-acquisition-of-ermetic). Strongest CIEM in the market (identity-first CNAPP), plus CSPM, CWPP, IaC, and Kubernetes security. - **Microsoft Defender for Cloud** — Built into Azure but also covers AWS and GCP. Native fit for Microsoft-shop teams; CNAPP capabilities improving fast as Microsoft consolidates its cloud-security portfolio under the Defender brand. Each of these platforms takes a slightly different approach. Wiz and Orca emphasise agentless breadth. Prisma Cloud emphasises depth across the full lifecycle. CrowdStrike and Sysdig lead on runtime detection. The right choice depends on your cloud footprint, your team's priorities, and how much you value agentless simplicity versus agent-based depth. --- ## Getting started {#getting-started} Deploying CNAPP involves both technical setup and organizational preparation. Here is a practical path: **Map your cloud footprint.** List every cloud account, subscription, and project across all providers. Note which environments are production versus development. CNAPP pricing and prioritization both depend on this inventory. **Connect cloud accounts.** Most CNAPP platforms connect via read-only IAM roles or service principals. The initial connection gives agentless visibility within hours, not weeks. Start with production accounts to see the highest-risk findings first. **Triage the initial findings.** The first scan of any cloud environment produces hundreds or thousands of findings. Focus on critical and high severity findings that affect production, internet-facing resources with known exploits, overly permissive identities with access to sensitive data, and unencrypted storage containing sensitive information. **Establish ownership.** Assign cloud accounts and workloads to engineering teams. Without clear ownership, findings sit in a backlog with no one accountable. Most CNAPP platforms support integration with your organizational structure. **Integrate with development workflows.** Connect the CNAPP platform to your CI/CD pipeline for IaC scanning and container image scanning. Shift findings left so that misconfigurations are caught before deployment. Integrate with Slack, Jira, or your ticketing system for remediation tracking. **Deploy agents selectively.** If your CNAPP offers agent-based runtime protection, start with production workloads that handle sensitive data or face the internet. You do not need agents everywhere on day one. --- ## How to evaluate a CNAPP platform {#how-to-evaluate} Five things that actually matter when comparing CNAPPs, in roughly the order I've seen them swing decisions across security teams: 1. **Cloud coverage.** Does the platform cover every cloud you run? AWS plus Azure plus GCP is table stakes; Oracle Cloud, Alibaba, and on-prem Kubernetes (EKS Anywhere, Rancher) are differentiators. Check that container registries, serverless platforms, and managed Kubernetes are all in scope before signing. 2. **Agentless vs agent depth.** Agentless gives breadth in days; agents give runtime depth at the cost of deployment effort. Most teams need both. Confirm what each platform delivers without agents and what only the agent unlocks (typically: real-time process telemetry, file integrity, and lateral movement detection). 3. **Runtime detection quality.** This is where vendors quietly differ. Look at the runtime detection rules library, the false-positive rate on benchmark workloads, and whether the platform integrates with your existing SIEM. CrowdStrike Falcon Cloud and Sysdig Secure have the deepest runtime stories; Wiz and Orca are catching up. 4. **IaC and code coverage.** A CNAPP that doesn't shift left has a 30-50% blind spot. Confirm Terraform / CloudFormation / Kubernetes scanning and IDE plugin support; verify whether the policy library is the vendor's own (Prisma Cloud uses Checkov; Snyk uses Snyk IaC; Wiz uses its own). 5. **AI-SPM readiness.** New in 2025-2026 — does the platform inventory deployed AI models, scan vector databases, and flag shadow AI usage? If you run any LLM, embedding store, or fine-tuning pipeline, this matters now and will matter more next year. For a side-by-side comparison of standalone CSPM vs full CNAPP, see [CSPM vs CNAPP](/application-security/cspm-vs-cnapp). --- ## Benefits of CNAPP {#benefits} The consolidated case for CNAPP over five point solutions: - **Unified context across the cloud stack.** A single risk graph connects misconfigurations to vulnerabilities to identities to network exposure. The same alert that says "S3 bucket public" also tells you which IAM role can read it, which workload mounts it, and whether the data inside is sensitive — context that point tools never get on their own. - **Fewer alerts, more signal.** Correlated findings collapse to one alert per attack path instead of five separate alerts for the same incident. Most teams report 60-80% alert volume reduction in the first quarter after switching from point tools to a CNAPP. - **Lower total cost of ownership.** Consolidation removes the cost of integrating five vendor APIs, training the team on five UIs, and managing five renewal cycles. Bundled CNAPP licences are usually cheaper than the sum of equivalent point solutions, especially at multi-cloud scale. - **Better attack-path analysis.** CNAPP platforms model lateral movement across cloud resources — "this internet-facing EC2 → this overprivileged role → this S3 bucket with PII." Point tools see slices; CNAPP sees the chain. - **Single agent / agentless surface.** One deployment instead of five reduces both runtime overhead and the number of agents the security team has to keep up to date. Modern CNAPPs default to agentless and add agents only where runtime depth is needed. --- --- # What is DAST? URL: https://appsecsanta.com/dast-tools/what-is-dast Description: DAST finds vulnerabilities by attacking your running web app from the outside. Learn how dynamic scanning works, top free and paid tools, and CI/CD setup. ## What DAST actually does {#what-dast-actually-does} Dynamic Application Security Testing finds vulnerabilities by attacking your running application from the outside. It crawls your web app, discovers forms and endpoints, fires malicious payloads at them, and watches what happens. No source code needed. No knowledge of what language or framework you used. DAST treats the application as a black box, the same way an attacker would. That is what makes DAST different from [SAST](/sast-tools). SAST reads your code and looks for dangerous patterns. DAST does not care about your code. It cares about how your application actually behaves when someone sends it `' OR 1=1--` in a login field. I spent almost 5 years working in the DAST industry, and the biggest shift I have seen is the move from standalone scanning tools for pentesters to CI/CD-integrated scanners that run automatically on every release. The technology is the same, but the workflow has changed completely. Mordor Intelligence estimates the DAST market reached $3.61 billion in 2025 and will grow to $8.52 billion by 2030 ([Mordor Intelligence, DAST Market Report, 2025](https://www.mordorintelligence.com/industry-reports/dynamic-application-security-testing-market)), driven by the shift to DevSecOps and the need for automated runtime testing alongside static analysis. --- ## DAST vs SAST vs IAST: where DAST fits {#dast-vs-sast-vs-iast} The three testing methods sit on different axes — knowing which is which is the fastest way to understand what DAST is. SAST (Static Application Security Testing) reads your source code. The scanner parses files, builds an abstract syntax tree, and looks for dangerous patterns — string concatenation into a SQL query, untrusted input flowing to an HTML template, hardcoded secrets. SAST runs without a running application. It needs the code. DAST (this page) tests a running application from the outside. The scanner has no view into your code, only into HTTP requests and responses. It catches what shows up at runtime — injection, misconfigurations, broken auth, leaked headers — and ignores what only shows up in source. IAST (Interactive Application Security Testing) instruments the running application from the inside. An IAST agent observes both source-level data flow and runtime requests, so a finding can point to the exact file and line. IAST needs an agent that supports your language and framework, which limits where it runs. In practice, most mature security programs combine SAST + DAST. IAST adds a third layer when language coverage and code-level findings justify the agent footprint. For a deep side-by-side, see [SAST vs DAST vs IAST](/application-security/sast-vs-dast-vs-iast). This page stays on the DAST definition. --- ## How does dynamic scanning work? {#how-dynamic-scanning-works} A DAST scan follows a predictable sequence. Knowing how it works helps you troubleshoot when a scan misses something you expected it to find. ### Crawling The scanner starts by mapping the application. It follows links, submits forms, clicks buttons, and builds a model of every page and endpoint it can reach. Modern tools use headless browsers (Chromium under the hood) to handle JavaScript-heavy applications. Crawling is where DAST tools differ the most. A weak crawler misses pages and endpoints, which means missed vulnerabilities. For Single-Page Applications where content loads dynamically, the crawler needs to execute JavaScript and wait for DOM changes. Not all tools do this well. ### Attack and fuzzing Once the application is mapped, the scanner sends crafted payloads to every input it found: form fields, URL parameters, headers, cookies, JSON body parameters. SQL injection payloads for database-backed inputs. XSS payloads for fields rendered in HTML. Command injection payloads for inputs that might reach system calls. The scanner watches how the application responds. A database error message after a SQL injection payload suggests the vulnerability is real. Reflected script content in the response body confirms XSS. ### Authentication testing DAST tools test login mechanisms, session management, and access controls. Good tools support multi-step login sequences, token-based authentication, and role-based testing where you scan as different user roles to check for privilege escalation. Getting authentication right is the trickiest part of setting up a DAST scan. If the scanner cannot stay logged in, it only tests the unauthenticated attack surface, which is a small fraction of most applications. ### Reporting and verification Results get ranked by severity, usually mapped to OWASP Top 10 or CWE categories. Some tools go further. [Invicti](/invicti) uses proof-based scanning that automatically confirms vulnerabilities by extracting actual data (like a database version string) rather than just flagging a suspicious response. False positive rates drop close to zero for confirmed findings. --- ## What does DAST catch? {#what-dast-catches} DAST is good at finding vulnerabilities that depend on runtime behavior: - **SQL injection** — The classic. DAST sends malicious SQL in input fields and watches for database errors or data leakage in responses. - **Cross-site scripting (XSS)** — The scanner injects script payloads and checks whether they get reflected or stored and rendered. - **Server misconfigurations** — Missing security headers, verbose error messages, directory listing enabled, default credentials. These are invisible to source code analysis. - **Authentication and session issues** — Weak session tokens, missing logout functionality, session fixation, insecure cookie attributes. - **Broken access control** — The scanner tests whether it can access resources it should not be able to reach, including horizontal and vertical privilege escalation. - **Security header issues** — Missing or misconfigured Content-Security-Policy, X-Frame-Options, HSTS, and other headers that protect against common attacks. DAST catches these because it tests the application as it actually runs. Server misconfigurations and authentication issues do not exist in source code. They only exist in running applications. ### OWASP Top 10 (2021) coverage by DAST The OWASP Foundation publishes the [OWASP Top 10](https://owasp.org/www-project-top-ten/) as the most common web application risks. DAST hits some categories cleanly and only partially covers others. - **A01 Broken Access Control** — partial. DAST can probe role-based access and direct object references when configured with multiple test users; it misses logic-driven access rules. - **A02 Cryptographic Failures** — partial. DAST flags weak TLS, missing HSTS, and insecure cookies; it cannot inspect cryptographic primitives in source. - **A03 Injection** — strong. SQL injection, command injection, NoSQL injection, XSS — DAST's core strength. - **A04 Insecure Design** — weak. Design-level flaws live above what a scanner can observe. - **A05 Security Misconfiguration** — strong. Server headers, default pages, exposed admin panels — all visible at runtime. - **A06 Vulnerable Components** — partial. DAST detects some known-CVE fingerprints (Log4Shell, Spring4Shell); SCA tools cover this better. - **A07 Identification and Authentication Failures** — partial. Session fixation, weak tokens, missing logout — visible to a tuned scanner. - **A08 Software and Data Integrity Failures** — weak. Mostly SAST + supply-chain territory. - **A09 Security Logging Failures** — out of scope for runtime probing. - **A10 SSRF** — strong. Out-of-band detection (OAST) on inputs catches blind SSRF reliably. --- ## Where does DAST fall short? {#where-dast-falls-short} DAST has real limitations. Knowing them helps you decide where to supplement it. **No code location.** DAST tells you a SQL injection exists at `/api/users?id=123`, but not which file and line is responsible. Developers still need to track down the vulnerable code. [IAST tools](/iast-tools) solve this by combining runtime detection with code-level visibility. **Crawl coverage gaps.** DAST can only test what it can find. Pages hidden behind complex multi-step workflows or state-dependent interfaces get missed. Some teams supplement automated crawling with manual exploration using [Burp Suite](/burp-suite). **Speed.** A full DAST scan takes hours. Fine for nightly builds, too slow for pull request feedback. [Dastardly](/dastardly) and [ZAP](/zap) baseline scans address this with quick scan modes, but they trade thoroughness for speed. **SPA challenges.** Single-Page Applications built with React, Angular, or Vue load content dynamically through JavaScript. Older DAST tools that rely on HTML parsing miss these entirely. Modern tools use headless browsers, but SPA coverage still varies between products. **Business logic flaws.** Like SAST, DAST cannot understand your application's business rules. If a discount code can be applied twice because of a logic error, no scanner will find it. --- ## DAST in your CI/CD pipeline {#dast-in-your-cicd-pipeline} The days of running a DAST scan once a quarter and emailing a PDF report are over. Modern DAST fits into automated pipelines, though the setup differs from SAST. The catch: DAST needs a running application. Your pipeline needs to deploy to a staging environment before the scan can start. ### Quick scans on every PR Use lightweight tools that finish in minutes. [Dastardly](/dastardly) has a built-in 10-minute cap. [ZAP](/zap) baseline scans run in under 5 minutes. [Nuclei](/nuclei) with targeted templates finishes quickly. Not comprehensive, but they catch regressions and obvious issues fast. ### Full crawls on nightly or weekly builds Schedule thorough DAST scans outside the PR workflow. A full crawl with [Invicti](/invicti), [HCL AppScan](/hcl-appscan-dast), or [Veracode DAST](/veracode#veracode-dynamic-analysis-dast) against staging takes hours and covers more ground. Run it nightly and review results in the morning. ### Quality gates Block production deploys when critical findings appear. [Invicti](/invicti), [StackHawk](/stackhawk), and [HCL AppScan](/hcl-appscan-dast) have CI/CD integrations that can fail a pipeline based on finding severity. --- ## DAST for APIs and SPAs {#dast-for-apis-and-spas} Traditional DAST was built for server-rendered web pages. Modern applications look different: SPAs with React frontends talking to REST or GraphQL APIs. The tools have had to adapt. ### API scanning Most DAST tools now support API scanning by importing OpenAPI/Swagger specs or Postman collections. The tool reads the spec, understands the endpoints and parameter types, and tests each one for injection, broken authentication, and data exposure. [Escape](/escape) is built specifically for API and business logic testing. [StackHawk](/stackhawk) has strong API scanning through its HawkAI feature. [Tenable WAS](/tenable-io) handles REST, GraphQL, and SOAP APIs. For API-heavy architectures, dedicated API scanning is more effective than forcing a traditional web scanner to understand your API. ### SPA scanning For SPAs, you need a DAST tool that uses a real browser engine to render JavaScript and interact with the DOM. [Burp Suite](/burp-suite), [Invicti](/invicti), and [HCL AppScan](/hcl-appscan-dast) handle SPAs better than most. Always verify that the tool can discover your SPA's routes and interact with dynamic content before committing to it. --- **Looking for tools?** See our complete [DAST tools comparison](/dast-tools) with 30+ tools rated and reviewed. --- ## Getting started {#getting-started} If you have never run DAST before, here is a practical path. Set up a staging environment. DAST needs a running application. Never scan production directly unless you understand the risks (DAST sends malicious payloads that can create test data or trigger errors). Start with a free tool. [ZAP](/zap) is the safest starting point. Well-documented, large community, runs everywhere. Install it, point it at your staging URL, run a baseline scan. Configure authentication. Your first scan will only cover the unauthenticated surface. Set up the scanner with login credentials to test authenticated functionality. This is where most people get stuck, so allocate time for it. Review and triage results. Go through the findings. Verify the real ones, dismiss the false positives. DAST false positive rates are lower than SAST, but not zero. Add it to CI. Once you trust the results, integrate the tool into your pipeline. Quick scans on PRs, full scans nightly. Consider adding SAST. DAST covers runtime behavior. [SAST](/sast-tools) covers your source code. Together they give you much better coverage than either alone. See our [SAST vs DAST vs IAST comparison](/application-security/sast-vs-dast-vs-iast) for guidance on combining approaches. --- ## FAQ {#faq} --- # What is IaC Security? URL: https://appsecsanta.com/iac-security-tools/what-is-iac-security Description: IaC security catches misconfigurations in Terraform, CloudFormation, and Kubernetes before deployment. Top free tools, common issues, and CI/CD setup guide. > **IaC security is the practice of automatically scanning Terraform, CloudFormation, Kubernetes manifests, and Helm charts for misconfigurations before deployment.** Policy-as-code rules catch exposed databases, overly permissive IAM, unencrypted storage, and insecure network rules at development time — preventing misconfigurations from ever reaching production rather than detecting them after the fact. ## What IaC security means {#what-iac-security-means} Infrastructure as Code security is the practice of scanning IaC templates for security misconfigurations before they get deployed to cloud environments. Terraform files, CloudFormation templates, Kubernetes manifests, Helm charts, Dockerfiles -- any declarative configuration that defines infrastructure can be checked against security policies automatically. The idea is straightforward. If your infrastructure is defined in code, you can review that code for security issues the same way you review application code for bugs. A misconfigured S3 bucket is just a few lines of Terraform. Catch it in the pull request instead of finding it in production after someone exfiltrates your data. IaC scanning tools read your templates, parse them into a structured representation, and check each resource against a library of security policies. A policy might say "S3 buckets must have encryption enabled" or "security groups must not allow inbound traffic from 0.0.0.0/0." The tool compares what your code defines against what the policy requires. Failures get reported with the exact file, line number, and resource name. This is shift-left for infrastructure. The same concept that SAST brought to application security -- find problems in the code before they become live vulnerabilities -- applied to cloud infrastructure. The difference is that IaC misconfigurations are often easier to fix than application bugs, because you are changing a configuration value rather than rewriting logic. --- ## Why does IaC security matter? {#why-iac-security-matters} Cloud misconfiguration is not a theoretical problem. It is the leading cause of cloud security incidents. Gartner has projected that through 2025, 99% of cloud security failures would be the customer's fault, and misconfiguration sits at the top of that list. The numbers back this up. [IBM's 2025 Cost of a Data Breach Report](https://www.ibm.com/reports/data-breach) puts the global average at $4.44 million, down 9% from $4.88 million the year before but still high enough to justify catching misconfigurations early. The [2024 Verizon DBIR](https://www.verizon.com/business/resources/reports/dbir/) repeatedly calls out misconfiguration as a factor in web application breaches. Most of these are preventable with checks that any IaC scanner runs out of the box. Why bother when you could just review Terraform manually? A few reasons. **Speed.** An IaC scan runs in seconds. A Terraform plan with 200 resources scans in under a minute on any modern tool. A manual security review of the same infrastructure takes days and still misses things. **Consistency.** Humans miss things. Especially on the 50th pull request of the week. An automated scanner applies the same policies to every change, every time. CIS Benchmarks, organizational standards, compliance requirements -- all enforced without relying on someone remembering to check. **Cost.** Fixing a misconfiguration in a Terraform file costs a developer five minutes. Fixing the same misconfiguration after it causes a breach costs orders of magnitude more. --- ## What are the most common IaC misconfigurations? {#common-misconfigurations} These are the issues that IaC scanners flag most often. They are also the misconfigurations behind most cloud breaches. ### Public storage buckets S3 buckets, Google Cloud Storage buckets, and Azure Blob containers configured with public access. The Capital One breach in 2019 started with a misconfigured WAF but the data was in publicly accessible S3 storage. Every IaC scanner checks for this. It is the most basic rule in every policy library. ### Overly permissive IAM IAM policies with `"Effect": "Allow", "Action": "*", "Resource": "*"` give full administrative access. IaC scanners flag wildcard actions, wildcard resources, and missing condition constraints. The principle of least privilege is easy to state and hard to maintain manually across hundreds of IAM policies. ### Open security groups Security groups or network ACLs that allow inbound traffic from `0.0.0.0/0` on sensitive ports like SSH (22), RDP (3389), or database ports (3306, 5432, 27017). These are among the first things attackers scan for in cloud environments. ### Unencrypted storage and databases EBS volumes, RDS instances, S3 buckets, and similar resources without encryption at rest. Many compliance frameworks (PCI DSS, HIPAA, SOC 2) require encryption. IaC scanners check both that encryption is enabled and that customer-managed keys are used where required. ### Disabled logging and monitoring CloudTrail not enabled, VPC flow logs not configured, S3 access logging disabled. Without logging, you cannot detect or investigate incidents. IaC scanners verify that logging resources exist and are properly configured. ### Exposed databases RDS instances, Elasticsearch domains, or Redis clusters with public accessibility enabled. Databases should sit in private subnets and only be reachable through application servers or bastion hosts. A publicly accessible database is one credential-stuffing attack away from a breach. ### Missing network segmentation Resources in the default VPC, subnets without network ACLs, or missing private subnet configurations for sensitive workloads. IaC scanners check that network architecture follows isolation best practices. --- ## How does IaC scanning work? {#how-iac-scanning-works} IaC scanners use several techniques under the hood. Understanding them helps when you are evaluating tools or debugging why a scan missed something. ### Policy-based checking The core mechanism. The scanner maintains a library of policies (also called checks, rules, or queries depending on the tool). Each policy defines a condition that a resource must meet. "aws_s3_bucket must have server_side_encryption_configuration" is a policy. The scanner evaluates every resource against every applicable policy and reports failures. [Checkov](/checkov) ships with 1,000+ policies. [KICS](/kics) has 2,400+ Rego-based queries. [Trivy](/trivy) inherited [tfsec's policy library](https://github.com/aquasecurity/tfsec). The size and quality of the built-in policy library is the main differentiator between tools. ### Graph-based analysis Standard policy checks look at individual resources in isolation. Graph-based analysis looks at relationships between resources. This catches a class of misconfigurations that single-resource checks miss. Example: an EC2 instance connects to a network interface, which is in a subnet, which is in a VPC. A graph-based check can verify that this entire chain is properly configured -- that the subnet is private, the VPC has flow logging, and the network interface has the right security group attached. [Checkov](/checkov) is the only open-source tool with graph-based policies (800+ of them). ### Framework-specific parsers Each IaC framework has its own syntax and semantics. Terraform HCL is different from CloudFormation YAML is different from Kubernetes manifests. IaC scanners need parsers for each format that understand the resource types, attribute names, and relationships specific to that framework. This is why framework support varies between tools. Writing a parser for Terraform is not the same effort as writing one for Bicep or Pulumi. Broader framework support usually means each individual parser gets less depth. ### Custom policies Built-in policies cover common misconfigurations, but every organization has specific requirements. Custom policies let you encode your own standards. The major policy languages: - **Python or YAML** -- [Checkov](/checkov) supports both. YAML policies are declarative and easy to write. Python policies offer full programmatic flexibility. - **Rego** -- [KICS](/kics), [Trivy](/trivy), and [Terrascan](/terrascan) use [Rego, the Open Policy Agent language](https://www.openpolicyagent.org/docs/latest/policy-language/). Powerful but has a learning curve. - **OPA/Rego** -- [Snyk IaC](/snyk#snyk-iac) supports custom rules in Rego on paid plans. If your team already uses OPA for Kubernetes admission control, Rego-based tools fit naturally. If not, Checkov's YAML format has a gentler onboarding curve. --- ## IaC frameworks covered {#iac-frameworks-covered} IaC security tools do not all support the same frameworks. Here is what the ecosystem covers. ### Terraform The most widely scanned IaC framework. Every tool in this space supports Terraform HCL. Some also scan [Terraform plan output](https://developer.hashicorp.com/terraform/cli/commands/plan) (JSON), which captures the resolved values after variable interpolation and module expansion. Plan scanning is more accurate than static HCL scanning because it sees the actual values that will be deployed. For a hands-on walkthrough of setting up Terraform scanning with CI/CD pipeline examples, see the [Terraform security scanning guide](/iac-security-tools/terraform-security-scanning). ### CloudFormation AWS-specific. Scanned by all major tools. Includes both YAML and JSON formats. AWS SAM templates are also covered by most scanners since SAM compiles down to CloudFormation. ### Kubernetes manifests YAML files that define pods, deployments, services, network policies, and other Kubernetes resources. Scanners check for privileged containers, missing resource limits, hostPath mounts, missing security contexts, and other Kubernetes-specific misconfigurations. ### Helm charts Helm templates are rendered into Kubernetes manifests before scanning. Most tools handle this rendering internally. [Checkov](/checkov), [KICS](/kics), [Trivy](/trivy), and [Kubescape](/kubescape) all support Helm charts. ### Dockerfiles Checked for running as root, using the `latest` tag, exposing unnecessary ports, adding secrets in build layers, and missing health checks. Dockerfile scanning overlaps with container security but fits in the IaC scanning workflow because Dockerfiles are committed alongside infrastructure code. ### ARM templates and Bicep Azure-specific. ARM templates (JSON) are supported by most tools. Bicep (the newer Azure IaC language that compiles to ARM) has narrower support. [Checkov](/checkov) and [KICS](/kics) handle both. ### Ansible Ansible playbooks and roles can be scanned for insecure module usage, hardcoded credentials, and privilege escalation. [Checkov](/checkov), [KICS](/kics), and [Trivy](/trivy) support Ansible scanning. ### Others [KICS](/kics) has the widest coverage at 22+ frameworks, including OpenAPI specs, gRPC, Pulumi, Crossplane, Google Deployment Manager, and GitHub Actions workflows. [Checkov](/checkov) covers OpenTofu, Kustomize, Serverless Framework, and AWS CDK. --- ## IaC security vs CSPM {#iac-security-vs-cspm} IaC security and CSPM (Cloud Security Posture Management) solve the same underlying problem -- cloud misconfiguration -- but at different stages of the lifecycle. **IaC security** operates pre-deployment. It scans your code before anything reaches the cloud. The feedback loop is fast: a developer writes Terraform, the CI pipeline scans it, misconfigurations are flagged in the pull request. Nothing insecure gets deployed in the first place. **CSPM** operates post-deployment. It connects to your live cloud accounts (AWS, Azure, GCP) through APIs and continuously monitors the actual state of your infrastructure. It catches drift (someone changed a security group through the console), resources created outside of IaC, and misconfigurations that IaC scanning missed. They are not competing approaches. IaC security is preventive. CSPM is detective. A mature cloud security program runs both. Some tools bridge the gap. [Snyk IaC](/snyk#snyk-iac) offers drift detection that compares your Terraform state against your live cloud environment. [Checkov](/checkov) integrates with Prisma Cloud, which provides CSPM alongside IaC scanning. [Trivy](/trivy) can scan running Kubernetes clusters directly, which is closer to runtime monitoring than static scanning. The practical advice: start with IaC scanning because it is free, fast, and catches the most common issues. Add CSPM when you need visibility into what is actually running and want to detect changes made outside your IaC workflow. For teams evaluating broader cloud security platforms, our [CSPM vs CNAPP comparison](/application-security/cspm-vs-cnapp) covers when a standalone CSPM tool is enough versus when you need a full CNAPP platform. --- **Looking for tools?** See our complete [IaC security tools comparison](/iac-security-tools) with 18 tools rated and reviewed. --- ## Getting started {#getting-started} If you have never run IaC scanning before, here is a practical path. Pick one tool. If you use Terraform, start with [Checkov](/checkov). Install it with `pip install checkov` and run `checkov -d .` in your Terraform directory. If you want broader coverage beyond IaC, install [Trivy](/trivy) and run `trivy config .` on the same directory. Both take under two minutes to set up. Review the initial results. Your first scan will produce findings. Go through them. Most will be real issues you did not know about. A few will be false positives or findings that do not apply to your environment. Suppress those so they do not clutter future results. Add it to CI. Run the scanner on every pull request that touches IaC files. Start in warning mode -- report findings but do not block merges. Let the team see the value before enforcing gates. Enable quality gates. Once the team trusts the results, block merges on high and critical findings. Keep medium-severity findings as warnings. This is where IaC scanning pays off: misconfigurations stop reaching production entirely. Write custom policies. Every organization has requirements that generic policies do not cover. Internal naming conventions, required tags, mandatory encryption keys from your KMS. [Checkov](/checkov) custom policies in YAML are the easiest to write. [KICS](/kics) and [Trivy](/trivy) use Rego if your team is already in the OPA ecosystem. Map to compliance frameworks. If you have compliance requirements (CIS, SOC 2, PCI DSS, HIPAA), configure your scanner to report against those frameworks. [Checkov](/checkov) has built-in compliance mappings. This turns IaC scanning from a security tool into an audit tool. --- ## Top IaC security tools (quick list) {#top-tools} For a full vendor-neutral comparison, the [IaC security tools hub](/iac-security-tools) ranks 15 scanners across free and commercial tiers. The short list, with one paragraph each, is below. - **[Checkov](/checkov)** — best free multi-framework scanner. 1,000+ built-in policies, 800+ graph-based cross-resource checks, native Terraform / CloudFormation / Kubernetes / Helm support. Backed by Palo Alto Networks (Prisma Cloud) since the 2021 Bridgecrew acquisition. Apache 2.0. - **[Trivy](/trivy)** — best all-in-one. IaC plus container images plus SBOM plus running Kubernetes clusters in a single Go binary. Absorbed tfsec in 2023, so Terraform coverage is mature. Backed by Aqua Security. Apache 2.0. - **[KICS](/kics)** — best for niche frameworks. 2,400+ Rego queries spanning 22+ platforms (Ansible, Pulumi, Crossplane, OpenAPI specs, GitHub Actions). Backed by Checkmarx. Apache 2.0. - **[Kubescape](/kubescape)** — best for Kubernetes-first teams. [CNCF Incubating project](https://www.cncf.io/projects/kubescape/) with built-in CIS, NSA-CISA, and MITRE ATT&CK frameworks. Scans static manifests plus running clusters. Apache 2.0. - **Snyk IaC** — best developer experience. IDE plugin for VS Code and JetBrains, GitHub Actions, GitLab CI, plus AI-generated fix suggestions. Free tier with limits; paid plans for team features. - **[Wiz](/wiz)** — best commercial CNAPP including IaC. Agentless cloud scanning that correlates IaC findings with live cloud config and runtime exposure. Pricing is sales-gated. --- ## IaC security best practices {#best-practices} A few patterns separate teams that get value out of IaC scanning from teams that watch findings pile up unread. Borrowing from the [OWASP IaC Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html), the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes), and what I've seen across hundreds of pipelines: 1. **Shift left, but ship soft.** Run scans on every pull request, but start in warning mode. Block merges only after the team has tuned out false positives — usually 2-4 weeks. Forcing red builds on day one breeds workarounds; running yellow builds first earns trust. 2. **Treat policies as code.** Check your custom Checkov, Rego, or Kyverno policies into the same repo as the IaC they govern. Version them. Code-review them. The scanner is only as good as the policies it runs. 3. **Fail CI on high and critical only.** Medium and low findings stay as warnings. The point is to gate dangerous misconfigurations without burning trust on noisy ones. 4. **Pair IaC scanning with cloud-runtime visibility.** IaC catches what's in the templates; CSPM or CNAPP catches what's actually running. Both layers are needed because nobody actually deploys 100% from IaC — drift happens. 5. **Baseline against compliance frameworks.** Map your scanner output to CIS Benchmarks, NIST 800-53, SOC 2, HIPAA, and PCI DSS where applicable. Most scanners ship pre-built mappings; turning them on costs nothing and produces audit-ready evidence. 6. **Manage exceptions as code.** Suppress findings via `.checkov.yaml` skip lists, KICS query filters, or Kubescape exclusion lists — never via flags inside the CI runner. Code-reviewable exceptions stay accountable; CLI flags don't. 7. **Detect drift on a schedule.** Run `terraform plan` (or the equivalent) nightly and alert on anything new. Drift is where IaC scanning silently loses coverage; without drift detection, the scanner becomes a checkbox rather than a control. --- ## FAQ {#faq} --- # What is IAST? URL: https://appsecsanta.com/iast-tools/what-is-iast Description: IAST uses runtime agents inside your app to find vulnerabilities with exact code locations and near-zero false positives. Top tools and CI/CD setup included. ## What does IAST stand for? **IAST** stands for **Interactive Application Security Testing**. It is a security testing approach that places an agent inside a running application to observe how data flows through the code at runtime. The agent reports vulnerabilities with the exact file, line number, and call chain when tainted input reaches a dangerous operation. - **Detects** injection flaws, XSS, path traversal, insecure deserialization, weak cryptography, and other dataflow vulnerabilities — with the exact code location. - **Runs during** functional tests, integration tests, manual QA, or DAST scans against an instrumented application. - **Does not detect** vulnerabilities in code paths that never execute during testing — coverage is bounded by test traffic. ## What IAST actually does {#what-iast-actually-does} Interactive Application Security Testing finds vulnerabilities by observing your application from the inside while it runs. An agent sits inside the application runtime, watches how data moves through the code, and flags the exact line where something goes wrong. The "interactive" part matters. IAST does not scan your application on its own. It waits for something to interact with the application — an automated test suite, a QA engineer clicking through workflows, a DAST scanner firing payloads. As those interactions happen, the agent tracks every data flow and reports vulnerabilities with full code-level detail. [SAST](/sast-tools) reads your code without running it. [DAST](/dast-tools) attacks your running application from the outside. IAST sits inside the application while it runs and sees both the code and the runtime behavior at the same time. When it finds a SQL injection, it does not just tell you the URL and parameter like DAST would. It tells you the file, the line number, the full stack trace, and the exact data flow from HTTP request to database query. That means very few false positives. The agent observes actual data flow rather than guessing from static patterns or inferring from HTTP responses. Contrast Security reports their IAST approach produces 99% fewer false positives than traditional tools (Contrast Security, vendor-reported). In NSA testing, Contrast correctly identified 98% of web application vulnerability test cases with zero false alarms (Contrast Security citing NSA STONESOUP evaluation). The IAST market is small compared to SAST and DAST. Only about nine active tools exist today. The technology is genuinely useful, but it requires more setup than running a scanner, which has kept adoption narrower than the other approaches. --- ## How does runtime instrumentation work? {#how-runtime-instrumentation-works} IAST tools use agents that hook into the application runtime to observe code execution. The mechanics vary by language, but the principle is the same across all of them. ### Agent deployment You install a language-specific agent into your application server. For a Java application, you add a [JVM argument](https://docs.contrastsecurity.com/en/install-the-java-agent.html) (`-javaagent:contrast.jar`). For .NET, you install a CLR profiler. For [Node.js, you require a module at startup](https://docs.contrastsecurity.com/en/install-a-node-js-agent.html). The agent loads alongside your application and instruments key functions without changing your source code. The agent intercepts calls to security-sensitive functions: database queries, file system operations, command execution, HTTP responses, cryptographic functions. It also intercepts data entry points: HTTP request parameters, headers, cookies, request body parsing. ### Taint tracking This is the core of how IAST works. When user-controlled data enters the application through an HTTP request, the agent marks it as "tainted." As that data flows through the application, through variable assignments, string concatenations, method calls, and framework processing, the agent follows it. A concrete example: a user submits a search form. The agent marks the search parameter as tainted. It follows that value through the controller, into a service method, through a string concatenation that builds a SQL query, and into `Statement.executeQuery()`. If no parameterized query or sanitization was applied along the way, the agent reports a SQL injection vulnerability with the exact code path. This is the same concept as SAST data flow analysis, but with one big difference. SAST has to guess which code paths are reachable and how frameworks handle data. IAST sees the actual execution. No guessing about whether Spring's input validation is in place or whether Django's ORM is being used correctly. The agent watches it happen. ### Passive vs active IAST Most IAST tools are passive. They observe traffic that already exists (from tests, QA, or other scanners) and analyze it. [Contrast Assess](/contrast-security#contrast-assess-iast), [Datadog IAST](/datadog-iast), and [Checkmarx IAST](/checkmarx#iast) work this way. No additional attack traffic is generated. Some tools add an active component. [Seeker IAST](/seeker-iast) uses active verification, where the agent sends additional requests to confirm whether a detected vulnerability is actually exploitable. This reduces false positives further but generates extra traffic against the application. A third approach is DAST+IAST hybrid. Tools like [Acunetix AcuSensor](/acunetix-acusensor), [Invicti Shark](/invicti-shark), and [Fortify WebInspect Agent](/fortify-webinspect-agent) [pair an internal agent with an external DAST scanner](https://www.acunetix.com/vulnerability-scanner/acusensor-technology/). The DAST scanner generates attack traffic while the agent watches the code execution. This gives you the crawling and attack capabilities of DAST with the code-level precision of IAST. --- ## What does IAST catch? {#what-iast-catches} IAST finds the same [vulnerability classes](https://owasp.org/www-project-top-ten/) as SAST and DAST, but with higher confidence and more useful remediation detail: - **Injection flaws** — SQL injection, command injection, LDAP injection, XPath injection. IAST traces the exact data path from HTTP parameter to dangerous function, including every transformation along the way. - **Cross-site scripting (XSS)** — Tainted user input that reaches an HTTP response without encoding. The agent shows the exact output function responsible. - **Path traversal** — User-controlled input used to construct file paths. The agent catches this at the file system API call with the actual path value. - **Insecure deserialization** — Untrusted data reaching deserialization functions. The agent identifies the exact deserialization call and the incoming data. - **Weak cryptography** — Calls to deprecated algorithms (MD5, SHA-1 for password hashing) or weak key lengths observed at runtime. - **Hardcoded secrets** — Credentials or API keys embedded in code that the agent encounters during execution. - **Server misconfigurations** — Missing security headers, verbose error messages, insecure cookie attributes. The agent sees the actual HTTP response being constructed. The advantage over SAST is accuracy. SAST might flag a database query as vulnerable when the framework actually parameterizes it automatically. IAST sees the parameterized query at runtime and stays quiet. The advantage over DAST is detail. DAST tells you that `/api/users?id=1` is vulnerable to SQL injection. IAST tells you the vulnerability is in `UserRepository.java` at line 47, where `query` is concatenated with untainted input from `request.getParameter("id")`. --- ## What are the benefits of IAST? The argument for adding IAST to a security program comes down to six benefits. - **Low false positives via runtime data flow.** The agent sees actual taint propagation rather than inferring it from code or HTTP responses. Vendors typically report under 5% false positive rates — Contrast cites NSA Center for Assured Software testing at 98% true-positive accuracy, Datadog publishes 100% on the OWASP Benchmark. - **Catches what DAST misses.** Blind injection, business-logic flaws, deep data flow vulnerabilities where the HTTP response looks identical to a successful request — IAST observes the dangerous sink directly instead of guessing from the outside. - **Developer-friendly remediation.** Findings include the file, line number, and full data flow trace. Developers fix from a stack trace instead of reproducing a vulnerability from a URL and payload. - **CI/CD-friendly.** The agent runs alongside existing functional tests, adds 2–5% latency, and reports as a side effect of normal test execution. There is no separate scan step to schedule. - **Language-aware.** Where DAST treats every app as a black box, IAST sees the runtime — Spring's parameterized query stays quiet, Django's ORM stays quiet, the unsafe string concatenation gets flagged. - **Faster than full DAST scans.** Telemetry is continuous instead of batch, so security findings land as tests run instead of arriving hours later when the nightly scan completes. ## Where does IAST fall short? {#where-iast-falls-short} IAST has real limitations. Knowing them helps you decide where to add other testing methods. **Limited language support.** Every supported language needs a dedicated agent built for that runtime. Java and .NET have the best coverage across all tools. Node.js support is common. Python, Go, Ruby, and PHP support varies by vendor. If your stack includes Rust, Elixir, Kotlin multiplatform, or anything niche, IAST is not an option today. **Coverage depends on test traffic.** IAST only sees code paths that actually execute during testing. If your test suite covers 40% of your code, IAST analyzes 40% of your code. Dead code, rarely used admin endpoints, and error handling paths that tests do not trigger remain invisible. This is fundamentally different from SAST, which analyzes the entire codebase. **Performance overhead.** Agents add latency. Vendors report 2-5% overhead, which is acceptable for QA environments but enough to keep most teams from running IAST in production. Performance-sensitive applications or tight SLA environments may find even that unacceptable during load testing. **Deployment complexity in modern architectures.** For a monolithic Java application on Tomcat, adding an IAST agent takes minutes. For a Kubernetes cluster running 50 microservices across three languages, you need to modify container images, manage agent versions, and handle the operational overhead. Serverless architectures (Lambda, Cloud Functions) are largely unsupported because the ephemeral execution model does not work well with persistent agents. **Small ecosystem.** With only about nine active tools on the market, your choices are limited. There are no mature open-source IAST tools. If your budget is zero, the IAST market does not have a maintained free option in 2026 — Contrast Community Edition reached end-of-life on June 30, 2025. The closest free path is to request a vendor trial from [Contrast Assess](/contrast-security#contrast-assess-iast), [Datadog IAST](/datadog-iast), or [Seeker IAST](/seeker-iast) — none publish public pricing, and all three gate trial access behind a sales conversation. --- ## IAST in your CI/CD pipeline {#iast-in-your-cicd-pipeline} IAST integrates differently than SAST or DAST. There is no separate scan step. The agent runs during your existing tests and reports findings as a side effect of normal testing. ### During functional and integration tests This is the most natural fit. Deploy your application to a QA environment with the IAST agent enabled, run your existing test suite, and the agent analyzes data flows in the background. No extra scan step, no extra time. Security analysis happens alongside your functional tests. [Contrast Assess](/contrast-security#contrast-assess-iast) and [Seeker IAST](/seeker-iast) both integrate with CI tools like Jenkins, GitLab CI, and GitHub Actions. The pipeline deploys the instrumented application, runs tests, then checks the IAST dashboard for new findings before proceeding. ### Paired with DAST scanning Some teams run a DAST scanner against an IAST-instrumented application. The DAST tool provides broad attack coverage while the IAST agent provides code-level detail for everything it finds. [Invicti Shark](/invicti-shark), [Acunetix AcuSensor](/acunetix-acusensor), and [Fortify WebInspect Agent](/fortify-webinspect-agent) are built specifically for this workflow. ### Quality gates Block deployments when IAST finds critical vulnerabilities. Because IAST false positive rates are low, quality gates are more practical than with SAST. A critical IAST finding is almost certainly a real vulnerability that needs fixing before release. ### Coverage monitoring Track which code paths the agent has analyzed over time. If IAST consistently sees only 50% of your codebase, that is a signal to improve your test coverage. [Contrast Assess](/contrast-security#contrast-assess-iast) provides route coverage metrics that show exactly which endpoints and code paths have been tested. --- ## IAST vs SAST and DAST {#iast-vs-sast-and-dast} The three approaches are complementary, not competing. **SAST** analyzes all your code without running it. It covers the entire codebase, catches issues early, and fits into IDE and PR workflows. The trade-off is higher false positive rates because it has no runtime context. See [SAST tools](/sast-tools) for options. **DAST** tests your running application from outside. It finds server misconfigurations, authentication issues, and runtime behaviors that code analysis misses. The trade-off is no code-level detail — developers must track down the root cause themselves. See [DAST tools](/dast-tools) for options. **IAST** sits inside the running application during testing. It gives you the code-level precision of SAST with the runtime context of DAST. The trade-off is limited coverage (only tested code paths), language-specific agents, and deployment complexity. Do you need all three? Many teams get strong coverage with just SAST and DAST. IAST adds the most value when false positive triage is eating too much developer time, when you need exact code locations for runtime findings, or when you have a mature test automation suite that exercises most of your code. For a detailed breakdown with comparison tables, see the [SAST vs DAST vs IAST comparison](/application-security/sast-vs-dast-vs-iast). For a focused look at how IAST and DAST compare on detection capabilities, accuracy, and deployment, see [IAST vs DAST](/application-security/iast-vs-dast). --- **Looking for tools?** See our complete [IAST tools comparison](/iast-tools) with 10 tools rated and reviewed. --- ## Getting started {#getting-started} If you have never run IAST before, here is a practical path. Check your language support first. IAST is only useful if an agent exists for your application's language and runtime. Java and .NET are safe bets. Node.js is widely supported. For Python, Go, Ruby, or PHP, check specific vendor support before investing time. Start with a vendor trial. Contrast Community Edition reached end-of-life on June 30, 2025, so the IAST market no longer has a self-serve free tier. Practical evaluation paths in 2026: request a [Contrast Assess](/contrast-security#contrast-assess-iast) trial through Contrast Security's sales team, or — if Datadog APM is already running in your stack — flip on [Datadog IAST](/datadog-iast) with a [single env-var](https://docs.datadoghq.com/security/code_security/iast/setup/) (`DD_IAST_ENABLED=true`). Either path gives you a real IAST experience on a real application within a day or two. Install the agent, run your tests, see what it finds. Instrument a QA environment. Do not start in production. Deploy your application with the IAST agent to a QA or staging environment. Run your existing test suite. The agent analyzes everything that executes and reports findings with code-level detail. Review the findings. IAST false positive rates are low, so most reported issues will be real. Each finding includes the file, line number, and data flow path. Prioritize by severity and fix the critical ones first. Improve test coverage. IAST only sees what your tests trigger. If coverage is low, you are leaving blind spots. Use the IAST agent's coverage metrics to identify untested endpoints and write additional tests for them. Evaluate CI integration. Once you trust the results, integrate IAST into your pipeline. The agent runs during your existing test phase, so there is no additional scan step. Add quality gates to block deployments on critical findings. Consider adding SAST and DAST. IAST alone is not enough. [SAST](/sast-tools) covers the full codebase including code paths your tests do not reach. [DAST](/dast-tools) covers server-level issues that IAST agents do not see. See our [SAST vs DAST vs IAST comparison](/application-security/sast-vs-dast-vs-iast) for guidance on combining approaches. --- ## FAQ {#faq} --- # What is Mobile Application Security Testing? URL: https://appsecsanta.com/mobile-security-tools/what-is-mobile-security Description: MAST finds vulnerabilities in iOS and Android apps through static, dynamic, and behavioral analysis. Covers OWASP Mobile Top 10, top tools, and CI/CD setup. ## What mobile security testing means {#what-mobile-security-testing-means} Mobile Application Security Testing analyzes iOS and Android apps for security vulnerabilities. It covers the compiled binary, the app's runtime behavior, its network traffic, and how it stores data on the device. Unlike web application testing, MAST deals with code that runs on a device you do not control. The app binary ships to millions of phones. Anyone with the right tools can decompile it, extract secrets, reverse-engineer the logic, and tamper with its behavior. Once the APK or IPA leaves your build server, you cannot patch it without pushing an update through the app store. That changes the threat model. A web application sits behind your firewall. A mobile app sits on the attacker's device. MAST tools deal with this by throwing multiple techniques at the problem. They decompile the binary and scan the resulting code. They run the app on emulators or real devices and watch what it does. They intercept network traffic. They check whether hardening controls like certificate pinning and root detection actually work or just look like they do. Mobile apps now handle banking, healthcare, payments, and identity verification. That is why Gartner included mobile application security testing in their 2025 Hype Cycle for Application Security, and why OWASP maintains a dedicated Mobile Top 10 alongside the better-known web Top 10. --- ## Why does mobile security matter? {#why-mobile-security-matters} Mobile apps process sensitive data on hardware you do not own or control. The risks are different from web, and in some ways worse. **Reverse engineering is trivial.** Android APKs can be decompiled back to readable Java or Kotlin code using freely available tools like [jadx](https://github.com/skylot/jadx) and apktool. iOS apps are harder to crack but not immune. Any API key, encryption key, or business logic hardcoded in the binary is exposed to anyone willing to spend ten minutes decompiling it. **Local data storage is a minefield.** Mobile apps store data in SharedPreferences, SQLite databases, plist files, [Keychain](https://developer.apple.com/documentation/security/keychain_services), and the file system. If the app stores authentication tokens, personal data, or encryption keys in unprotected locations, any app on a rooted device or any attacker with physical access can read them. **Regulatory pressure is increasing.** GDPR, CCPA, PCI-DSS, and HIPAA all apply to mobile apps that handle personal or financial data. App store reviews from Apple and Google are getting stricter about privacy disclosures and data handling. Google Play's Data Safety section and Apple's App Privacy labels force transparency. **Third-party SDKs are a blind spot.** According to NowSecure research, the average mobile app includes 20 to 30 third-party SDKs for analytics, advertising, crash reporting, and social login. Each SDK collects its own data and carries its own vulnerabilities. You probably did not audit any of them. [Data Theorem](/data-theorem) specifically targets this problem with third-party SDK analysis. **The attack surface is wider than web.** Mobile apps talk to device hardware (camera, GPS, biometrics), communicate with other apps through inter-process channels, handle push notifications and deep links, and call platform-specific APIs. Each one is a potential entry point that web applications simply do not have. --- ## OWASP Mobile Top 10 {#owasp-mobile-top-10} OWASP released the latest [Mobile Top 10](https://owasp.org/www-project-mobile-top-10/) in late 2023 (commonly referenced as the 2024 edition). It lists the most critical security risks in mobile applications. Most mobile security tools map their findings to these categories. **M1 — Improper Credential Usage.** Hardcoded credentials, API keys, and secrets embedded in the app binary. This is the most common finding in mobile security scans because developers frequently store keys in code rather than fetching them from a secure backend. **M2 — Inadequate Supply Chain Security.** Third-party libraries and SDKs with known vulnerabilities or malicious behavior. The mobile supply chain is harder to audit than web because SDKs often ship as pre-compiled binaries. **M3 — Insecure Authentication/Authorization.** Weak authentication mechanisms, client-side authorization checks, and missing session management. Mobile apps sometimes perform authorization logic on the device rather than the server, which is trivially bypassable. **M4 — Insufficient Input/Output Validation.** SQL injection, path traversal, and injection attacks through local inter-process communication, deep links, and WebViews. Mobile-specific inputs like Intent extras (Android) and URL schemes (iOS) are common attack vectors. **M5 — Insecure Communication.** Missing or improperly implemented TLS, disabled certificate validation, cleartext HTTP traffic. Certificate pinning bypass is a dedicated testing area for mobile security tools. **M6 — Inadequate Privacy Controls.** Excessive data collection, insufficient user consent, and privacy-violating SDK behavior. This category became more important with stricter app store privacy requirements. **M7 — Insufficient Binary Protections.** Missing code obfuscation, no anti-tampering controls, no root or jailbreak detection. Without binary protection, attackers can modify app behavior, bypass license checks, and inject malicious code. **M8 — Security Misconfiguration.** Overly permissive app permissions, debug mode left enabled, backup allowed, insecure default settings. These are easy to detect and easy to fix, yet they appear in most security scans. **M9 — Insecure Data Storage.** Sensitive data stored in plaintext in SharedPreferences, SQLite databases, log files, or clipboard. This overlaps with M1 but covers broader data handling beyond credentials. **M10 — Insufficient Cryptography.** Weak algorithms, hardcoded encryption keys, improper key management. Using AES with a key embedded in the binary provides no real protection. --- ## Types of mobile security testing {#types-of-mobile-security-testing} Mobile security testing is not one thing. It is several techniques stacked together, and most tools use all of them. ### Static analysis (SAST for mobile) The tool decompiles the APK or IPA into readable code and scans it for vulnerabilities. This catches hardcoded secrets, insecure API calls, missing encryption, improper permission usage, and vulnerable third-party libraries. [MobSF](/mobsf), [Oversecured](/oversecured), and [AppKnox](/appknox) all perform static analysis on compiled binaries. Static analysis for mobile differs from traditional SAST because it works with decompiled code rather than original source. The analysis quality depends on how well the tool handles obfuscated code, ProGuard-shrunk classes, and cross-language apps (Kotlin calling Java, Swift calling Objective-C). ### Dynamic analysis (DAST for mobile) The tool installs the app on an emulator or real device, interacts with it, and monitors its behavior at runtime. This catches insecure network communication, improper data storage during use, runtime permission issues, and authentication flaws. [esChecker](/eschecker) focuses specifically on dynamic and interactive testing. Dynamic analysis reveals issues that static analysis misses: server-side responses, actual network traffic patterns, real data written to local storage during use, and behavior triggered by specific user actions. ### Behavioral analysis Goes deeper than basic dynamic testing. The tool monitors system calls, file system changes, network connections, and inter-process communication while the app runs. This is where you catch data leaking through logs, clipboard, screenshots, and background processes. [NowSecure](/nowsecure) does particularly thorough behavioral and privacy analysis. ### API backend testing Mobile apps are only half the picture. The APIs they communicate with are the other half. Several mobile security tools test the backend endpoints the app calls, checking for broken authentication, excessive data exposure, and injection vulnerabilities in the API layer. [Data Theorem](/data-theorem) extends mobile testing to cover the full API surface. ### Binary protection assessment Checks whether your hardening measures actually work: code obfuscation, anti-tampering controls, root and jailbreak detection, debugger detection, certificate pinning. It is one thing to implement these controls. It is another to verify that a determined attacker cannot bypass them in five minutes with Frida. [Zimperium zScan](/zimperium-zscan) specializes in this validation, and [Talsec](/talsec) provides RASP-based runtime protection SDKs. --- ## How do mobile security tools work? {#how-mobile-security-tools-work} Whether you use MobSF or a six-figure enterprise platform, the workflow is broadly the same. ### Binary upload and decompilation You upload an APK (Android) or IPA (iOS) file. The tool decompiles it using tools like [jadx](/jadx), dex2jar, or class-dump under the hood. Android apps decompile reliably into Java or smali bytecode. iOS apps require more effort because of Apple's code signing and encryption, though most commercial tools handle this automatically. ### Static scanning The decompiled code gets analyzed for known vulnerability patterns. The tool checks for hardcoded API keys and secrets, insecure cryptographic implementations, improper platform API usage, overly broad permissions, and vulnerable third-party libraries. [Oversecured](/oversecured) covers 175+ Android and 85+ iOS vulnerability categories at this stage with a claimed 99.8% detection accuracy. ### Dynamic analysis on emulator or device The tool installs the app on an Android emulator or iOS simulator (or a real device for deeper testing). It exercises the app's functionality, either through automated interaction or instrumentation frameworks like [Frida](https://frida.re/docs/home/). During this phase, the tool monitors network traffic for cleartext communication and certificate validation issues, local storage for sensitive data written to disk, log output for leaked information, and inter-process communication for exploitable handlers. [MobSF](/mobsf) uses Frida for instrumentation during dynamic analysis. Commercial tools like [NowSecure](/nowsecure) and [Zimperium zScan](/zimperium-zscan) run tests on real device farms for more accurate results. ### Network traffic interception The tool proxies the app's network traffic to see what data leaves the device and how it is protected. TLS implementation, certificate pinning enforcement, cleartext HTTP fallbacks, sensitive data in request headers or query parameters. You would be surprised how many production apps still send authentication tokens over unencrypted connections or pass user IDs in URL parameters. ### Reporting and compliance mapping Results get mapped to OWASP MASVS categories, compliance frameworks (PCI-DSS, GDPR, HIPAA), and severity ratings. Most tools generate PDF or HTML reports suitable for compliance audits. [AppKnox](/appknox) maps findings to GDPR, PCI-DSS, HIPAA, NIST, and SAMA frameworks. --- ## Mobile-specific vulnerabilities {#mobile-specific-vulnerabilities} These are the issues that make mobile a different beast from web application security. **Insecure data storage.** Apps store sensitive data in SharedPreferences (Android) or UserDefaults (iOS) without encryption. SQLite databases with plaintext credentials. Cached web content containing authentication tokens. Log files with personal information. Every mobile security tool checks for these, and they appear in nearly every scan. **Certificate pinning bypass.** Certificate pinning prevents man-in-the-middle attacks by checking that the server's certificate matches an expected value. Sounds solid in theory. In practice, improper implementation makes it trivially bypassable. Frida and [objection](https://github.com/sensepost/objection) can disable most pinning implementations in a few commands. Security tools verify that your pinning actually holds up. **Root and jailbreak detection gaps.** Apps that handle sensitive operations should detect rooted or jailbroken devices. The problem is that detection methods are well-documented and bypass techniques are freely available on GitHub. It is an arms race. [Talsec](/talsec) takes a different approach with RASP-based runtime integrity monitoring rather than simple one-time detection checks. **Hardcoded secrets in binaries.** API keys, encryption keys, OAuth client secrets, and Firebase configuration data embedded in the app binary. String extraction from a decompiled APK takes seconds. This remains the single most common vulnerability in mobile security assessments because developers treat the binary as if it were a private container. **Insecure inter-process communication.** Android Intents and iOS URL schemes that accept input from other apps without validation. A malicious app on the same device can send crafted data through these channels. Exported Android components (activities, services, broadcast receivers) without proper permission checks are a frequent finding. **WebView vulnerabilities.** Mobile apps that use WebViews to display web content inherit every vulnerability a web browser has. The real danger is JavaScript bridges that expose native functionality to web content. An XSS in a WebView with a JavaScript bridge can give an attacker access to device APIs, contacts, and file storage. It is worse than XSS on the web because the blast radius is the entire device. **Insecure deep links.** Custom URL schemes and Android App Links that can be hijacked by malicious apps. If the app does not properly validate deep link parameters, attackers can trigger unintended actions or steal authentication tokens through link interception. **Clipboard data leakage.** Apps that copy sensitive data (passwords, tokens, account numbers) to the clipboard expose it to every other app on the device. On older Android versions, any app could read the clipboard without restriction. --- **Looking for tools?** See our complete [mobile security tools comparison](/mobile-security-tools) with 17 tools rated and reviewed. --- ## Getting started {#getting-started} If you have never run a mobile security scan, here is a practical path. Start with [MobSF](/mobsf). Install it locally or use Docker. Upload your APK or IPA and run a static scan. Within minutes you will have a report showing hardcoded secrets, insecure configurations, overly broad permissions, and vulnerable libraries. This first scan always produces findings, even on apps you thought were secure. Triage the results. Not everything MobSF flags is a real risk. A debug certificate warning on a release build matters. A debug certificate warning on a development build does not. Go through the findings, understand which ones apply to your threat model, and prioritize based on actual impact. Run dynamic analysis. Static analysis cannot tell you what the app does at runtime. Set up an Android emulator with MobSF or use a commercial tool to run the app and monitor its behavior. Watch for sensitive data written to local storage, cleartext network traffic, and information leaked to logs. Check your hardening controls. If your app handles sensitive data, verify that certificate pinning, root detection, code obfuscation, and anti-tampering measures are in place and working. [Zimperium zScan](/zimperium-zscan) and [Talsec](/talsec) specialize in this. Integrate into CI/CD. Add mobile security scanning to your build pipeline. Most tools accept APK and IPA uploads via API. Block releases when critical vulnerabilities appear. [Oversecured](/oversecured) and [AppKnox](/appknox) both support CI/CD integration that can fail builds on critical findings. Test third-party SDKs. You are responsible for the behavior of every SDK in your app. Run scans specifically looking at what data third-party libraries collect and transmit. [Data Theorem](/data-theorem) and [NowSecure](/nowsecure) provide detailed SDK analysis. Consider runtime protection. Scanning catches vulnerabilities before release. But the app still runs on devices you do not control. Runtime protection like [Talsec](/talsec) freeRASP defends the app after it ships. For apps handling financial or health data, both layers are worth having. --- ## FAQ {#faq} --- # What is RASP? URL: https://appsecsanta.com/rasp-tools/what-is-rasp Description: RASP agents live inside your application and block attacks in real-time with context-aware detection. Compare RASP vs WAF, review top tools, and get started. ## What RASP actually does {#what-rasp-actually-does} Runtime Application Self-Protection is a security agent that lives inside your application and blocks attacks as they happen. Not before they reach the application (that is a WAF). Not after the fact (that is a SIEM). During execution, in real-time, with full visibility into what the application is doing with each request. The difference from other security tools matters. [SAST](/sast-tools) and [DAST](/dast-tools) find vulnerabilities. They tell you where the problems are so you can fix them. RASP does not find vulnerabilities. It blocks their exploitation, whether you know about them or not. If an attacker discovers a SQL injection in your application before you do, a RASP agent can block the exploit because it sees untrusted input reaching a SQL query at runtime. No prior knowledge of the vulnerability required. I have deployed RASP at financial services companies where false positive rates are unacceptable. A blocked legitimate request means a failed transaction. The context-aware detection that RASP provides, seeing what the application is actually doing with each input, makes it far more accurate than perimeter defenses. Mordor Intelligence estimates the RASP market reached $2.02 billion in 2025, forecast to grow to $7.17 billion by 2030 at a 28.82% CAGR ([Mordor Intelligence, RASP Market Report, 2025](https://www.mordorintelligence.com/industry-reports/runtime-application-self-protection-market)). --- ## How RASP works {#how-rasp-works} RASP uses runtime instrumentation to observe application behavior and intervene when an attack is detected. ### Agent installation The RASP agent loads into the application runtime. For Java, this means a JVM agent in your startup configuration. For .NET, a CLR profiler. For Node.js, an npm module loaded at application startup. One-time setup during deployment, either by modifying startup scripts or baking it into container images. ### Function hooking The agent hooks into security-sensitive functions: SQL query execution, file I/O, command execution, network calls, deserialization. These hooks sit between the application code and the dangerous operation, intercepting data before it reaches the underlying function. ### Context-aware detection When a hooked function is called, the agent examines the input in context. A WAF sees an HTTP request containing `' OR 1=1--` and blocks it based on the pattern. The RASP agent sees that this string arrived from user input, passed through the application code without sanitization, and is about to be concatenated into a SQL query string. The WAF guesses. RASP knows. This is why RASP has dramatically lower false positive rates than WAFs. A WAF might block a legitimate request that happens to contain SQL-like syntax (a blog post about SQL injection, for example). RASP would not block it because it can see the input is going to a text field, not a SQL query. ### Block or monitor Depending on configuration, RASP either blocks the malicious request immediately or logs it for review. Every vendor recommends starting in monitor mode. Run the agent for a few weeks, review what it would have blocked, verify there are no false positives, then switch to blocking mode. Do not skip this step. Blocking legitimate requests in production is worse than the vulnerability you are trying to protect against. --- ## RASP vs WAF {#rasp-vs-waf} RASP and WAFs both protect running applications, but they work differently enough that the comparison is worth spelling out. | | RASP | WAF | |---|---|---| | **Location** | Inside the application process | In front of the application (network perimeter) | | **Detection method** | Code execution context | HTTP traffic pattern matching | | **False positives** | Low (sees actual code behavior) | Higher (pattern matching only) | | **Performance impact** | 2-10% latency added to the application | Minimal (separate infrastructure) | | **Deployment** | Per-application agent install | Network-level, covers all apps at once | | **Zero-day protection** | Good (detects exploitation behavior) | Limited (needs rules for known patterns) | | **DDoS protection** | No | Yes | | **Cost per application** | Higher (agent per app) | Lower (one WAF for many apps) | My take: if you can afford both, use both. WAFs give you perimeter defense and DDoS protection. RASP gives you accurate, context-aware protection for your most critical applications. If you must choose one, a WAF is the safer starting point because it requires no application changes and covers all your applications at once. RASP makes the most sense for high-value applications where false positives are unacceptable: payment processing, authentication services, anything handling PII or financial data. You do not need RASP on every application. You need it on the ones where a blocked legitimate request or a missed attack has real consequences. --- ## What does RASP protect against? {#what-rasp-protects-against} RASP is effective against attacks where untrusted input reaches dangerous functions: - **SQL injection** — The agent sees untrusted input being concatenated into a SQL query and blocks it before execution. - **Command injection** — User input reaching system command execution functions. - **Cross-site scripting (XSS)** — Tainted input being rendered in HTTP responses without encoding. - **Path traversal** — User input used to construct file paths that escape the intended directory. - **Insecure deserialization** — Untrusted data being deserialized without type validation. - **Zero-day exploitation** — Because RASP detects attack behavior rather than known signatures, it can block exploits for vulnerabilities that have not been publicly disclosed yet. RASP is less effective against DDoS, network-level attacks, and attacks targeting infrastructure rather than the application. That is WAF and network security territory. --- ## What is the performance impact? {#the-performance-question} Every RASP conversation eventually gets to performance. The honest answer: yes, it adds overhead. How much depends on the tool, the application, and the configuration. Typical latency overhead ranges from 2% to 10%. [Waratek](/waratek) claims minimal overhead due to its virtualization-based architecture. [Contrast Protect](/contrast-security#contrast-protect-rasp) and [Datadog ASM](/datadog-asm) report overhead in the 2-5% range for most applications. For a web application with 200ms average response time, 5% overhead means 10ms added per request. Most users will not notice. For a high-frequency trading system or real-time gaming backend, 10ms might be unacceptable. The practical approach: deploy the agent in a staging environment identical to production. Run your load tests with and without the agent. Measure the actual latency difference for your specific application and traffic patterns. Then decide whether the protection is worth the overhead. Do not rely on vendor benchmarks. Every application has different call patterns, and the overhead varies with how many security-sensitive function calls your code makes. --- ## Deployment considerations {#deployment-considerations} How hard RASP is to deploy depends on your infrastructure. **Traditional VMs and bare metal.** Add the agent to your application server startup configuration. For Tomcat, add the Java agent to `CATALINA_OPTS`. For IIS, install the .NET profiler. One-time setup. **Docker and Kubernetes.** Modify your Dockerfile to include the agent, or use init containers. Every image rebuild needs the agent, which adds a CI/CD step and increases image size. Some teams use admission controllers to inject the agent automatically. **Serverless (Lambda, Cloud Functions).** Most RASP tools do not support serverless. Functions are ephemeral, start from scratch on each invocation, and the startup overhead of loading a RASP agent is too high. If you run serverless, use [SAST](/sast-tools) and [DAST](/dast-tools) for security testing and your cloud provider's WAF for runtime protection. --- ## Why has the RASP market consolidated? {#market-consolidation} The standalone RASP market has consolidated heavily since 2020. Knowing what happened helps you make sense of the current product landscape. **Sqreen was acquired by Datadog (2021).** Sqreen's RASP engine became [Datadog Application Security Management (ASM)](/datadog-asm). If you already use Datadog for APM, their RASP is a natural add. **Signal Sciences was acquired by Fastly (2020).** Signal Sciences became the foundation of Fastly's Next-Gen WAF. It is still available but not sold as a standalone RASP product anymore. **K2 Cyber Security was acquired by New Relic (2022).** The technology was integrated into New Relic's security monitoring. **Hdiv Security was acquired by Datadog (2022).** Integrated into Datadog Code Security. The standalone product is no longer maintained. The pattern: RASP is being absorbed into APM and observability platforms. Datadog, New Relic, and Dynatrace all have RASP capabilities now. RASP agents are architecturally similar to APM agents — both instrument the application runtime — so bundling them reduces deployment complexity. For buyers, this means your RASP choice may come down to which observability platform you already use. --- **Looking for tools?** See our complete [RASP tools comparison](/rasp-tools) with 10 tools rated and reviewed. --- ## Getting started {#getting-started} RASP is not the first security tool you should adopt. It makes the most sense after you have SAST and DAST in place and need runtime protection for critical applications. Identify your highest-value applications. RASP is deployed per-application, so start with the ones where a successful attack would cause the most damage: payment processing, user authentication, anything handling PII or financial data. Check language support. Java and .NET have the most options. Node.js and Python are covered by fewer tools. Go and Rust have almost no RASP support. Deploy in monitor mode first. Install the agent on staging. Let it run alongside normal testing for a few weeks. Review what it flags. Verify there are no false positives. Validate performance. Run load tests with and without the agent. Measure the actual latency impact. Move to blocking mode. Once you trust the agent and the performance impact is acceptable, enable blocking on staging. Test thoroughly. Then move to production. Do not stop fixing vulnerabilities. RASP is a safety net, not a patch. If RASP catches a SQL injection, fix the code. RASP protects you while the fix is in progress and catches zero-days that no patch exists for yet. But the goal is always to fix the root cause. --- ## FAQ {#faq} --- # What is SAST? URL: https://appsecsanta.com/sast-tools/what-is-sast Description: SAST is the security subset of static code analysis — it scans source code for vulnerabilities before your app runs. Learn how it works, what it catches, and CI/CD setup. ## What SAST actually does {#what-sast-actually-does} Static Application Security Testing scans your source code for security vulnerabilities without running the application. It reads your code the way a security reviewer would, except it does it in minutes instead of days. The "static" part is what matters. SAST tools analyze code at rest. They do not need a running application, a staging environment, or a deployed server. Point the tool at your repository and it tells you where the problems are, down to the file and line number. A developer pushes code, the CI pipeline runs a SAST scan, and within minutes they know if they introduced a SQL injection or a cross-site scripting vulnerability. Fix it before the pull request merges. That is the whole idea. SAST has been around since the early 2000s. The first generation of tools was slow, noisy, and expensive. Modern SAST tools are faster, more accurate, and many are free. But the core concept has not changed: read the code, find the bugs, tell the developer where to look. IBM's 2025 Cost of a Data Breach Report puts the global average at [$4.44 million](https://www.ibm.com/reports/data-breach) — down 9% from $4.88 million in 2024 but still high enough that catching vulnerabilities before they reach production is not optional for most organizations. Yes, SAST is the application-security subset of static code analysis. All SAST is static code analysis, but not all static code analysis is SAST — tools like [ESLint](https://eslint.org/) (JavaScript linting) and Kotlin's built-in null-safety analysis inspect code without running it but target quality and correctness, not security. Throughout this guide I use "SAST" for security-specific scanners and "static code analysis" for the broader category. --- ## How does static analysis work? {#how-static-analysis-works} SAST tools use several techniques to find vulnerabilities. Not every tool uses all of them, and the depth of analysis is a major differentiator between free and commercial products. ### Parsing and AST generation The tool parses your source code into an abstract syntax tree (AST), a structured representation that can be traversed regardless of formatting or coding style. Most tools build language-specific ASTs, though some (like [Semgrep CE](/semgrep)) use a cross-language intermediate representation. ### Pattern matching The simplest technique. The tool looks for known-bad patterns in the AST: calls to deprecated functions, use of insecure cryptographic algorithms, hardcoded credentials. Fast and low on false positives, but it only catches low-hanging fruit. [Bandit](/bandit) and [gosec](/gosec) rely heavily on pattern matching. They are fast and easy to configure, but they miss anything that requires understanding how data flows through your application. ### Data flow analysis This is where SAST tools earn their keep. Data flow analysis (also called taint analysis) tracks the path of user-controlled input from its source (where it enters the application) to its sink (where it does something dangerous). A concrete example: in a Java web application, data flow analysis traces a value from `HttpServletRequest.getParameter("id")` through several method calls, string concatenations, and variable assignments until it reaches `Statement.executeQuery(sql)`. If no sanitization or parameterized query is used along the way, the tool flags it as a SQL injection. The depth of this analysis varies enormously. Some tools only trace data flow within a single function (intra-procedural). Enterprise tools like [Checkmarx](/checkmarx), [Coverity](/coverity), and [Fortify](/fortify-static-code-analyzer) trace across function calls, files, and separate modules (inter-procedural). Deeper analysis catches more real bugs but takes longer to run. ### Control flow analysis Control flow analysis checks the order of operations: race conditions, resource leaks (opening a file but never closing it), improper error handling. This matters most for C/C++ code where manual resource management is common. ### Configuration analysis Some SAST tools also check configuration files: web.xml, application.properties, YAML configs. Misconfigured security headers, disabled CSRF protection, overly permissive CORS settings. --- ## What does SAST catch? {#what-sast-catches} SAST is good at finding vulnerabilities that have clear code-level patterns: - **Injection flaws** — SQL injection, command injection, LDAP injection, XPath injection. Anywhere user input reaches a dangerous function without sanitization. - **Cross-site scripting (XSS)** — User input rendered in HTML responses without encoding. - **Hardcoded secrets** — API keys, passwords, and tokens committed to source code. - **Insecure cryptography** — Use of deprecated algorithms (MD5, SHA-1 for password hashing), weak key lengths, or ECB mode. - **Buffer overflows** — Particularly in C and C++, where array bounds are not checked automatically. - **Path traversal** — User input used to construct file paths without validation. - **Insecure deserialization** — Deserializing untrusted data without type checks. These all follow recognizable patterns in source code. A data flow from user input to a SQL query without parameterization looks the same regardless of who wrote it. --- ## Static Code Analysis vs SAST: Terminology {#static-code-analysis-vs-sast-terminology} Static code analysis is any technique that inspects source code, bytecode, or binaries without executing them. SAST is the security-focused subset of that umbrella — the part that hunts for vulnerabilities like SQL injection, XSS, and hardcoded secrets rather than style issues or dead code. The broader category covers four overlapping practices. Linters (ESLint, Pylint, RuboCop) enforce coding style and catch obvious bugs. Code quality scanners like SonarQube check for code smells, duplication, and complexity. Type and null-safety analyzers (mypy for Python, Kotlin's compiler, TypeScript's `strict` mode) prove correctness properties. SAST overlaps with all of these but optimizes for security-relevant sinks and taint flows. Developers and tool vendors often use the two terms interchangeably, which is usually fine in casual conversation. SonarQube markets itself as both "code quality" and "SAST" because the same engine does both jobs. [Fortify Static Code Analyzer](/fortify-static-code-analyzer) puts "static code analysis" in the product name even though it is firmly a SAST tool. The distinction matters in three situations. In procurement, RFPs ask specifically for "SAST" when they mean tools with CWE coverage and OWASP Top 10 rules — a generic linter will not pass. In analyst research, Gartner and Forrester segment "SAST" separately from "code quality" in their Magic Quadrant and Wave reports. In compliance language, standards like [NIST SSDF](https://csrc.nist.gov/projects/ssdf) (PW.7.2) and [PCI DSS 4.0](https://www.pcisecuritystandards.org/) (6.2.3) reference "static analysis" generically but expect security-specific tooling during assessment. --- ## Where does SAST fall short? {#where-sast-falls-short} SAST cannot see everything. Knowing the gaps helps you decide where to add other testing methods. **Runtime and configuration issues.** SAST does not execute the application, so it misses server misconfigurations, missing security headers, and authentication bypass that depends on server configuration. That is [DAST](/dast-tools) territory. **Business logic flaws.** If your pricing logic lets users buy items for negative amounts, SAST will not catch it. The code is syntactically correct; the logic is wrong. **False positives.** SAST flags code that looks dangerous even when it is not. A function that accepts user input and passes it to a database query might have sanitization in a middleware layer that the tool does not model. Untuned SAST can produce false positive rates of 30-60%, which is enough to make developers ignore it entirely. Adding [IAST](/iast-tools) alongside SAST helps validate findings with runtime data. For practical techniques to bring false positive rates down, see the [guide to reducing SAST false positives](/sast-tools/reducing-sast-false-positives). **Framework-specific behavior.** If a SAST tool does not understand your framework, it reports false vulnerabilities. A tool that does not understand Django's ORM will flag database queries as SQL injection risks even though the ORM parameterizes them automatically. **Third-party dependencies.** SAST scans your code, not the code inside your npm packages or Maven dependencies. That is [SCA](/sca-tools) territory. For a detailed breakdown of how the two approaches complement each other, see the [SAST vs SCA comparison](/application-security/sast-vs-sca). --- ## SAST in your CI/CD pipeline {#sast-in-your-cicd-pipeline} Running SAST manually works for a one-time audit. The real value comes from running it automatically on every code change. ### Pre-commit and IDE The fastest feedback loop. [Snyk Code](/snyk#snyk-code-sast) and SonarLint scan code in the IDE as developers type. [Semgrep CE](/semgrep) and [Bandit](/bandit) can run as pre-commit hooks, catching issues before code is even pushed. ### Pull request scanning The most common setup. The CI pipeline runs SAST on every pull request and posts findings as PR comments. Developers see issues in context, right next to the code they changed. [SonarQube](/sonarqube), [Checkmarx](/checkmarx), and [Snyk Code](/snyk#snyk-code-sast) all do this well. ### Quality gates Block merges when critical vulnerabilities appear. Without enforcement, SAST findings become suggestions that get ignored. [SonarQube](/sonarqube) quality gates and [Checkmarx](/checkmarx) policies are the most common implementations. ### Baseline management When you first run SAST on an existing codebase, you will get hundreds or thousands of findings. Nobody fixes all of those on day one. Baseline the existing findings, require that all new code is clean, and fix legacy issues gradually. Most commercial tools support this out of the box. --- ## Open-source vs commercial {#open-source-vs-commercial} The gap between free and paid SAST tools is real, but not as wide as vendors want you to believe. [Semgrep CE](/semgrep), [SonarQube Community Edition](/sonarqube), [Bandit](/bandit), and [Brakeman](/brakeman) handle pattern matching and basic data flow well — see the [open-source SAST tools roundup](/sast-tools/open-source-sast-tools) for the full free stack. Semgrep CE in particular has a strong rule ecosystem and makes writing custom rules straightforward. For cross-file taint analysis, [Semgrep Code](/semgrep) extends the engine with deeper inter-file capabilities. For teams using a single primary language, these are often enough. [Checkmarx](/checkmarx), [Fortify](/fortify-static-code-analyzer), [Veracode](/veracode#veracode-static-analysis-sast), and [Snyk Code](/snyk#snyk-code-sast) add deeper inter-procedural data flow analysis, broader language coverage, better IDE integration, compliance dashboards, and dedicated support — covered in the [enterprise SAST tools shortlist](/sast-tools/enterprise-sast-tools). The analysis depth matters most for large codebases with complex call chains across multiple files and modules. The honest take: if you are a small team writing a Python web application, [Bandit](/bandit) plus [Semgrep CE](/semgrep) will catch most of what a $200K enterprise tool would find. If you are an enterprise with 50 applications across Java, .NET, Go, and Python, commercial tools earn their price through breadth and management features. --- **Looking for tools?** See our complete [SAST tools comparison](/sast-tools) with 30+ tools rated and reviewed. --- ## Getting started {#getting-started} If you have never run SAST before, here is a practical path. Pick a tool that supports your primary language. Do not overthink this. [Semgrep CE](/semgrep) for multi-language, [Bandit](/bandit) for Python, [Brakeman](/brakeman) for Rails. Install it and run it locally. Triage the initial results. The first scan will produce noise. Go through the findings, identify real issues, suppress the false positives. This is an afternoon's work, not a month-long project. Add it to CI. Run the tool on every pull request. Start in warning mode (do not block merges yet). Let the team get used to seeing findings. Enable quality gates. Once the team is comfortable, block merges on critical and high-severity findings. Keep medium as warnings. Write custom rules. Every codebase has patterns that generic rules miss. If you use an internal framework or have specific security requirements, write rules for those. [Semgrep CE](/semgrep) and [CodeQL](/github-codeql) make this straightforward. Consider adding DAST. SAST covers your code. [DAST](/dast-tools) covers your running application. Together they give you much better coverage than either alone. See our [SAST vs DAST vs IAST comparison](/application-security/sast-vs-dast-vs-iast) for guidance. --- --- # What is SBOM? URL: https://appsecsanta.com/sca-tools/what-is-sbom Description: An SBOM lists every software component you ship. Learn why regulations now require it, CycloneDX vs SPDX formats, and which tools generate SBOMs effectively. ## What SBOM is {#what-sbom-is} A Software Bill of Materials (SBOM) is a machine-readable inventory of every component inside a piece of software. It lists every open-source library, third-party dependency, framework, and module, along with version numbers, licenses, and supplier information. The concept borrows from manufacturing. A car manufacturer knows every part in every vehicle: the steel grade, the chip supplier, the tire model. If a part is recalled, the manufacturer knows exactly which vehicles are affected. Software has lacked this transparency for decades. When the Log4Shell vulnerability hit in December 2021, most organizations could not answer a basic question: "Do we use Log4j, and where?" An SBOM answers that question definitively. If you have an accurate, up-to-date SBOM for every application, you can query it in minutes and know exactly which applications, services, and deployments contain a vulnerable component. Modern software is mostly assembled, not written from scratch. According to the Synopsys OSSRA report, 70 to 90 percent of the code in a typical application comes from open-source libraries and third-party components. An SBOM makes that invisible majority visible. --- ## Why does SBOM matter? {#why-sbom-matters} SBOMs have moved from a nice-to-have to a regulatory requirement. Three forces are driving adoption: **Supply chain attacks are increasing.** The SolarWinds compromise, the Codecov breach, the ua-parser-js malware incident, and the XZ Utils backdoor all exploited the trust organizations place in their software supply chain. An SBOM does not prevent these attacks, but it dramatically reduces response time when one hits. **Regulations now require it.** The U.S. Executive Order 14028, the EU Cyber Resilience Act, and FDA medical device guidance all mandate SBOM generation and sharing in specific contexts. Organizations selling software to the U.S. federal government or the EU market cannot ignore this. **Vulnerability management depends on it.** Without knowing what components you use, you cannot know what vulnerabilities affect you. SCA tools work by comparing your dependency list against vulnerability databases. An SBOM is the standardized, shareable version of that dependency list. The practical benefit is speed. When the next critical vulnerability drops, organizations with SBOMs measure their response time in hours. Organizations without them measure it in weeks. --- ## SBOM formats {#sbom-formats} Two formats dominate the SBOM landscape. Both are accepted by U.S. and EU regulators, and both are machine-readable. ### CycloneDX CycloneDX is an OWASP-maintained standard designed with security as its primary focus. The current version is 1.7, released in October 2025. **Strengths:** - Native support for VEX (Vulnerability Exploitability eXchange), which lets you communicate whether a vulnerability actually affects your product - Supports multiple BOM types: SBOM, SaaSBOM, HBOM (hardware), AI/ML-BOM, and CBOM (cryptographic) - Available in JSON, XML, and Protocol Buffers - Tight integration with security tooling and vulnerability databases - Provenance tracking via citations (added in 1.7) ### SPDX SPDX (Software Package Data Exchange) is a Linux Foundation standard that originated in the open-source licensing and compliance space. Version 3.0 expanded its scope to include security use cases. **Strengths:** - Deepest support for license compliance tracking - ISO/IEC 5962:2021 international standard - Broad adoption in legal and procurement workflows - Mature tooling ecosystem, especially for license review ### Format comparison | Feature | CycloneDX | SPDX | |---|---|---| | **Primary focus** | Security and vulnerability management | License compliance (expanded to security) | | **VEX support** | Native, first-class | Supported via external linking (SPDX 3.0) | | **Serialization** | JSON, XML, Protocol Buffers | JSON, XML, RDF, Tag-Value | | **Governance** | OWASP | Linux Foundation (ISO standard) | | **BOM types** | SBOM, SaaSBOM, HBOM, AI/ML-BOM, CBOM | SBOM focused | | **Best for** | Security teams, DevSecOps | Legal review, license compliance | If your primary use case is security and vulnerability management, CycloneDX is the stronger choice. If you need license compliance tracking for legal review, SPDX has deeper support. Many organizations generate both: CycloneDX for their security team and SPDX for their legal team. --- ## Regulations and mandates {#regulations-and-mandates} Several regulations now require or strongly encourage SBOM generation: **U.S. Executive Order 14028 (2021).** Requires SBOM submission for any software sold to U.S. federal agencies. SBOMs must be machine-readable (CycloneDX or SPDX), traceable, and kept current through software updates. NIST published minimum elements guidance that defines what an SBOM must contain. **EU Cyber Resilience Act (CRA).** Applies to manufacturers of digital products sold in the EU. Requires an up-to-date, machine-readable SBOM as part of technical documentation, available for audit by market surveillance authorities. Vulnerability and incident reporting requirements take effect September 2026. Full SBOM requirements take effect December 2027. **FDA medical device guidance.** Since October 2023, the FDA requires an SBOM as part of premarket submissions for medical devices. All software components must be disclosed, including open-source libraries and their versions. **NIS2 Directive.** The EU's updated Network and Information Security Directive encourages SBOM adoption for essential and important entities as part of supply chain risk management. **PCI DSS 4.0.** While not explicitly mandating SBOMs, PCI DSS 4.0 requires organizations to maintain an inventory of custom and third-party software, which SBOMs directly support. The regulatory trend is clear: SBOM will become a baseline requirement across industries. Starting now avoids a scramble later. --- ## How do you generate an SBOM? {#how-to-generate-an-sbom} Generating an SBOM is not a one-time activity. It should be automated as part of your CI/CD pipeline. **Step 1: Choose your format.** CycloneDX for security-focused workflows, SPDX for compliance-focused workflows, or both if you need to serve multiple stakeholders. **Step 2: Integrate into your build.** Add SBOM generation as a build step in your CI/CD pipeline. Tools like Syft, Trivy, and the CycloneDX Maven/Gradle/NPM plugins generate SBOMs directly from your project's dependency manifest (package.json, pom.xml, go.mod, requirements.txt, etc.). **Step 3: Include transitive dependencies.** Ensure your tool resolves the full dependency tree, not just direct dependencies. Most vulnerabilities hide in transitive dependencies. **Step 4: Store and version SBOMs.** Treat SBOMs as release artifacts. Store them alongside build outputs in your artifact repository. Version them with each release so you can trace any deployed version back to its component list. **Step 5: Monitor continuously.** New vulnerabilities are disclosed daily. An SBOM generated last month is already stale from a vulnerability perspective. Use an SCA tool or SBOM management platform to continuously scan your stored SBOMs against updated vulnerability databases. --- ## SBOM tools {#sbom-tools} Several tools generate, manage, and analyze SBOMs. For a broader view of supply chain security tools, see AppSec Santa's [SCA tools](/sca-tools) page. **Generation tools:** | Tool | Type | Formats | Notes | |---|---|---|---| | **Syft (Anchore)** | Open-source CLI | CycloneDX, SPDX | Generates SBOMs from source, containers, and filesystems. Part of the [Anchore](/anchore) ecosystem. | | **Trivy** | Open-source CLI | CycloneDX, SPDX | Vulnerability scanner that also generates SBOMs. Covers containers, filesystems, and git repos. | | **CycloneDX plugins** | Open-source | CycloneDX | Language-specific plugins for Maven, Gradle, NPM, pip, Go, Rust, and more. | | **Microsoft SBOM Tool** | Open-source CLI | SPDX | Generates SPDX SBOMs. Used internally at Microsoft. | **Management and analysis platforms:** - **[Anchore](/anchore)** — Enterprise SBOM management with policy enforcement, continuous monitoring, and compliance reporting. Anchore Enterprise builds on the open-source Syft and Grype tools. - **[Chainguard](/chainguard)** — Provides hardened container images with built-in SBOMs and minimal attack surface. Their images ship with SBOM attestations, making compliance straightforward for containerized workloads. - **[Snyk Open Source](/snyk#snyk-open-source-sca)** — SCA tool that identifies vulnerable dependencies and can generate CycloneDX SBOMs. Strong developer workflow integration with IDE, CLI, and CI/CD support. - **FOSSA** — License compliance and SBOM platform. Particularly strong for organizations that need to track open-source license obligations alongside security vulnerabilities. --- --- # What is SCA? URL: https://appsecsanta.com/sca-tools/what-is-sca Description: SCA finds vulnerabilities and license issues in open-source dependencies. Learn how reachability analysis cuts alert noise, plus top free and paid tools. ## What SCA actually does {#what-sca-actually-does} Software Composition Analysis finds known vulnerabilities in the open-source libraries your application depends on. It does not scan your code. It scans your dependencies. Modern applications are mostly open source. The [Black Duck 2026 OSSRA report](https://www.blackduck.com/resources/analyst-reports/open-source-security-risk-analysis.html) found 98% of commercial codebases contain open-source components and 87% have at least one known vulnerability, with the mean number of vulnerabilities per codebase climbing 107% year-over-year to 581. You can write the most secure code in the world, but if you import a library with a critical vulnerability, you inherit that risk. SCA tools read your manifest files (package.json, pom.xml, requirements.txt, go.mod, Gemfile.lock), identify every direct and transitive dependency. They then cross-reference them against vulnerability databases like the National Vulnerability Database (NVD), [OSV](https://osv.dev/), and vendor-curated databases. The tool runs in seconds. It tells you which dependencies have known CVEs, how severe they are, and in many cases, which version to upgrade to. SCA also handles license compliance. Open source does not always mean "free to use however you want." A copyleft license like GPL can require you to open-source your own code. If you ship commercial software, SCA catches licensing conflicts before they become legal problems. --- ## How does SCA work? {#how-sca-works} SCA follows a simpler pipeline than SAST or DAST. Identify dependencies, check them against databases, report what you find. ### Dependency discovery The tool scans your manifest files and lock files to build a complete dependency tree: direct dependencies (what you explicitly installed) and transitive dependencies (what your dependencies depend on). A typical Node.js project with 20 direct dependencies might have 200+ transitive dependencies. Some tools also scan compiled binaries and container images to identify components not in manifest files. [Black Duck](/blackduck) is particularly strong at binary analysis. ### Vulnerability matching Each component and version is checked against vulnerability databases. [OWASP Dependency-Check](/owasp-dependency-check) uses NVD directly. Commercial tools like [Snyk](/snyk#snyk-open-source-sca) and [Mend](/mend#mend-sca) maintain their own curated databases that update faster. The speed difference matters: NVD can take weeks to publish a new CVE, while vendor databases often pick it up within hours. ### Reachability analysis This is what separates basic SCA from actually useful SCA. A dependency might have a vulnerability in a function your application never calls. Traditional tools report it anyway, and the noise piles up. Reachability analysis checks whether the vulnerable code path is actually reachable from your application. [Endor Labs](/endor-labs) and [Contrast SCA](/contrast-security#contrast-sca) do this through static call graph analysis. [Qwiet AI](/qwiet-ai) uses code property graphs. According to vendors like Endor Labs, the result is typically a 70-90% reduction in alerts, which makes a huge difference for developer adoption. ### License compliance SCA tools check the licenses of every dependency against your organization's policies. Common license types: - **MIT, Apache 2.0, BSD** — Permissive. Generally safe for commercial use. - **GPL, AGPL** — Copyleft. Can require you to open-source your own code if you distribute software. - **LGPL** — Weak copyleft. Typically okay for dynamic linking in commercial software. [FOSSA](/fossa) and [Black Duck](/blackduck) are the strongest tools for license compliance. [Snyk](/snyk#snyk-open-source-sca) covers it too, but with less depth on complex licensing scenarios. ### SBOM generation Most SCA tools can produce a Software Bill of Materials in [CycloneDX](https://cyclonedx.org/specification/overview/) or [SPDX](https://spdx.dev/use/specifications/) format. The [US Executive Order on Cybersecurity (2021)](https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity) mandates SBOMs for software sold to federal agencies, and adoption is growing beyond government. Even if compliance is not your concern today, having an SBOM makes it much faster to check whether you are affected when the next Log4Shell drops. For the full SBOM walkthrough, see [SBOM tools comparison](/sca-tools/sbom-tools-comparison). If you want a free tool that covers the whole pipeline, the [open-source SCA tools](/sca-tools/open-source-sca-tools) guide shortlists the twelve most-used options. For a broader view of the category, the [SCA tools hub](/sca-tools) collects all 30+ tools in one place. --- ## What does SCA catch? {#what-sca-catches} SCA focuses on a specific attack surface: - **Known vulnerabilities (CVEs)** — The core function. If a dependency version has a published CVE, SCA flags it. - **License violations** — Dependencies with licenses that conflict with your organization's policies or commercial distribution model. - **Outdated dependencies** — Components that are several versions behind, which may indicate unmaintained or abandoned libraries. - **Malicious packages** — Newer tools like [Socket](/socket) analyze package behavior to detect typosquatting, dependency confusion, and other supply chain attack patterns. Beyond the bullet list above, three things are worth spelling out because they trip people up when they first evaluate SCA. **CVE detection in dependencies is about matching, not discovery.** An SCA tool does not find new vulnerabilities; it matches your component versions against CVEs that have already been published to NVD, GHSA, OSV, or an ecosystem-specific feed. The tool's value is how fast and how accurately that match happens, not novel research. **Transitive-dependency-only vulnerabilities are the majority.** Most real-world findings live in packages your code does not import directly — they are pulled in by something you did import. A direct dependency scan catches only the tip; every tool on the [comparison list](/sca-tools) resolves the full tree. **Reachable vs raw CVE counts tell different stories.** A scanner without reachability reports every CVE in every component. A scanner with reachability (Endor Labs, Contrast SCA, OSV-Scanner guided remediation) reports only CVEs in code your application actually calls — usually 10-30% of the raw count. Both numbers are correct; they answer different questions. Licence conflicts and typosquats round out the surface. Licence conflicts are the non-security half of SCA — a GPL-licensed library in proprietary code is a legal exposure, not a CVE. Typosquats and compromised-maintainer releases are packages that behave maliciously without a CVE yet; catching those requires a behavioural scanner like [Socket](/socket), not a CVE matcher. --- ## Why is SCA so noisy? {#the-noise-problem} The biggest complaint about SCA is alert volume. A typical enterprise application might show hundreds of vulnerable dependencies, most of which are transitive (dependencies of dependencies) and many of which are not exploitable in context. Some teams end up disabling SCA alerts entirely because the noise becomes unbearable. That is worse than having no SCA at all, because it creates a false sense of coverage. Three things help. **Reachability analysis.** [Endor Labs](/endor-labs) and [Contrast SCA](/contrast-security#contrast-sca) cut alerts by 70-90% by showing which vulnerabilities are actually reachable from your code. The most effective noise reduction available. **Severity filtering.** Not every CVE is critical. Block merges on critical and high, warn on medium, suppress low. Most tools support this. **Transitive dependency focus.** A vulnerability in a direct dependency you control is more actionable than one buried three levels deep. Some tools let you prioritize accordingly. --- ## Benefits and limits of SCA SCA is a high-leverage control, but it is not a complete one. The honest picture is a short list of each. **Benefits:** - **Visibility into transitive dependencies.** Most real-world vulnerabilities live several levels deep in your dependency graph, beyond what a manual `package.json` review catches. SCA resolves the full tree in seconds. - **Compliance automation.** US Executive Order 14028, the EU Cyber Resilience Act, and PCI DSS 4.0 all lean on machine-readable component inventories. SCA tools that emit CycloneDX or SPDX cover the paperwork. - **Continuous CVE monitoring.** When a new critical CVE drops, you want to know which of your applications is affected within minutes, not weeks. SCA backed by a persistent SBOM store ([Dependency-Track](https://github.com/DependencyTrack/dependency-track), Anchore Enterprise) answers that instantly. - **Lowest-cost supply-chain hygiene.** Free tiers of Snyk, Dependabot, and Trivy + Grype cover the core capability at zero licence cost. **Limits:** - **Noise and false positives.** Flat CVE lists without reachability make alert fatigue inevitable. [Endor Labs](/endor-labs), [Contrast SCA](/contrast-security#contrast-sca), and [Qwiet AI](/qwiet-ai) cut that by 70-90% with reachability; most open-source scanners do not. - **Custom-compiled and vendored libraries.** If your team forks a library and vendors it into your repo, SCA has nothing to match against. Binary composition analysis (Black Duck, FOSSA) is the only reliable answer. - **Licence vs malicious-package overlap.** SCA is strong on known CVEs and licence strings. It is weak on typosquats and compromised-maintainer releases, which is why teams pair SCA with behavioural scanners like [Socket](/socket). - **Dependent on database freshness.** An SCA tool is only as good as the feeds it consumes. NVD publication lag, GHSA review queues, and ecosystem-specific advisory gaps all land in your scan results. --- ## Supply chain attacks {#supply-chain-attacks} Traditional SCA checks dependencies against databases of known vulnerabilities. That works for CVEs that have already been reported. Supply chain attacks are a different problem. An attacker compromises a legitimate package or publishes a malicious one that looks legitimate. There is no CVE because nobody has reported it yet. Traditional SCA misses these entirely. The numbers are ugly. The [Sonatype 2024 State of the Software Supply Chain](https://www.sonatype.com/state-of-the-software-supply-chain/introduction) report found a 156% year-over-year increase in malicious packages, with over 704,102 malicious packages identified since 2019 across npm, PyPI, and other ecosystems. [Socket](/socket) takes a different approach to this problem. Instead of matching against CVE databases, it analyzes what packages actually do: network calls, filesystem access, obfuscated code, install scripts. If a package that is supposed to be a string formatting library suddenly starts making HTTP requests to an unknown server, Socket flags it. [Checkmarx SCA](/checkmarx#sca-and-supply-chain) has a similar behavioral analysis feature that evaluates package provider credibility, update cadence, and runtime behavior. For teams worried about supply chain risk, the combination of traditional SCA (for known CVEs) and behavioral analysis (for unknown threats) provides the broadest coverage. --- ## SBOMs and compliance {#sboms-and-compliance} A Software Bill of Materials is an inventory of every component in your software. If you sell a food product, you list the ingredients. An SBOM does the same for software. The push for SBOMs accelerated after the US Executive Order on Cybersecurity in 2021, which requires SBOMs for software sold to federal agencies. The EU Cyber Resilience Act has similar requirements coming. SBOMs are useful beyond compliance. When Log4Shell ([CVE-2021-44228](https://www.cve.org/CVERecord?id=CVE-2021-44228)) was disclosed in December 2021, organizations with SBOMs could immediately check whether they were affected. Everyone else spent days or weeks manually inventorying their dependencies. Standard formats: - **CycloneDX** — OWASP-maintained, lightweight, widely supported. - **SPDX** — Linux Foundation-maintained, ISO standard, more detailed. Most SCA tools generate SBOMs in both formats. [Black Duck](/blackduck), [Snyk](/snyk#snyk-open-source-sca), and [Endor Labs](/endor-labs) all include SBOM generation. --- ## SCA vs SAST {#sca-vs-sast} SCA and [SAST](/sast-tools) are often confused because both run before deployment. They look at completely different things. | | SCA | SAST | | --------------------- | -------------------------------------- | ---------------------------------- | | **What it scans** | Third-party libraries and dependencies | Your own source code | | **What it looks for** | Known CVEs, license violations | Code-level flaws (SQLi, XSS, etc.) | | **Input needed** | Manifest files or compiled binaries | Source code or bytecode | | **Speed** | Seconds | Minutes to hours | | **False positives** | Low (matched against known CVEs) | Higher (depends on analysis depth) | You want both. SCA checks what you imported. SAST checks what you wrote. Together they cover the full picture of what goes into production. For a deeper look at how these two approaches differ, see the [SAST vs SCA comparison](/application-security/sast-vs-sca). For a broader comparison that includes DAST and IAST, see the [SAST vs DAST vs IAST guide](/application-security/sast-vs-dast-vs-iast). --- **Looking for tools?** See our complete [SCA tools comparison](/sca-tools) with 30+ tools rated and reviewed. --- ## Top SCA tools to know SCA is not a one-tool category. A short landing list covers the options most teams actually evaluate — three commercial, three open-source — with one sentence on positioning. The deeper comparisons live on the [full SCA tools hub](/sca-tools). **Commercial:** - [Snyk Open Source](/snyk#snyk-open-source-sca) — developer-first SCA with automated fix pull requests and a Free plan that scans unlimited public repositories. - [Black Duck](/blackduck) — enterprise SCA with deep licence-compliance tooling and binary composition analysis for compiled artefacts. - [FOSSA](/fossa) — licence-compliance-first SCA with 99.8% licence detection accuracy and a centralised SBOM Portal for distribution. **Open-source:** - [Trivy](/trivy) — all-in-one scanner that covers container images, filesystems, and IaC in a single binary ([32K+ GitHub stars](https://github.com/aquasecurity/trivy)). - [Grype](/grype) — SBOM-first vulnerability scanner from Anchore with composite CVSS + EPSS + KEV risk scoring. - [OSV-Scanner](/osv-scanner) — Google's scanner backed by the aggregated OSV.dev database, with guided remediation for npm and Maven. For a side-by-side matrix of 30+ tools with pricing context, see the [SCA tools comparison](/sca-tools). For the free-only shortlist, the [open-source SCA tools](/sca-tools/open-source-sca-tools) guide drills into the twelve most-used options. --- ## Getting started {#getting-started} SCA is probably the easiest security tool category to adopt. Here is a practical path. Start with a free tool. [Snyk Open Source](/snyk#snyk-open-source-sca) has the smoothest onboarding. Run `snyk test` in your project directory and you have results in seconds. [OWASP Dependency-Check](/owasp-dependency-check) is the fully free alternative. Review the initial findings. Your first scan will probably show dozens of vulnerable dependencies. Do not panic. Sort by severity, focus on critical and high first, check whether the affected library is actually used in a way that exposes the vulnerability. Update what you can. Many findings are fixed by bumping a dependency version. [Snyk](/snyk#snyk-open-source-sca) and [Mend](/mend#mend-sca) can open auto-remediation PRs. Review the updates before merging since version bumps can introduce breaking changes. Add it to CI. Run the tool on every pull request. Block merges on critical vulnerabilities. Warn on high and medium. Set up license policies. Define which licenses your organization allows. Block any dependency with a copyleft license if you ship commercial software. Consider SBOM generation. Add it to your release pipeline. Costs nothing and gives you an inventory you can query when the next Log4Shell drops. --- ## FAQ {#faq} ### Is SCA the same as SBOM? No. SCA is the scanning activity — resolve dependencies, match against CVE databases, report findings. An [SBOM](/sca-tools/what-is-sbom) is an artefact — a structured inventory of every component in your software, typically in CycloneDX or SPDX format. Most SCA tools can produce SBOMs, and many consume them for continuous monitoring, but the two are not interchangeable terms. ### Does SCA replace SAST? No. [SAST](/sast-tools) scans your own source code for code-level flaws like SQL injection and insecure deserialisation. SCA scans the third-party libraries you imported for known CVEs and licence conflicts. Most teams need both — SCA is usually the faster first win because it does not require code-path analysis. ### Why do SCA tools disagree on vulnerability counts? Two scanners running against the same code can disagree by 30-40% of findings. The differences come from the vulnerability database each tool consumes (NVD vs GHSA vs OSV vs distro feeds), the matching method (CPE-based vs ecosystem-specific), and whether reachability or VEX annotations filter the raw count. Neither output is "wrong" — they answer slightly different questions. ### Is Dependabot a full SCA tool? Partially. [Dependabot](/dependabot) reads the GitHub Advisory Database, reports vulnerable dependencies in your GitHub repositories, and opens automated fix PRs. It covers the core SCA job for GitHub-hosted projects at zero cost. It does not cover reachability analysis, custom-compiled libraries, or licence-compliance policy — teams that need those typically layer Snyk, Black Duck, or FOSSA on top. ### Does SCA find malicious packages? Most SCA tools do not. Traditional SCA matches against databases of already-reported CVEs; typosquats and compromised-maintainer releases usually have no CVE when they are published. Tools that combine SCA with behavioural analysis ([Socket](/socket), [Checkmarx SCA](/checkmarx#sca-and-supply-chain)) or that consume the [OpenSSF Malicious Packages](https://github.com/ossf/malicious-packages) feed ([OSV-Scanner](/osv-scanner) via OSV.dev) close that gap. ---