Continuous Penetration Testing Methodology (CPTM) is a comprehensive, iterative approach to security testing that operates year-round to protect against evolving cyber threats. Unlike traditional one-off annual penetration tests which provide a "snapshot" of security at a single point in time, CPTM enables real-time visibility into vulnerabilities and continuous risk reduction. This guide presents a structured CPTM framework comparable in depth to industry standards like NIST SP 800-115, the MITRE ATT&CK framework, the Penetration Testing Execution Standard (PTES), and Gartner's Continuous Threat Exposure Management (CTEM), while exceeding their requirements through continuous coverage and integration.

This document is organized to serve both technical teams and executive stakeholders. It begins with an overview of CPTM and its benefits to the organization. Then, it details each phase of the methodology – from upfront planning through continuous reconnaissance, vulnerability discovery, exploitation, and ongoing reporting – with clear objectives and procedures. A tool-agnostic approach is emphasized with suggestions of best-of-breed tools in each category (reconnaissance, scanning, exploitation, etc.) to illustrate how CPTM can be implemented using current technologies without tying the process to any single product or vendor. We also provide a mapping section aligning CPTM to established frameworks (NIST 800-115, MITRE ATT&CK, PTES, and Gartner CTEM), showing how CPTM covers all their elements and extends beyond them in scope and frequency. Finally, a justification section highlights how CPTM surpasses traditional annual penetration testing: closing the window of exploitability between infrequent tests, keeping pace with rapid infrastructure changes, and fostering a proactive security culture suitable for all industries – from highly regulated sectors that demand constant assurance, to tech-driven organizations with continuous deployment pipelines.

Key Takeaways for Stakeholders: Continuous penetration testing offers real-time insights and agile risk management that static annual tests cannot. It aligns with compliance requirements while greatly enhancing security posture through frequent assessments and fast remediation. CPTM is an investment in resilience - ensuring that as an organization's systems and threats evolve, the defenses and testing practices evolve in step, providing stakeholders confidence that security is being rigorously and continuously validated.

In today's threat landscape, where new vulnerabilities and attack techniques emerge daily, security assessments can no longer be treated as a one-and-done annual exercise. Traditional penetration tests, conducted once or twice a year, yield valuable insight but leave long gaps during which untested changes and weaknesses can accumulate and system deployment or code update between test windows might introduce critical vulnerabilities that remain undiscovered for months – creating a "window of exploitability" (WoE) that attackers can readily exploit. For example, an organization that pen-tests only every June and December would leave any vulnerabilities introduced in July untested until the next cycle, potentially giving adversaries a five-month head start. This approach is increasingly inadequate for fast-paced IT environments or industries with high security requirements.

Continuous Penetration Testing has emerged as a strategic response to these limitations. By moving from point-in-time tests to ongoing, iterative assessments, CPTM ensures that security testing keeps up with the speed of infrastructure change. The methodology involves frequent (often daily, weekly, or on-demand) cycles of scanning, probing, and validating defenses so that vulnerabilities are caught and remediated as soon as they surface. This shift enables organizations to maintain a robust security posture even as they rapidly innovate or scale their systems. It also aligns with modern development practices like Agile and DevOps by embedding security testing into the continuous delivery pipeline.

CPTM is not a single tool or product but a comprehensive framework that combines automation and human expertise in a repeatable process. Automated scanners and monitors run around the clock to flag common issues and changes, while skilled penetration testers regularly perform deep-dive analysis and attempted exploits to uncover complex weaknesses. This blend ensures both breadth and depth: automation provides real-time coverage of the full attack surface, and human-led testing brings creativity and adversarial thinking that automated tools alone cannot achieve. The result is a "best of both worlds" approach – continuous coverage with expert validation.

This guide lays out a complete Continuous Penetration Testing Methodology, including phases, processes, and objectives, in a structured format. It is designed to be tool-agnostic, meaning the focus is on what needs to be done and how to approach it, rather than prescribing specific tools. However, for each phase we suggest widely-used tools and techniques that teams might employ, categorized by their purpose. These illustrate how CPTM can be practically implemented using best-of-breed solutions available today, from open-source utilities to enterprise platforms, without endorsing any single vendor.

Throughout the guide, references are made to well-established standards and frameworks to demonstrate alignment. CPTM draws upon the guidance of NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment) for overall structure and rigor in planning, execution, and reporting. It leverages the MITRE ATT&CK framework to inform threat modeling and ensure comprehensive coverage of adversary tactics and techniques. It also encompasses all phases of the PTES (Penetration Testing Execution Standard), from pre-engagement to reporting, embedding them into a continuous lifecycle. Additionally, CPTM maps formally to Gartner's Continuous Threat Exposure Management (CTEM) framework, aligning its five stages to CPTM phases for enterprise-grade exposure management. By adhering to these respected frameworks, CPTM ensures completeness and reliability; by extending them into a continuous model, it achieves a higher level of security assurance than traditional methods.

In summary, as cyber threats grow more sophisticated and business operations demand more agility, CPTM provides a proactive, ongoing approach to penetration testing. The following sections detail each phase of this methodology, outline recommended practices and tools, and illustrate how continuous testing delivers superior outcomes in risk reduction and compliance for organizations across all industries.

CPTM is organized into phases that mirror those of a traditional penetration test but executed in a continuous, iterative fashion. The phases are structured to ensure a logical flow: plan the testing engagement, discover assets and vulnerabilities, attack and exploit to validate findings, and report results for remediation. These phases repeat on an ongoing basis, for example, daily or weekly or with every significant change – rather than occurring just once a year. Each phase below includes detailed processes, procedures, and objectives tailored to a continuous cycle.

Objective: Establish the rules, scope, and frequency of testing, and create a foundation for ongoing collaboration between the testing team and the organization. In a continuous model, planning is not a one-time task but an ongoing activity that adjusts as the organization's environment and requirements evolve.

Process & Procedures: In the initial planning stage (often called pre-engagement), the team conducts a thorough scoping and coordination, very similar to a traditional pen test kickoff but with an eye toward long-term operations. Key planning steps include:

• Define Scope and Assets: Identify the systems, applications, networks, cloud tenants and facilities that are in-scope for continuous testing. This should cover the entire attack surface (external and internal) that the organization wishes to protect. Given the dynamic nature, there should be a mechanism to update the scope continuously as new assets come online or old ones are decommissioned. For example, new internal assets, cloud assets or a new web application should automatically be added to the testing scope once deployed. The planning team should work with asset owners to maintain an updated asset inventory for testing. Scope should explicitly include AI/LLM-integrated services, third-party dependencies, and supply chain components as first-class assets, not afterthoughts.

• Set Engagement Rules (Rules of Engagement): Establish clear rules to ensure testing is safe and compliant. This includes defining testing hours or blackout periods (to avoid critical production times), agreeing on whether certain techniques (like Denial of Service or social engineering) are allowed or not, and specifying any sensitive systems to exclude. Because testing is continuous, these rules should also cover how to handle urgent situations – e.g. if a critical issue is found at 2 AM, who should be notified? And how to minimize disruption during business hours. The rules of engagement should also outline how far testers can go in exploiting a vulnerability (for instance, whether they are permitted to exfiltrate data in a controlled manner to demonstrate impact, or to stop at proof-of-concept).

• Legal and Compliance Alignment: Put in place legal agreements such as NDAs and get formal authorization for continuous testing. Many industries require that all tests are authorized to avoid legal ramifications. For continuous testing, an umbrella agreement might be established to cover ongoing activities, with periodic reviews. It's also crucial to consider compliance standards, for example, making sure the continuous testing program helps fulfill requirements like PCI DSS 11.3 (which mandates penetration testing) or other regulatory needs. NIST SP 800-115 emphasizes addressing legal considerations and obtaining proper approvals as part of the planning phase.

• Communication Plan: Develop a communication strategy between the penetration testing team (which might be an internal red team or an external service/contractor) with the organization's stakeholders. In CPTM, communication is often persistent and in real-time, rather than limited to kickoff and report delivery. This can include setting up dedicated ChatOps channels (such as a Slack or Microsoft Teams) to discuss findings as they emerge, weekly or monthly check-in meetings, and protocols for escalating critical vulnerabilities immediately. Continuous engagement means the testers effectively become long-term partners with the defender teams (sometimes termed an "Offensive SOC" team working alongside the defensive SOC), so open communication and trust are essential.

• Resource and Schedule Planning: Plan the allocation of resources and the cadence of testing activities. Determine which portions of the process will be automated (running continually or on a frequent schedule) and when human testers will perform manual deep-dive testing. For example, automated discovery and vulnerability scans might run daily, while manual penetration test sprints might occur one week out of every month focusing on different areas each time or as new assets and vulnerabilities are discovered in real-time. Ensure that the individual(s) performing the testing have the necessary skills and capacity for the continuous engagement. Because CPTM is ongoing, the plan should include how to rotate or rest testers to avoid fatigue, and how to handle knowledge transfer if team members change over time.

• Implementation & Baseline: At the very start of CPTM, it's common to perform a baselining (initial discovery, recon and vulnerability identification) to gauge the current security posture. This baseline follows the typical full engagement (recon, exploit, etc.) and produces an initial set of findings and a risk profile. The continuous program will then aim to maintain and improve upon this baseline, ensuring new issues are addressed and risk is continuously driven down from that starting point.

Continuous Aspect: Unlike a one-time test, planning in CPTM is revisited regularly. The scope document is a living document that might be reviewed quarterly to include new business units or technologies. Rules of engagement may be adjusted based on lessons learned (e.g., if certain automated scans caused performance issues). The communication plan will also adapt, for instance, adding new stakeholders or integrating with incident response workflows as needed. Essentially, Phase 1 never truly ends during CPTM; it feeds into all other phases by ensuring everyone remains aligned on objectives and process as changes occur. This aligns with NIST 800-115's emphasis that proper planning and coordination precede execution and that deviations during execution should prompt review.

Objective: Continuously identify and enumerate all potential attack vectors in the organization's environment. This phase aims to maintain an up-to-date understanding of the attack surface through both passive intelligence gathering and active scanning. In a continuous program, reconnaissance is not a one-off preliminary step, but an always-on discovery process that catches changes in real time (e.g. new servers, domains, user accounts, or software deployments).

Process & Procedures:

• External Attack Surface Monitoring: Leverage automated discovery tools to map the organization's external footprint on an ongoing basis. External Attack Surface Management (EASM) solutions can continuously scan the internet for assets related to the organization (by domain names, IP ranges, company names, etc.) to find any unknown or unmanaged assets. This includes discovering new subdomains, cloud instances, APIs, or third-party services that appear over time. By monitoring DNS registrations, SSL certificates, cloud metadata, and IP space, the testing team can quickly spot when a development team launches a new website or if an engineer exposes a new port to the internet. Continuous recon also involves watching for leaked information, for example, checking if any company credentials or data appear on dark web sites or pastebins (indicative of a breach or risky behavior).

• Internal Asset Discovery: Scope discovery includes internal networks, running scheduled network scans (authenticated, agent based, or unauthenticated) to identify new hosts, devices, or changes in network topology. For instance, a weekly scan of IP ranges can reveal newly added servers or networking equipment. Incorporate detection of new open ports or services on existing hosts as well (since configuration changes could open new services). In environments using cloud or virtualization, integrate with infrastructure APIs to list instances or containers as they are created. Automated asset discovery tools can be configured to send alerts whenever a new host joins the domain or a significant change (like a critical service enabled on a server) is detected.

• OSINT and Threat Intelligence Gathering: Continuously gather Open-Source Intelligence related to the organization and its industry. This includes monitoring for news about relevant vulnerabilities (e.g., if a new exploit is published that might affect software the company uses, that information is fed into the testing process) and keeping track of attacker forums or threat intel feeds for any indications the company is being targeted. The testers should also monitor breach databases and credential dumps for any user accounts from the organization, which could be leveraged in password spraying or credential stuffing tests. Essentially, the reconnaissance phase blends into threat intelligence – mapping not just the IT assets but the threat landscape around the organization.

• Supply Chain & Dependency Discovery: Reconnaissance must extend beyond first-party assets to include the organization's software supply chain. This means continuously enumerating third-party libraries, open-source dependencies, SaaS integrations, and CI/CD pipeline components. Tools like Syft can generate a Software Bill of Materials (SBOM) from container images and repositories, while Grype can continuously scan those SBOMs against known vulnerability databases. Any newly introduced dependency — whether pulled in by a developer or silently updated by a package manager — should automatically surface in the asset inventory for further assessment. The goal is to eliminate blind spots in the supply chain before they become breach vectors, as demonstrated by incidents like Log4Shell and SolarWinds-style compromise patterns.

• AI/LLM and Agentic Endpoint Discovery: As organizations integrate large language models and AI APIs into their products and internal tooling, these endpoints must be explicitly enumerated as part of continuous reconnaissance. This includes identifying exposed model inference APIs, retrieval-augmented generation (RAG) pipeline components, vector databases, and LLM-backed chatbots or agents. Any AI service that accepts external input — whether via a public interface or an internal integration — represents a new attack surface that must be tracked and tested continuously. Particular attention should be paid to agentic AI deployments built on protocols such as Model Context Protocol (MCP), where LLM agents are granted tool-calling capabilities to interact with external systems. Each MCP server, tool integration, and OAuth-delegated capability connected to an AI agent must be enumerated as part of the attack surface, as these represent novel lateral movement and data exfiltration paths. MITRE ATLAS provides a useful taxonomy for mapping AI-specific attack vectors discovered during this phase.

• Non-Human Identity (NHI) Discovery: Modern environments contain vastly more machine identities than human ones — service accounts, API keys, OAuth tokens, CI/CD pipeline credentials, cloud IAM roles, and third-party integration secrets. Continuous reconnaissance must enumerate NHIs across the environment, identifying dormant service accounts, over-permissioned API tokens, long-lived credentials that should be rotated, and OAuth grants with excessive scope. Tools like TruffleHog and Gitleaks cover secrets in code repositories; cloud provider IAM consoles and tools like CloudTrail analysis and Entra ID auditing surface machine identity sprawl in cloud environments. NHI discovery feeds directly into privilege escalation and lateral movement testing in later phases, as compromised service accounts frequently provide silent, high-impact access that bypasses human authentication controls entirely.

• Vulnerability Intelligence (Continuous Scanning for Known Vulns): While detailed vulnerability scanning is covered in the next phase, reconnaissance overlaps by identifying obvious exposures. For example, running lightweight port scans (using tools like Nmap) continuously can reveal if a server suddenly starts exposing a database port or if a new web service comes online. Using this information, the team can prioritize further analysis on those changes. The recon phase might also include periodic banner grabbing or service fingerprinting to detect what software versions are running, feeding into a vulnerability knowledge base. If a new critical CVE (Common Vulnerability/Exposure) is announced that affects a version of software the company runs, the recon process should flag all hosts running that version immediately.

• Covert Reconnaissance: Similar to PTES's intelligence gathering and covert gathering phases, CPTM may include covert recon activities like social media profiling, where testers continuously watch for information employees or contractors inadvertently share (on LinkedIn, Twitter, etc.) that could aid an attack (e.g., mentioning technologies in use, or posting a screenshot of an internal tool). They might also periodically test physical security reconnaissance (like checking what information is available at public locations, or whether employee badges are being sold online, etc., if that's in scope). All these efforts happen regularly rather than just at the start of an engagement.

Continuous Aspect: In continuous pen testing, reconnaissance is essentially on-going monitoring. Automation is key and required: tools running 24/7 can immediately detect changes and feed them to the testing team. For example, one can set up notifications such that as soon as a developer exposes a new web port, the team is alerted and can begin assessment. This continuous recon closes the gap described earlier – no asset should remain "unknown" or "untested" for long after it appears. By contrast, in a traditional test, anything not in scope during the initial planning or launched afterward would be missed until the next test. CPTM's recon phase ensures the scope of testing remains current and comprehensive.

Another continuous element is integrating this phase with configuration management and DevOps pipelines. For instance, as soon as a new code release is deployed, automated scripts trigger scans or information gathering on the updated components. Over time, the testers build a rich inventory of organization assets and how they interconnect, which is constantly updated. This aligns with NIST 800-115's Discovery phase, but instead of a one-time discovery, CPTM performs discovery repeatedly and in real time, providing "real-time visibility" into the environment.

Objective: Analyze the information gathered from reconnaissance to identify likely threat scenarios and prioritize targets. In this phase, testers translate raw data (assets, vulnerabilities, and system information) into a coherent model of potential attacks. They consider the organization's critical assets, the potential attackers (threat actors) and their tactics, and decide where to focus testing efforts continuously for maximum impact. The goal is to ensure that testing mimics real-world threats as closely as possible, covering not just random vulnerabilities but the paths an actual attacker would take.

Process & Procedures:

• Business and Asset Prioritization: Continuous testing must align with what matters most to the organization. The threat modeling process involves identifying the "crown jewels" (e.g. critical databases, sensitive data, mission-critical APIs) and mapping how an attacker might reach them. Testers should maintain an updated understanding of business processes and data flows: e.g., knowing that a certain server houses customer financial data or a certain application handles healthcare records. This context allows the team to prioritize testing on systems whose compromise would be most damaging. Essentially, this is a continuous asset value assessment: as new systems come online or business priorities shift, the threat model is updated to reflect what needs the most protection.

• Adversary Modeling (Attacker Profiles): Define and periodically revisit the profiles of potential adversaries relevant to the organization. For example, one profile might be a financially motivated external hacker trying to breach the perimeter, another might be an insider threat with credentials, or an advanced persistent threat (APT) group targeting the industry. For each profile, consider their likely Tactics, Techniques, and Procedures (TTPs). Here, the MITRE ATT&CK framework is invaluable: it provides a comprehensive matrix of tactics (goals like Initial Access, Privilege Escalation, Lateral Movement, etc.) and techniques (specific methods used) observed in real attacks. The CPTM team can map which ATT&CK techniques are relevant to the environment and ensure that the continuous testing covers as many of those as possible. For instance, if MITRE ATT&CK lists "phishing" and "valid accounts" as common initial access techniques, the testers will incorporate recurring phishing simulations and testing of password policies. Using ATT&CK as a guide offers pivotal insights into adversarial tactics, ensuring the testing methodology doesn't miss techniques that attackers are known to use. The threat model is thus enriched with known attacker behaviors.

• AI/LLM Threat Scenarios: As AI systems become embedded in organizational workflows, threat modeling must explicitly account for AI-specific attack patterns. Using the MITRE ATLAS framework as a reference, testers should model scenarios including prompt injection (both direct and indirect via RAG pipelines), model inversion attacks, data poisoning in training or fine-tuning pipelines, insecure model API configurations, and excessive agency granted to LLM-backed agents. For agentic AI deployments using protocols like MCP, threat modeling must account for tool-call injection (where malicious content in external data sources triggers unintended tool execution), OAuth token theft via malicious MCP servers, and privilege escalation through over-permissioned agent capabilities. The OWASP Top 10 for LLM Applications provides a structured taxonomy for this threat class and should be incorporated into the threat model wherever AI services are in scope. Each LLM-integrated component identified in Phase 2 should have at least one adversary scenario mapped to it before entering Phase 4.

• GenAI-Accelerated Adversary Modeling: Threat modeling must account for the reality that attackers now leverage generative AI to accelerate and scale their operations. AI-assisted reconnaissance can enumerate targets and identify vulnerabilities faster than traditional methods. AI-generated phishing content achieves higher click rates through personalization at scale. Automated exploit generation tools lower the bar for weaponizing newly disclosed CVEs. And AI-powered lateral movement tools can adapt in real time to network defenses. The implication for CPTM is that the assumed attacker pace and sophistication must be recalibrated upward — threat models should explicitly include AI-augmented adversary profiles, and testing cadence should account for the reduced time between vulnerability disclosure and active exploitation that AI tooling enables.

• Supply Chain Threat Scenarios: The threat model must account for adversaries who compromise organizations not through direct attack but through trusted third parties and dependencies. Model scenarios such as dependency confusion attacks (substituting a malicious package for an internal one), compromised CI/CD pipeline steps (e.g., a malicious GitHub Action or poisoned build container), and typosquatted packages introduced into the dependency tree. For each critical third-party integration, the team should map the blast radius of a supply chain compromise — what systems would be affected, what data could be exposed, and how quickly the organization would detect it. SLSA (Supply Chain Levels for Software Artifacts) and the CISA Secure Software Development Framework provide useful reference structures for threat modeling supply chain risk.

• Attack Path Analysis: Using the information from recon and vulnerability data (from Phase 2 and Phase 4), chart out potential attack paths. An attack path is a sequence of steps an attacker could take to go from an entry point (say, a compromised low-privilege account or an exposed system) to a high-value target. For example: an exposed development web server might allow an attacker to get a foothold, then a weak password could let them pivot into the corporate network, then missing patches on an internal database server could lead to data exfiltration. The testers document these hypothetical paths and then plan to test them in practice during the exploitation phase. In continuous testing, attack path analysis is updated frequently (daily or weekly) as new vulnerabilities are found or as defenses improve (some paths may be closed after fixes, but new ones might appear). By visualizing and prioritizing attack paths, the team can focus on the most realistic and dangerous scenarios first.

• Risk Rating and Prioritization: Continuous testing can generate a lot of data, so threat modeling helps to prioritize what to tackle immediately vs later. Each identified threat/vulnerability combo can be assigned a risk rating (considering likelihood and impact). The CISA Known Exploited Vulnerabilities (KEV) Catalog and the Exploit Prediction Scoring System (EPSS) are essential inputs here: KEV identifies vulnerabilities with confirmed active exploitation in the wild, while EPSS provides a probability score for exploitation within 30 days. Both should be cross-referenced against the organization's asset inventory in real time so that any KEV-listed vulnerability affecting in-scope systems is immediately escalated to the top of the testing queue. This risk-based approach ensures the continuous testing efforts are always directed at reducing the highest risks first, which is critical given the ongoing nature. Many organizations tie this process into their risk management framework, so CPTM findings feed into the overall enterprise risk register continuously.

• Test Plan Formulation: Based on the threat model, the team formulates a testing plan (which is continually refreshed). This includes deciding which tools and techniques to use for which scenario, setting up necessary infrastructure for the test (e.g., phishing email servers for a planned phishing campaign, or creating malware dropper for an exfiltration test), and timing (if certain tests should coincide with particular events or be unannounced for realism). The plan should remain flexible – new intel or a new vulnerability discovery can alter it. Essentially, before moving to Phase 4 and 5 (vulnerability scanning and exploitation), the testers have a game plan influenced by real-world threat considerations. This aligns with PTES's Threat Modeling phase, where testers perform business asset analysis and threat agent analysis, but CPTM does it repeatedly as new information comes in.

Continuous Aspect: Threat modeling in CPTM is not conducted once; it's a living model that is continually refined. Each cycle of testing yields new information (e.g., "we found that X system was more vulnerable than expected" or "the blue team detected our last attempt in 2 hours – how would a real attacker adapt?"). The threat model is adjusted accordingly. Regular threat modeling sessions (perhaps monthly or quarterly) can be held where the pen testers and relevant security staff review emerging threats (like new attack campaigns in the wild) and internal changes (like adoption of a new technology such as container orchestration, which might introduce new attack vectors) and then incorporate those into upcoming tests.

By continuously engaging in threat modeling, CPTM ensures it stays one step ahead of attackers: as attackers change tactics, the methodology shifts to test those tactics. This is a step beyond many traditional frameworks – for example, NIST 800-115 provides a solid foundation for identifying and analyzing targets, but CPTM expands this by continuously integrating behavior frameworks (like ATT&CK and ATLAS) into the testing cycle, thereby exceeding standard requirements by making the testing as dynamic as the threat environment itself.

Objective: Identify vulnerabilities in systems, applications, networks, AI/LLM services, APIs, and supply chain components on an ongoing basis, using a combination of automated scanning and manual techniques. This phase aims to ensure that newly introduced weaknesses are rapidly discovered and that previously identified issues are tracked and re-validated. Essentially, this is the "find all the holes" phase, repeated continuously.

Process & Procedures:

• Automated Vulnerability Scanning (Scheduled/On-Demand): Deploy vulnerability scanners to run at regular intervals across the in-scope assets. These can include network vulnerability scanners (such as Nessus, OpenVAS, Qualys, or others) to detect missing patches, misconfigurations, and known CVEs on servers and network devices. For web applications, use Dynamic Application Security Testing (DAST) tools like OWASP ZAP or Burp Suite's scanner to continuously crawl and test web endpoints for common web vulnerabilities (SQL injection, XSS, etc.). Ideally, integrate these scans with the development pipeline: for example, every time a new version of an application is deployed, an automated DAST scan runs against the staging or production environment. Scans can be targeted (focusing on specific new components) or broad (full network scans monthly, for instance). The continuous aspect means scanning is not a one-time event; some scans might run daily (for critical externally facing assets), while more exhaustive scans run weekly or monthly depending on criticality and practicality. Any high severity findings from automated scans should trigger alerts to the team immediately.

• KEV and EPSS-Driven Prioritization: Vulnerability assessment should be continuously informed by the CISA Known Exploited Vulnerabilities (KEV) Catalog and the Exploit Prediction Scoring System (EPSS). Any CVE appearing in the KEV catalog that affects in-scope assets should be treated as an immediate priority, triggering an expedited scan and validation cycle regardless of where it falls in the normal testing schedule. EPSS scores should be factored into routine triage: a vulnerability with a high EPSS score but moderate CVSS rating may warrant faster attention than a critical CVSS finding with low exploitation probability. Integrating these feeds into the vulnerability management platform ensures the team is always focused on what is most likely to be exploited, not just what scores highest on paper.

• API Security Assessment: APIs represent a growing and frequently under-tested attack surface. Continuous vulnerability assessment must include dedicated API security testing covering REST, GraphQL, and gRPC interfaces. Testers should assess for the OWASP API Security Top 10, including Broken Object Level Authorization (BOLA), Broken Authentication, Excessive Data Exposure, and lack of rate limiting. Automated API discovery tools can enumerate undocumented or shadow APIs that may not appear in formal documentation. Each API endpoint identified in Phase 2 should be continuously tested for authorization bypass, parameter tampering, and injection vulnerabilities. API changes introduced through CI/CD pipelines should trigger targeted re-assessment of affected endpoints.

• AI/LLM and Agentic System Vulnerability Assessment: AI-integrated components identified in Phase 2 and scoped in Phase 3 must undergo dedicated vulnerability assessment. This includes testing for prompt injection (both direct user input and indirect injection via external data sources consumed by RAG pipelines), insecure output handling (where model responses are rendered without sanitization), training data leakage, model denial-of-service via resource-exhaustive prompts, and excessive permissions granted to LLM agents. For agentic systems built on MCP or similar tool-calling frameworks, assessment must include testing for tool-call injection via malicious data sources, verification that agent OAuth scopes are appropriately restricted, and confirmation that MCP server implementations validate and sanitize tool inputs. Tools such as Garak (LLM vulnerability scanner), PyRIT (Python Risk Identification Toolkit for AI), and Promptmap can be used to automate portions of this assessment. Manual testing remains essential for logic-based abuse scenarios that automated tools cannot fully simulate. The OWASP Top 10 for LLM Applications should serve as the primary checklist for this sub-phase.

• Non-Human Identity (NHI) Assessment: The attack surface of modern environments is dominated by machine identities — service accounts, API keys, OAuth tokens, CI/CD secrets, cloud IAM roles, and third-party integration credentials. Continuous vulnerability assessment must include dedicated NHI assessment covering: dormant or orphaned service accounts with lingering permissions, API keys and tokens with excessive scopes that have not been rotated within policy windows, CI/CD pipeline secrets accessible to unauthorized pipeline stages, cloud IAM roles with overly broad trust policies, and OAuth applications granted persistent access to sensitive resources. NHI assessment should be triggered automatically whenever a service account is created, an API key is issued, or an OAuth grant is approved. The output feeds directly into privilege escalation scenarios in Phase 5, as compromised machine identities frequently provide silent, persistent, high-impact access paths that bypass human authentication controls entirely.

• Supply Chain & Dependency Vulnerability Assessment: Continuously scan the organization's software supply chain for known vulnerabilities in third-party libraries, container base images, and CI/CD pipeline dependencies. Tools like Grype, Trivy, and OWASP Dependency-Check should be integrated into CI/CD pipelines to flag vulnerable dependencies at build time. Beyond known CVEs, assess for configuration weaknesses in the supply chain itself: overly permissive pipeline permissions, unprotected secrets in build environments, unsigned artifacts, and third-party integrations with excessive OAuth scopes. StepSecurity's Harden-Runner can be used to monitor and restrict GitHub Actions pipeline behavior. Any newly introduced dependency should be assessed before it reaches production, and existing dependencies should be continuously monitored for newly disclosed vulnerabilities.

• Continuous Configuration Assessment: Beyond scanning for software vulnerabilities, assess configuration security continuously. This includes checking for weak configurations (e.g., default credentials, improper firewall rules, cloud storage buckets left public). Tools or scripts can be used to regularly verify security baselines (for instance, running CIS benchmark scanners on systems periodically). With infrastructure-as-code and cloud, one can automate the checking of cloud configurations (using tools like ScoutSuite or AWS Config rules) to flag things like open S3 buckets or overly permissive IAM roles as they arise. These configuration issues are often as critical as software flaws and should feed into the vulnerability list.

• Cloud-Native Vulnerability Assessment: Cloud environments present attack vectors that traditional network scanners do not adequately cover. Continuous assessment of cloud-native infrastructure should include: IAM privilege escalation path analysis (identifying roles or permissions that could be chained to achieve administrative access), Server-Side Request Forgery (SSRF) testing targeting cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254, which can expose instance credentials), serverless function abuse (testing for event injection, insecure environment variable handling, and over-privileged execution roles), and container escape scenarios in Kubernetes environments. Tools such as Pacu (AWS exploitation framework), Prowler, and kube-hunter are well-suited for continuous cloud-native assessment. Any change to IAM policies, cloud network rules, or serverless function configurations should trigger a targeted re-assessment of the affected components.

• Manual Vulnerability Research: While scanners handle known issues, skilled testers continuously perform manual testing to find unknown vulnerabilities (e.g., business logic flaws in applications, novel attack vectors, or perform attack chaining). This could mean routinely spending time probing a web application beyond what the automated scanner covers — trying edge-case inputs, attempting privilege escalation in the app, or chaining multiple small issues into a larger exploit. Testers also keep an eye out for zero-day issues: for example, if they notice a particular custom application behaves oddly, they might spend extra time researching it for new kinds of flaws. Continuous manual testing might rotate focus: one week focusing on the mobile application, the next on the corporate VPN, etc., ensuring over time that every component is deeply reviewed by human eyes, not just by tools.

• False Positive Analysis and Validation: Continuous scanning produces a stream of findings. The testing team must triage and validate these results. For each vulnerability identified (especially by automated means), they verify if it is a true issue and assess its impact. This often requires manual validation — for example, a scanner flags a SQL injection, the tester will attempt a safe proof-of-concept query to confirm data can actually be extracted. False positives are common, so continuous testing teams maintain a knowledge base of known false positives or benign findings to tune out over time. This improves efficiency: as the program matures, it becomes better at separating signal from noise.

• Vulnerability Tracking: All identified vulnerabilities are logged in a tracking system (could be a dedicated penetration testing platform or a simple issue tracker) with details, severity, and status. Crucially, continuous testing means you will retest vulnerabilities after remediation, so tracking is vital to know what's been fixed and what remains open. The testers coordinate with the organization's IT/development teams to get updates on remediation progress so they can validate fixes promptly. If a vulnerability remains open too long, the continuous program can escalate it or increase focus (e.g., attempt to exploit it further to demonstrate risk). Over time, this tracking produces metrics like average time to remediation (MTTR), number of new vulnerabilities found per month, Vulnerability Escape Rate (vulnerabilities that reach production without being caught in earlier pipeline stages), and Coverage Rate (percentage of in-scope assets assessed within a given period). Many PTaaS platforms used in continuous engagements provide a dashboard where all current vulns are listed with real-time status, replacing the static spreadsheet or PDF report model.

• Scope Expansion based on Vulnerabilities: Sometimes finding a vulnerability can expand what needs to be tested. For example, discovering an SQL injection in an app might prompt adding the connected database servers into scope for further testing. Or finding that a certain software is vulnerable might lead to scanning all other servers for that software. Thus, vulnerability analysis can loop back to the reconnaissance phase or even planning (to adjust scope agreements if needed). In CPTM, these feedback loops happen fluidly; the methodology encourages adjusting and broadening testing as new info comes to light.

Continuous Aspect: The distinguishing factor in CPTM's vulnerability analysis is the frequency and integration. Vulnerability scanning and analysis is essentially continuous – daily incremental scans or at least significantly more frequent than quarterly. This dramatically reduces the window of exposure since new vulnerabilities (whether from new deployments or newly disclosed CVEs) are caught potentially within days or weeks instead of many months. Additionally, by integrating scanning into CI/CD pipelines, organizations achieve a form of DevSecOps — security testing automatically kicks off with each code push or infrastructure change, making security an ongoing concern rather than a final checkbox.

The continuous approach also forces improvements in handling results: rather than a huge deluge of findings once a year (which can overwhelm developers), issues are trickled in and dealt with continuously, which is more manageable. This supports a culture of continuous improvement. It also helps with continuous compliance: many standards require not just a yearly test, but that you maintain secure configurations throughout. Continuous vulnerability management provides evidence that you are constantly checking and fixing issues, which can exceed compliance minimums and strengthen audit results.

Objective: Actively attempt to exploit identified vulnerabilities and security weaknesses in order to verify their impact and uncover deeper issues that scanners or analysis alone cannot reveal. Exploitation serves to validate which vulnerabilities are truly dangerous by demonstrating what an attacker could do, and it often exposes additional vulnerabilities (for example, an initial exploit may lead to discovering internal systems or credentials that open new attack vectors). In CPTM, exploitation is performed on an ongoing basis, whenever new high-impact vulnerabilities are found, and as part of scheduled "attack runs or exploit hunts" that simulate real-world attacks using the latest threat models. The cadence and triggering of these runs or hunts are critical to CPTM and can be timing or event triggered (e.g. a new host or service becomes available, identified via attack surface management).

Process & Procedures:

• Exploit Development/Execution: For each significant vulnerability or attack path identified in earlier phases, the penetration testers will develop and execute an exploit attempt. This can range from using public exploit code or frameworks to writing custom proof-of-concept code. For example, if a new critical vulnerability is found on a web application (say, an authentication bypass), testers will attempt to use it to gain unauthorized access to the application's data. If a buffer overflow on a server is identified, they might run an exploit (in a controlled manner) to get a shell on that server. Popular tools used include exploitation frameworks like Metasploit (for leveraging a large database of exploits) and custom scripts. The testers take care to perform exploitation in line with the agreed rules of engagement — e.g., avoiding actions that could crash production systems unless explicitly allowed or doing so during a maintenance window.

• AI/LLM and Agentic System Exploitation: AI-integrated systems that have been assessed in Phase 4 must be actively exploited to validate theoretical findings. This includes executing prompt injection attacks to override system instructions, extract confidential data from context windows, or cause the model to perform unintended actions. Indirect prompt injection via external data sources (e.g., injecting instructions into a document that a RAG pipeline will ingest) should be specifically tested, as this attack class is highly effective and often overlooked. For agentic AI systems built on tool-calling frameworks like MCP, testers should attempt tool-call injection — crafting malicious content in external data sources that causes the agent to execute unintended tool calls, exfiltrate data, or escalate its own permissions. Testers should also attempt to abuse OAuth tokens issued to AI agents, testing whether over-scoped delegated permissions can be exploited to access resources beyond the agent's intended scope. All findings should be mapped to the OWASP LLM Top 10 and MITRE ATLAS for consistent reporting and remediation guidance.

• Non-Human Identity (NHI) Exploitation: Validated NHI vulnerabilities from Phase 4 should be actively exploited to demonstrate real business impact. This includes using over-permissioned service account credentials to access resources beyond their intended scope, demonstrating that a long-lived unrotated API key can be used to authenticate as a privileged service, and showing that CI/CD pipeline secrets accessible to untrusted jobs can be exfiltrated and used to impersonate build infrastructure. NHI exploitation often provides the highest-impact lateral movement paths in cloud and DevOps-heavy environments — a single compromised service account with broad IAM permissions can provide access equivalent to a domain admin without triggering traditional credential theft alerts. These scenarios should be explicitly included in purple team exercises to validate whether NHI-based attacks are detectable by the defensive team.

• Supply Chain Attack Simulation: Beyond assessing dependencies for known CVEs, testers should actively simulate supply chain attack scenarios to validate detection and response capabilities. This includes testing whether a dependency confusion attack would succeed against the organization's package management configuration, verifying that CI/CD pipelines reject unsigned or tampered artifacts, and confirming that pipeline secrets are not accessible to untrusted contributors. In environments using GitHub Actions or GitLab CI, testers should assess whether a compromised third-party Action or include could exfiltrate secrets or modify build outputs. These simulations directly test the blast radius scenarios mapped in Phase 3 and validate whether supply chain controls are effective in practice, not just in policy.

• API Exploitation: API vulnerabilities identified in Phase 4 should be actively exploited to determine true business impact. This includes demonstrating BOLA by accessing resources belonging to other users, bypassing authentication on sensitive endpoints, and chaining API vulnerabilities across microservices to escalate access. Mass assignment vulnerabilities — where API endpoints accept and process fields they should not — should be tested against all object creation and update endpoints. GraphQL-specific testing should include introspection abuse, query depth attacks, and field-level authorization bypass. Tools like Postman, Insomnia, and Akto can be used to systematically exercise API endpoints, while custom scripts allow targeted exploitation of logic-level flaws.

• Credential Attacks and Lateral Movement: Beyond software exploits, testers will also perform attacks like password guessing, pass-the-hash, token impersonation, etc., if in scope. Continuous testing might integrate with the organization's password policy checks by regularly attempting password spray or brute-force attacks on external portals (to ensure weak passwords aren't being used) or on internal systems if credentials are obtained. If an exploit yields user credentials (for instance, dumping a password hash), testers attempt to use those to move laterally through the network — mimicking how a real attacker would propagate. They will test if reused passwords allow hopping between systems, or if a low-level account can escalate privileges on a machine.

• Purple Team Exercises: CPTM's exploitation phase must include structured purple team exercises that go beyond stealth testing to create deliberate, collaborative validation between offensive and defensive teams. In a purple team exercise, the red team (testers) execute specific ATT&CK techniques in real time while the blue team (SOC/defenders) attempts to detect and respond, with both teams sharing observations openly. Each exercise should follow a defined format: select ATT&CK technique(s) to emulate, execute in a controlled manner, document whether detection fired, identify the gap if it did not, and implement a detection improvement before the next cycle. Reference models such as TIBER-EU and MITRE ATT&CK Evaluations provide structured templates for purple team cadence and reporting. Purple team exercises should run at a minimum quarterly, with findings feeding directly into both the threat model (Phase 3) and detection engineering backlog. The measurable output is ATT&CK technique coverage improvement over time — tracking which techniques the organization can now detect that it could not in the prior cycle.

• Social Engineering Exploits: If included in scope, continuous exploitation may extend to ongoing social engineering testing. For example, conducting phishing campaigns against employees every quarter to see if credentials or access can be obtained, or attempting phone pretexting or physical tailgating if physical security is also in scope. Each campaign's results feed back into improved training and technical controls (like better email filtering) and future campaigns adjust in technique (just as attackers would).

• Persistence and Evasion Techniques: To truly simulate advanced threats, testers may also employ techniques to persist and evade detection once they have a foothold. For example, after gaining access to a test system, they might install a harmless beacon or schedule a task (ensuring no real damage, but something that would mimic a backdoor) to see if the security monitoring detects it. They can test disabling antivirus or bypassing endpoint protection in controlled ways. Because CPTM is ongoing, one cycle might focus on initial access techniques, another on lateral movement, another on persistence — over time covering the full spectrum of ATT&CK tactics.

• Chained Exploits and Advanced Scenarios: Testers look to chain multiple vulnerabilities or findings for greater effect. Continuous testing is ideal for this, as you might find pieces of the puzzle in different rounds. For instance, a low-severity info leak found in one month (like a stack trace revealing software versions) might, when combined with a new exploit disclosed the next month for that software, allow a serious breach. The team actively revisits prior findings to see if new exploits can be applied.

Continuous Aspect: Continuous exploitation means the organization is regularly stress-testing its defenses with real attacks, not just scanning. One advantage is that it keeps the defender teams (IT ops, security monitoring, incident response) on their toes and provides ongoing practice. It essentially brings a bit of "red team" exercise into the regular routine. In fact, organizations practicing CPTM often integrate it with their Defensive SOC through purple teaming: testers share results with the SOC to improve detection, or sometimes do stealth tests to gauge detection and then reveal them. This is why some companies speak of an "Offensive SOC" — a dedicated team continuously attacking the organization to complement the defensive SOC.

Objective: Assess and document the impact of successful exploitations, and perform controlled post-exploit activities to fully understand the business risk of the vulnerabilities. In this phase, the focus is on answering: "Once we're in, what can we do? What damage could an attacker inflict and how can we prevent it?" Post-exploitation involves digging deeper after initial access is gained — extracting data, escalating privileges, pivoting to other networks, and generally seeing how far an attacker could go. It also includes cleanup and ensuring no lasting effects from the tests.

Process & Procedures:

• Privilege Escalation: After gaining access to a system (say as a regular user), testers attempt to elevate their privileges to gain administrative or root access. This may involve trying known privilege escalation exploits, exploiting misconfigurations (like weak service permissions or accessible secrets), or using credential theft tools (for instance, using Mimikatz to dump credentials from memory on Windows machines). In cloud environments, privilege escalation assessment includes chaining IAM permissions — identifying roles that allow PassRole, AssumeRole, or CreatePolicy actions that could be leveraged to achieve administrative access even without a direct admin policy assignment. Tools like Pacu automate many AWS privilege escalation paths, and similar frameworks exist for Azure and GCP. Continuous testing ensures that as new privilege escalation techniques are discovered in the wild, they are tried against the environment.

• Lateral Movement: Using the access from a compromised host, testers explore the internal network to see what other systems they can reach and compromise. They might use tools like BloodHound to map Active Directory relationships and identify high-value targets (like Domain Controllers) reachable from their foothold. The iterative nature of CPTM means that lateral movement isn't just one pass; testers can methodically work their way through network segments over time. One month's test might fully explore segment A, next month segment B, etc., gradually ensuring every corner of the internal environment is assessed for lateral movement opportunities.

• Data Exfiltration & Impact Demonstration: Once deeper access is obtained, testers attempt to access sensitive data or critical functions to demonstrate the real impact. For example, if they reach a database with customer information, they may extract a sample (in a safe, controlled way) to prove data access. Additionally, testers may simulate exfiltration by sending data out in various ways (FTP, HTTP, DNS tunneling, cloud storage upload, etc.) to test data loss prevention controls and monitoring. Since CPTM is ongoing, testers can vary these techniques over time, effectively training the organization to detect and stop data theft attempts.

• Persistence & Covering Tracks: In some cases, testers will implement persistence measures (as allowed) to see if they can remain undetected in the environment. Any persistence created is removed at the end of the exercise. PTES includes "post exploitation — cleanup" as a step, which is critical here: the testers must remove any backdoors or accounts they created and generally restore systems to pre-test state after they've gathered the needed information.

• Documentation of Findings and Lessons: As part of post-exploitation, testers document exactly what actions were taken and what was achieved. This includes mapping out the path: e.g., "compromised host A using vulnerability X, then stole credentials for user Y, which were reused on host B giving admin access, then accessed database Z containing credit card data." Each step is tied to specific vulnerabilities or misconfigurations that allowed it, which will all be reported for remediation. In continuous testing, these narratives accumulate and can be used to measure improvement over time.

Continuous Aspect: Post-exploitation in a continuous model is usually done in small, controlled doses very regularly, rather than a massive all-out compromise once in a blue moon. This has the advantage of regularly exercising the organization's detection and response muscles. It turns security from a periodic fire drill into a continuous improvement process.

Objective: Deliver timely and actionable findings to stakeholders, support the remediation of identified issues, and feed lessons learned back into the cycle for continuous improvement. In CPTM, reporting is not a one-time final document, but a continuous flow of information and periodic summaries that ensure both technical teams and executives stay informed of security posture. This must be facilitated with a dynamic web portal or ticketing system. This phase closes the loop by turning discoveries into improvements, aligning with the organization's risk management and compliance requirements.

Process & Procedures:

• Real-Time Reporting of Findings: One hallmark of continuous testing is that critical and actionable findings are reported immediately rather than waiting for a final report at the end of an engagement. When the team discovers a high-risk vulnerability (e.g., an easily exploitable admin-level flaw or evidence of a critical misconfiguration), they will notify the appropriate stakeholders right away. This could be through an established alert mechanism — for example, creating a ticket in the issue tracking system, sending an encrypted email to the security officer, or posting in the dedicated Slack/Teams channel for the engagement.

• Continuous Reporting Platform: Many continuous programs utilize a reporting dashboard or portal (sometimes provided by a PTaaS platform) where all findings are logged and updated in real time. Stakeholders can log in at any time to see the current status: which vulnerabilities are open, which are closed, trending metrics, etc. This dynamic reporting is a big shift from static PDF reports — it provides real-time updates to executives and engineers.

• Formal Reports and Executive Summaries: Despite the focus on real-time communication, formal documentation is still important for record-keeping, compliance, and communicating with higher-level stakeholders. CPTM typically provides periodic summary reports — perhaps monthly or quarterly — that compile the continuous findings into a coherent document. These reports include key performance indicators: Mean Time to Remediation (MTTR), Vulnerability Escape Rate (vulnerabilities that bypassed earlier detection stages), Coverage Rate (percentage of in-scope assets assessed in the period), and Detection Rate (percentage of simulated attacks detected by the defensive team). These named KPIs replace vague metric descriptions and give management a consistent, comparable view of program performance over time. At any given point, a complete penetration testing report can be generated to satisfy auditors or management, covering all work done in that period.

• Remediation Guidance and Collaboration: The testing team doesn't just drop findings on the developers/IT teams; they collaborate to ensure fixes are understood and effectively applied. For each finding, detailed remediation guidance is given — whether it's a recommended patch, code fix, configuration change, or additional security control. In a continuous model, testers and defenders often work side-by-side throughout the year. This tight feedback loop leads to faster patching and more secure design over time.

• Retesting and Validation: Once an issue is reported and the organization implements a fix, the CPTM team performs a re-test of that issue. Continuous testing ensures that vulnerabilities truly get closed and stay closed. For certain vulnerability classes, automated continuous validation can be implemented — for example, if an open S3 bucket was found and fixed, a script can continuously check that the bucket remains private, alerting if it ever misconfigures again.

• Metrics and Continuous Improvement: CPTM reporting includes metrics that help quantify improvements and remaining risks. The four core KPIs for a mature CPTM program are: MTTR (Mean Time to Remediation — how quickly vulnerabilities are fixed after discovery), Vulnerability Escape Rate (how many vulnerabilities bypass earlier detection stages and reach production), Coverage Rate (what percentage of in-scope assets were assessed in a given period), and Detection Rate (what percentage of red team techniques were detected by the blue team — a direct output of purple team exercises in Phase 5). These metrics should be trended over time and presented to leadership quarterly to demonstrate program maturity and guide investment decisions.

• Alignment with Defense and Strategy: The findings and results from CPTM feed into broader security strategy. Regular reports can be mapped to frameworks like NIST CSF or ISO 27001 controls to show where weaknesses lie, helping guide risk management. Because CPTM exceeds just technical testing and becomes part of continuous risk evaluation, it is highly valuable to stakeholders outside of IT/security as well, such as enterprise risk managers and auditors.

Continuous Aspect: The reporting and feedback phase in CPTM is essentially a continuous communication and improvement cycle. Stakeholders aren't left waiting or wondering — they have near real-time insight. Moreover, by constantly feeding the results back into Phase 1 (Planning) and Phase 3 (Threat Modeling), CPTM creates a learning system. Over time, continuous testing can lead to fewer findings of the same type (since issues get fixed and stay fixed), allowing the team to focus on more advanced testing and edge cases, thereby continually increasing the security maturity. This is how CPTM surpasses traditional approaches — it's not just find-and-fix; it cultivates an ongoing security mindset and adaptation process.

With the phases described above, CPTM covers the full lifecycle of security testing in a continuous loop. Each phase feeds into the next, and the final phase (reporting/feedback) loops back to planning, creating a virtuous cycle of improvement.

CPTM is designed to be tool-agnostic, meaning it does not rely on any specific vendor or product. Instead, it prescribes what needs to be done, allowing organizations to choose the tools that best fit their environment, budget, and expertise. In practice, a variety of tools (open-source and commercial) can be used to implement continuous penetration testing. This section provides suggestions for "best-of-breed" tools in different categories of the testing process.

Reconnaissance & Asset Discovery Tools

• External Footprint and OSINT Tools: Tools like Shodan and Censys can continuously monitor the internet for your organization's assets (e.g., by IP range or domain) and report new services exposed. SecurityTrails (which absorbed the former Spyse platform) and BinaryEdge are similar platforms for attack surface and DNS history discovery. For a more tailored approach, OWASP Amass is an open-source tool that can enumerate subdomains and map external networks, useful for continuous domain discovery. Recon-ng is a full-featured web reconnaissance framework with a modular architecture, capable of automating data gathering from DNS records, social media, breach data, and other public sources. theHarvester is another tool that scrapes search engines and public sources for emails, subdomains, IPs, and more — it can be run periodically to find newly mentioned assets or credentials online.

• Network Scanning & Mapping: Nmap, the classic network scanner, is invaluable for continuous recon. It can be scripted to scan known networks on a schedule and output any changes (new hosts or ports). Its scripting engine (NSE) can even perform simple vulnerability checks or gather additional info from services. In cloud environments, the cloud provider's APIs (AWS, Azure, GCP) along with tools like CloudMapper or AzureHound can enumerate instances and services regularly.

• Supply Chain & Secrets Discovery: Continuously monitoring source code repositories and build pipelines for exposed credentials and supply chain risks is a critical reconnaissance function. TruffleHog and Gitleaks scan Git repositories and commit history for hardcoded secrets, API keys, and credentials that should never have been committed. Syft generates a Software Bill of Materials (SBOM) from container images and application dependencies, providing a continuous inventory of third-party components for downstream vulnerability assessment. These tools should run as part of every CI/CD pipeline and on a scheduled basis against all repositories, ensuring secrets exposure and new supply chain components are detected immediately.

• OSINT and Threat Intel Feeds: Subscribing to and using threat intelligence feeds is crucial. Services like HaveIBeenPwned (to see if company emails appear in breaches), AlienVault OTX, and VirusTotal provide alerts on indicators associated with your domain or IPs. Maltego is a powerful visualization tool that aggregates OSINT relationships, useful for deeper investigation during recon.

Vulnerability Scanning & Analysis Tools

• Network/Infrastructure Vulnerability Scanners: Nessus (by Tenable), QualysGuard, and Rapid7 InsightVM (Nexpose) are leading commercial scanners that can be scheduled for continuous scanning and offer robust reporting. OpenVAS (Greenbone Community Edition) is a popular open-source alternative. These scanners should be integrated with the CISA KEV catalog and EPSS feeds so that newly listed exploited vulnerabilities automatically trigger priority scans against relevant assets.

• Web Application Scanners (DAST): For continuous web app testing, OWASP ZAP (open-source) can be automated to spider and scan web applications for common vulnerabilities in daemon/API mode suitable for CI pipeline integration. Burp Suite (professional edition) has an automated scanner that can be used similarly. Acunetix and NetSparker are commercial web scanners with CI integration features.

• API Security Testing Tools: Dedicated API security testing requires tools beyond traditional DAST scanners. Postman and Insomnia allow testers to build and execute comprehensive API test collections that can be run continuously against evolving API surfaces. Akto is an open-source API security testing platform that can discover API inventory and run automated security checks aligned to the OWASP API Security Top 10. For GraphQL specifically, tools like InQL and Clairvoyance support schema extraction and query fuzzing. API security tests should be embedded in CI/CD pipelines to trigger on any API contract change.

• AI/LLM Security Testing Tools: Testing AI-integrated systems requires a specialized toolset. Garak is an open-source LLM vulnerability scanner that probes models for prompt injection, jailbreaks, and data leakage. PyRIT (Python Risk Identification Toolkit for Generative AI), developed by Microsoft, supports automated red teaming of generative AI systems. Promptmap automates prompt injection testing across multiple LLM endpoints. MITRE ATLAS and the OWASP Top 10 for LLM Applications serve as the primary reference frameworks for structuring AI security assessments. These tools should be incorporated into any pipeline that deploys or updates AI-integrated components.

• Supply Chain & Dependency Scanning: Grype and Trivy are fast, open-source container and filesystem vulnerability scanners that integrate natively with CI/CD pipelines to catch vulnerable dependencies before they reach production. OWASP Dependency-Check supports a broad range of languages and package managers. Syft generates SBOMs for ongoing inventory. StepSecurity Harden-Runner monitors and restricts GitHub Actions pipeline behavior to detect and prevent supply chain attacks at the CI layer. Semgrep provides static analysis rules specifically targeting supply chain and dependency risks. These tools collectively ensure the supply chain is continuously assessed rather than treated as a trusted black box.

• Cloud and Container Security Tools: ScoutSuite (multi-cloud security auditing), Prowler (AWS security best practices), Pacu (AWS exploitation framework for privilege escalation and lateral movement testing), and kube-hunter (Kubernetes environment scanning) can be run continuously to catch cloud-specific misconfigurations or vulnerabilities. These complement traditional scanners by covering cloud control plane issues including IAM misconfigurations, exposed metadata endpoints, and serverless function weaknesses.

• Vulnerability Management Platforms: Platforms like Tenable.sc, Qualys VMDR, or open-source DefectDojo aggregate results from multiple scanners into a unified workflow. DefectDojo integrates natively with GitLab CI/CD and GitHub Actions pipelines, allowing findings from DAST, SAST, SCA, and manual testing to be deduplicated and tracked in a single system. This ensures the full picture of continuous assessment is visible to both technical and management stakeholders.

Exploitation & Post-Exploitation Tools

• Exploitation Frameworks: Metasploit Framework is a go-to tool, offering hundreds of exploit modules for different platforms. Core Impact and Canvas are commercial frameworks with similar capabilities.

• Post-Exploitation Toolkits: Tools like Mimikatz (for extracting Windows credentials from memory), Cobalt Strike (commercial), or the open-source Sliver framework can be used to manage compromised machines, escalate privileges, and move laterally in a controlled manner. BloodHound (with Neo4j and SharpHound) maps Active Directory trust relationships and finds the shortest path to Domain Admin. Pacu serves the equivalent role for AWS environments.

• Password Cracking and Brute Force: Hashcat and John the Ripper for cracking password hashes. Hydra, Medusa, or Ncrack for online brute-force against SSH, RDP, and web forms — used carefully with appropriate throttling to avoid lockouts.

• Social Engineering Tools: GoPhish for automated phishing campaigns, SET (Social Engineer's Toolkit) for payload crafting and fake websites.

• Breach and Attack Simulation (BAS) Platforms: Tools like AttackIQ, SafeBreach, or Cymulate automate certain exploitation and attack paths continuously in a safe manner, complementing human-led testing by continuously validating common ATT&CK technique coverage.

Continuous Monitoring & Integration Tools

• CI/CD Integration: Jenkins, GitLab CI, or GitHub Actions can be configured to run security tools at defined pipeline stages, ensuring security tests trigger automatically with every code push or infrastructure change.

• Alerting and Communication: Slack bots or Microsoft Teams webhooks for real-time alerts, linked to vulnerability management systems and ticketing platforms like JIRA or ServiceNow for automatic ticket creation and assignment.

• Attack Surface Management (ASM) Platforms: Commercial ASM solutions (e.g., Randori, Palo Alto Xpanse) continuously map assets and probe them for exposures, feeding information to the CPTM team without manual effort.

• Logging and SIEM Integration: Platforms like Splunk, QRadar, or Elastic Security provide visibility into whether CPTM attack simulations are being detected, directly informing purple team exercise outcomes and detection engineering priorities.

Summary: A successful continuous penetration testing program uses a suite of tools rather than one monolithic solution, with each tool addressing a different aspect — discovery, scanning, exploiting, monitoring. The specific tools can be swapped in and out; what's important is that the capabilities — continuous discovery, scanning, exploitation, and monitoring — are fully realized across all attack surfaces including traditional infrastructure, cloud-native environments, APIs, AI/LLM systems, and the software supply chain.

Continuous Penetration Testing Methodology (CPTM) is rooted in best practices and core principles defined by major security frameworks. In this section, we map CPTM to four key references: NIST SP 800-115, MITRE ATT&CK, the Penetration Testing Execution Standard (PTES), and Gartner's Continuous Threat Exposure Management (CTEM) framework. We will show how CPTM aligns with each and, importantly, how it extends or exceeds their requirements by introducing a continuous, iterative approach.

Alignment with NIST SP 800-115

NIST Special Publication 800-115 provides guidance on planning and conducting technical security assessments, including penetration testing. CPTM aligns with NIST 800-115's core stages and then goes beyond by making them continuous:

• Phases (Planning, Execution, Post-Execution): NIST 800-115 broadly breaks a security assessment into Planning, Execution, and Post-Execution activities. In CPTM, Phase 1 (Planning & Engagement) corresponds directly to NIST's Planning stage, Phases 2–6 together make up the Execution stage, and Phase 7 (Reporting & Feedback) covers Post-Execution activities. Every element NIST expects is present.

• Techniques and Thorough Coverage: NIST SP 800-115 provides a catalog of assessment techniques. CPTM incorporates all of these within its phases — network mapping and port/service identification in Phase 2, vulnerability scanning in Phase 4, password cracking and exploitation in Phase 5, and social engineering as a potential vector in Phases 2 and 5 — and schedules them on a recurring basis.

• Frequency and Continuous Improvement: CPTM exceeds NIST 800-115 by applying its cycle continuously rather than as a point-in-time assessment. This yields benefits in risk reduction that NIST 800-115 doesn't explicitly address. Every good practice from NIST is executed repeatedly, dramatically narrowing the gap between assessments.

In summary, CPTM is fully aligned with NIST SP 800-115 and exceeds its requirements by treating the NIST cycle as an iterative loop, turning a point-in-time assessment into a continuous validation program.

Alignment with MITRE ATT&CK Framework

The MITRE ATT&CK framework is a knowledge base of adversary tactics and techniques. CPTM leverages ATT&CK in the following ways:

• Threat Modeling & ATT&CK Matrix: In Phase 3, CPTM explicitly incorporates MITRE ATT&CK to model adversaries and their TTPs, mapping likely threat actor behaviors to testing scenarios. This ensures test cases are informed by the extensive catalog of real-world techniques in ATT&CK.

• Comprehensive Adversary Emulation: CPTM's Phases 2–6 collectively address ATT&CK's full tactic set — from Initial Access and Execution through Persistence, Privilege Escalation, Lateral Movement, Collection, Exfiltration, and Impact — ensuring the full kill chain is emulated, not just entry points.

• Continuous ATT&CK Coverage: Because ATT&CK is frequently updated, CPTM's continuous nature means the threat model is regularly updated to include new techniques. CPTM operationalizes ATT&CK in a continuous validation context rather than referencing it once at engagement start.

• MITRE ATLAS for AI/LLM: For AI-integrated systems, CPTM supplements ATT&CK with MITRE ATLAS (Adversarial Threat Landscape for AI Systems), which provides a comparable matrix of adversarial tactics and techniques specific to machine learning systems. This ensures AI attack surfaces receive the same structured, framework-aligned treatment as traditional infrastructure.

In summary, CPTM is ATT&CK-aligned by design and extends that alignment to AI systems via MITRE ATLAS, ensuring comprehensive adversary-focused coverage across the full technology stack.

Alignment with PTES (Penetration Testing Execution Standard)

The Penetration Testing Execution Standard (PTES) is a well-known industry standard outlining a complete pen test process in seven phases. It is important to note that PTES and OWASP's Web Security Testing Guide (WSTG) are distinct standards: PTES defines the overall penetration testing lifecycle and execution structure, while OWASP WSTG provides detailed technical test cases specifically for web application security. CPTM draws on both — PTES for overall process structure and OWASP WSTG for web and application-level test case coverage. CPTM maps to all seven PTES phases as follows:

• PTES Phase 1: Pre-Engagement Interactions → CPTM Phase 1 (Planning & Engagement). CPTM covers all PTES guidance here and extends it by treating pre-engagement as a continuous, living process rather than a one-time kickoff.

• PTES Phase 2: Intelligence Gathering → CPTM Phase 2 (Continuous Reconnaissance & Asset Discovery). CPTM intensifies this by making intelligence gathering persistent and extending it to supply chain components and AI endpoints.

• PTES Phase 3: Threat Modeling → CPTM Phase 3 (Threat Modeling & Attack Planning). CPTM embeds this continuously, enriched with ATT&CK, ATLAS, and supply chain threat scenarios.

• PTES Phase 4: Vulnerability Analysis → CPTM Phase 4 (Continuous Vulnerability Assessment). CPTM fully implements this with ongoing automated scanning and manual analysis, extended to cover AI/LLM systems, APIs, and supply chain components.

• PTES Phase 5: Exploitation → CPTM Phase 5 (Exploitation & Attack Execution). CPTM repeats exploitation whenever new opportunities arise, extending it to include AI/LLM exploitation, API exploitation, supply chain attack simulation, and structured purple team exercises.

• PTES Phase 6: Post-Exploitation → CPTM Phase 6 (Post-Exploitation & Impact Analysis). CPTM covers all PTES post-exploit tasks and extends them to include cloud-native privilege escalation paths and IAM abuse scenarios.

• PTES Phase 7: Reporting → CPTM Phase 7 (Reporting & Continuous Feedback). CPTM exceeds PTES reporting requirements by providing real-time continuous reporting, defined KPIs (MTTR, Escape Rate, Coverage Rate, Detection Rate), and a structured remediation feedback loop rather than a single final deliverable.

CPTM encompasses all seven PTES phases and exceeds them by treating the PTES cycle as an ongoing program rather than a single engagement, eliminating the gap between test cycles.

Note on OWASP WSTG: OWASP's primary application security testing reference is the Web Security Testing Guide (WSTG), which provides detailed test cases for web application vulnerabilities. CPTM practitioners use the OWASP WSTG as a continuous reference for web and application testing in Phases 4 and 5, ensuring OWASP-recommended test cases (including OWASP Top 10 issues) are applied on an ongoing basis rather than annually. The OWASP Top 10 for LLM Applications extends this coverage to AI-integrated systems. OWASP's API Security Top 10 is applied specifically to API testing. These distinct OWASP resources each address a specific technology layer, and CPTM applies them in combination to achieve comprehensive application security coverage.

Alignment with Gartner CTEM (Continuous Threat Exposure Management)

Gartner's Continuous Threat Exposure Management (CTEM) framework defines a five-stage program for ongoing management of security exposures. CTEM represents the strategic model for enterprise security programs that move beyond periodic testing toward continuous exposure management. CPTM maps directly to all five CTEM stages:

• CTEM Stage 1: Scoping → CPTM Phase 1 (Planning & Engagement). Both involve defining which assets and business processes are in scope for continuous exposure management. CPTM's continuous scope review directly fulfills CTEM's intent that scoping is revisited as the business and threat landscape evolve — including new scope categories like AI services and supply chain components.

• CTEM Stage 2: Discovery → CPTM Phase 2 (Continuous Reconnaissance & Asset Discovery). CTEM's discovery stage calls for ongoing identification of assets and exposures across the full attack surface. CPTM's always-on reconnaissance with EASM tooling, supply chain enumeration via SBOM generation, AI endpoint discovery, and secrets scanning directly operationalizes this stage.

• CTEM Stage 3: Prioritization → CPTM Phase 3 (Threat Modeling & Attack Planning) and Phase 4 (Vulnerability Assessment). CTEM calls for risk-based prioritization of exposures based on exploitability and business impact. CPTM implements this through continuous threat modeling, KEV catalog integration, and EPSS-based triage — ensuring the highest-risk exposures are always at the front of the testing queue.

• CTEM Stage 4: Validation → CPTM Phase 5 (Exploitation & Attack Execution) and Phase 6 (Post-Exploitation & Impact Analysis). CTEM's validation stage requires confirming whether identified exposures are truly exploitable and what their real-world impact would be. CPTM delivers this through continuous exploitation, adversarial simulation, and structured purple team exercises that validate both the exploitability of findings and the detection capability of the defensive team.

• CTEM Stage 5: Mobilization → CPTM Phase 7 (Reporting, Remediation & Continuous Feedback Loop). CTEM's mobilization stage focuses on operationalizing findings — ensuring remediation actions are assigned, tracked, and completed. CPTM delivers this through real-time reporting, defined KPIs, collaborative remediation guidance, and automated retest validation that confirms fixes hold over time.

By mapping formally to CTEM, CPTM positions itself as the operational implementation layer for enterprise exposure management programs. Where CTEM defines the strategic framework for what continuous exposure management should achieve, CPTM defines the tactical methodology for how penetration testing delivers on that vision. Organizations adopting CTEM as a strategic model will find CPTM to be a natural and complete operational complement.

How CPTM Exceeds These Standards

To synthesize the alignment:

• NIST 800-115 gave us structure and thoroughness; CPTM implements it continuously, achieving real-time risk reduction beyond NIST's one-time assessments.

• MITRE ATT&CK gave us breadth of attacker techniques; CPTM actively uses it — alongside MITRE ATLAS for AI systems — to ensure all those techniques are tested in a rolling fashion, rather than sporadically.

• PTES gave us a complete pen test process; CPTM runs that process in a loop, ensuring no phase is ever idle and the organization is always in some part of the test cycle.

• Gartner CTEM gave us the strategic model for continuous exposure management; CPTM provides the tactical penetration testing methodology that operationalizes every CTEM stage, making CTEM actionable at the practitioner level.

By exceeding the requirements of these frameworks, CPTM provides a higher level of assurance and addresses the critical gap they all share when applied traditionally: the gap between tests. CPTM all but eliminates that gap.

Implementing CPTM represents a significant shift from traditional annual or point-in-time penetration testing. This shift brings numerous benefits that collectively make a strong case for CPTM as a superior approach across various industries.

1. Real-Time Vulnerability Management and Reduced Exposure Window

One of the most compelling benefits of CPTM is the dramatic reduction in the window of exploitability (WoE). Continuous testing closes this gap by providing ongoing discovery and testing of new changes. As a result, vulnerabilities are often found within days or weeks of introduction rather than potentially a year later. CPTM turns security testing into a 24/7 process, matching the around-the-clock nature of cyber threats.

2. Higher Frequency, Continuous Improvement

Continuous testing leads to a culture of continuous improvement in security. With frequent testing, the organization is in a constant cycle of finding and fixing issues. Teams fix issues faster because they are tackled in smaller batches rather than hundreds at year-end, improving Mean Time to Remediate (MTTR) dramatically. Security testing becomes an integral part of operations, not an afterthought.

3. Comprehensive Coverage Over Time

A single penetration test, no matter how well done, is limited by time and scope. With CPTM, coverage can be spread out logically over the year so that everything gets attention eventually. This includes traditional infrastructure, cloud-native environments, APIs, AI/LLM services, and the software supply chain — attack surfaces that a point-in-time test will rarely cover with adequate depth.

4. Improved Reporting and Stakeholder Engagement

Continuous testing changes the nature of reporting from a static document to an interactive, ongoing dialog. Dynamic reporting means executives and technical teams get continuous updates through dashboards or frequent summaries. Defined KPIs (MTTR, Escape Rate, Coverage Rate, Detection Rate) give management a consistent, measurable view of program performance over time, replacing the subjective narrative of an annual report.

5. Adaptive to Change and Agile/DevOps Integration

CPTM can be tightly integrated with CI/CD pipelines, making security testing a natural part of the development lifecycle. When a new vulnerability like Log4Shell emerges, a CPTM program can scan, validate, and report exposure within days rather than waiting for the next scheduled engagement.

6. Demonstrable Risk Reduction and ROI

Continuous programs can demonstrate ROI with measurable metrics. The drip-feed of vulnerabilities ensures teams are not overloaded and can actually fix everything that's found in a reasonable time, preventing the buildup of a large backlog of vulnerabilities that characterizes annual testing programs.

7. Applicability Across Industries

CPTM is a methodology that can be tailored to any industry:

• Finance and Banking: Continuous testing helps ensure customer financial data and transactions are secure at all times and provides ongoing compliance evidence for PCI DSS, FFIEC, and similar requirements.

• Healthcare: Continuous testing addresses HIPAA Security Rule requirements and keeps pace with the rapid adoption of telemedicine, connected medical devices, and AI-assisted clinical tooling.

• Retail and E-Commerce: CPTM catches vulnerabilities introduced during rapid release cycles and ensures continuous PCI DSS compliance for cardholder data environments.

• Technology/Software Companies: In DevOps environments with daily releases, CPTM is almost a necessity. It provides the continuous security validation layer that traditional annual testing cannot deliver at the pace of modern software development.

• Manufacturing and Industrial (ICS/SCADA): CPTM can be carefully tuned to continuously test the perimeter and non-invasive parts of OT networks, protecting critical infrastructure proactively in alignment with NERC CIP and similar frameworks.

• Government and Defense: CPTM aligns with Continuous Diagnostics and Mitigation (CDM) programs and prepares organizations against nation-state level threats through persistent red team operations.

• Small and Medium Businesses (SMBs): PTaaS-based continuous testing models make CPTM accessible to organizations without dedicated security teams, providing near-enterprise-level security oversight at a predictable subscription cost.

8. Staying Ahead of Attackers and Compliance Trends

Attackers are not waiting for next year's pen test. CPTM mirrors the attacker's persistence with an equal persistence in defense. Industry standards are also evolving in this direction — Gartner's CTEM framework and PCI DSS requirements for testing after significant changes both reflect a broader industry movement toward continuous security validation. By adopting CPTM now, organizations are aligned with the future direction of cybersecurity best practices.

Conclusion: Continuous Penetration Testing Methodology (CPTM) offers a forward-leaning, rigorous approach to security assurance that aligns with top industry frameworks — NIST SP 800-115, MITRE ATT&CK, PTES, and Gartner CTEM — and addresses the shortcomings of traditional testing across every attack surface including infrastructure, cloud-native environments, APIs, AI/LLM systems, and the software supply chain. By following the detailed phases and practices outlined in this guide, organizations can implement CPTM to achieve a state of security that is resilient, responsive, and demonstrably compliant with best practices. It is a methodology that evolves with your business, protects it in real time, and creates a cycle of continuous improvement — ultimately elevating your security posture to meet the demands of the modern threat landscape.

Paul Petefish – Author

Ramandeep Singh – Contributor

Mark Carney – Reviewer

Jason Rowland – Reviewer

Ben Johnson – Reviewer

1. Scarfone, K., Souppaya, M., Cody, A., & Orebaugh, A. (2008). Technical guide to information security testing and assessment (NIST Special Publication 800-115). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-115

2. Strom, B. E., Applebaum, A., Miller, D. P., Nickels, K. C., Pennington, A. G., & Thomas, C. B. (2018). MITRE ATT&CK: Design and philosophy (Technical report). The MITRE Corporation.

3. MITRE Corporation. (2023). MITRE ATLAS: Adversarial Threat Landscape for AI Systems. Retrieved from https://atlas.mitre.org

4. OWASP Foundation. (n.d.). Penetration testing methodologies. In OWASP Web Security Testing Guide. Retrieved November 20, 2025, from https://owasp.org/www-project-web-security-testing-guide/latest/3-The_OWASP_Testing_Framework/1-Penetration_Testing_Methodologies

5. OWASP Foundation. (2014). OWASP Web Security Testing Guide (Version 4). Retrieved from https://owasp.org/www-project-web-security-testing-guide/

6. OWASP Foundation. (2023). OWASP Top 10 for Large Language Model Applications. Retrieved from https://owasp.org/www-project-top-10-for-large-language-model-applications/

7. OWASP Foundation. (2023). OWASP API Security Top 10. Retrieved from https://owasp.org/www-project-api-security/

8. Penetration Testing Execution Standard. (2014). Penetration Testing Execution Standard (PTES). Retrieved from http://www.pentest-standard.org

9. Gartner. (2022). Implement a Continuous Threat Exposure Management (CTEM) Program. Gartner Research.

10. CISA. (2023). Known Exploited Vulnerabilities Catalog. Retrieved from https://www.cisa.gov/known-exploited-vulnerabilities-catalog

11. First.org. (2023). Exploit Prediction Scoring System (EPSS). Retrieved from https://www.first.org/epss/

12. PortSwigger Ltd. (2025). Burp Suite documentation. Retrieved from https://portswigger.net/burp/documentation/

13. Amazon Web Services. (2021). AWS Well-Architected Framework. Retrieved from https://aws.amazon.com/architecture/well-architected/

14. Bugcrowd. (2017, February 2). Getting started – bug bounty hunter methodology [Blog post]. Bugcrowd. Retrieved from https://www.bugcrowd.com/blog/getting-started-bug-bounty-hunter-methodology/

15. Organization for the Advancement of Structured Information Standards (OASIS). (2020). STIX Version 2.1 (Committee Specification 01). Retrieved from https://docs.oasis-open.org/cti/stix/v2.1/stix-v2.1.html

16. OWASP Foundation. (n.d.). CI/CD Security Cheat Sheet. OWASP Cheat Sheet Series. Retrieved November 20, 2025, from https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html

17. National Institute of Standards and Technology. (2022). Implementation of DevSecOps for a microservices-based application with service mesh (SP 800-204C). https://doi.org/10.6028/NIST.SP.800-204C

18. Rapid7, Inc. (2023). InsightVM: Live vulnerability assessment and endpoint analytics [Product brief]. Rapid7.

19. Wazuh, Inc. (2023). How Wazuh delivers enterprise-level security for free [White paper]. Retrieved from https://wazuh.com/resources/white-paper/

20. CISA & NSA. (2023). Defending CI/CD Environments. Retrieved from https://www.cisa.gov/resources-tools/resources/defending-continuous-integration-continuous-delivery-cicd-environments

21. OpenSSF. (2023). SLSA: Supply Chain Levels for Software Artifacts. Retrieved from https://slsa.dev

22. Anthropic. (2024). Model Context Protocol (MCP) Specification. Retrieved from https://modelcontextprotocol.io

23. OWASP Foundation. (2024). OWASP Top 10 for LLM Applications — Agentic AI Addendum. Retrieved from https://owasp.org/www-project-top-10-for-large-language-model-applications/

24. CrowdStrike. (2025). Global Threat Report 2025: Non-Human Identity Attack Trends. CrowdStrike Holdings, Inc.

This methodology document was developed with assistance from generative AI (Anthropic's Claude, OpenAI's ChatGPT) to support drafting, research, and refinement of technical content.