NetSPI combines human-led penetration testing with software for managing findings and remediation. Separate modules cover attack-surface visibility and vulnerability prioritization.
Other modules support attack simulation and integrations. AI assistants can also access platform data through NetSPI’s MCP server.
The breadth suits teams building a managed offensive-security program. Teams focused on testing a web application and its source code can compare that model with CodeAnt AI’s application-focused AI penetration testing.
A PTaaS engagement puts NetSPI testers and project delivery at the center. Attack Surface Visibility monitors assets between tests, while Breach and Attack Simulation (BAS) exercises detective controls.
The platform connects the resulting data, but access depends on the modules in your agreement. This guide to the PTaaS model explains how that delivery pattern works.
TL;DR
NetSPI features at a glance:
Feature area | What NetSPI includes | Buyer check |
|---|---|---|
Penetration Testing as a Service | Human-led tests with remediation tracking | Confirm scope and retest terms |
Attack Surface Visibility | External and cloud exposure monitoring | Confirm assets and cadence |
Vulnerability prioritization | Standard scores plus exploit context | Define severity ownership |
Attack simulation | Agent-based BAS playbooks | Validate deployment requirements |
Reporting and remediation | Live findings with report exports | Confirm workflow ownership |
Integrations and API | Data exchange with security tools | Verify sync direction |
MCP and AI access | Permission-aware platform queries | Review client and token controls |
NetSPI’s defining feature is expert-led testing connected to a shared remediation system. When comparing continuous and annual pentesting, evaluate the testing cadence separately from the platform interface.
What features does NetSPI actually include?
NetSPI carries verified findings from a scoped test into remediation. Adjacent modules monitor exposures and test detective controls.
PTaaS engagement delivery across 50+ test types
NetSPI says it supports more than 50 penetration-test types. The catalog covers applications and networks across on-premises and cloud environments.
Specialist services cover AI/ML systems and mainframes. Other options include hardware assessments and red teaming.
Secure code review and threat modeling complete the published catalog.
The proposal must identify the included targets and test types.
Inside PTaaS, teams can view an engagement with its findings and report. The same record identifies the affected assets.
Teams can tag those records and assign remediation work in the same system.
Scanner results can enter through API integrations or file imports. NetSPI parses and correlates those records before its testers validate them.
Testers can also create findings during manual testing. Human assessment remains the core of the penetration-testing process.
An application assessment requires a different access model from an Entra tenant test. Mainframe and medical-device testing introduce separate constraints.
This breakdown of penetration-test types shows how those scopes differ.
For application work, specify how much internal access the tester receives. A service count does not define engagement evidence.
Consolidated findings, attack paths, and remediation states
The Findings view combines records from subscribed PTaaS and EASM modules. It includes CAASM records when available.
Summary cards show remediation status. Filters and bulk actions operate across those records.
Opening a finding reveals its technical context and related CVEs. The record can connect the issue to an attack path and affected URLs.
Remediation instructions appear alongside the activity history. The record can also show its OWASP correlation.
*NetSPI’s public documentation shows findings from three subscribed modules in one view. Image: NetSPI.*
Client teams can mark a finding as Remediation in Progress or Ready for Retest. They can later mark it Remediated or record an Accepted Risk decision.
False Positive is available for findings that do not represent a vulnerability. NetSPI testers use separate states to record whether an issue remains open or its remediation was verified.
Setting a finding to Ready for Retest does not initiate the retest. The team must still schedule it through the platform or its delivery contact, as covered in this remediation and retest guide.
Attack-surface visibility between point-in-time tests
NetSPI’s current PTaaS page lists weekly external discovery and weekly AWS and Azure configuration scans. It also advertises dark-web and look-alike-domain monitoring for two domains.
The visibility page describes the asset data behind that monitoring. Its records cover public IPs and DNS domains as well as networks and open ports.
The module also tracks shadow IT and exposed data. Fraudulent domains form another monitored category.
Discovery identifies an asset or exposure. A penetration test then attempts to verify what an attacker can do with it within an authorized scope.
An external pentest methodology separates discovery from validation. Exploitation and reporting follow as distinct stages.
The broader automated penetration-testing workflow shows where recurring discovery fits within that sequence.
The feature set describes weekly AWS and Azure configuration scans. The catalog lists cloud penetration testing as a separate service.
A configuration finding records an exposure. A privilege-escalation path demonstrates how an attacker could use it.
Use a cloud pentest checklist to define the identity paths and tenant boundaries the test may exercise. It should also record any exposed services or destructive techniques excluded from scope.
Risk prioritization with CVSS, EPSS, KEV, and exploitation context
NetSPI combines standardized risk signals with evidence from its engagements. Its prioritization page shows CVSS severity alongside the FIRST Exploit Prediction Scoring System and the CISA Known Exploited Vulnerabilities catalog.
NetSPI adds indicators for vulnerabilities it has exploited previously and vulnerabilities its testers exploited during the customer’s engagement. Teams can also apply their own severity rating.
CVSS describes technical severity, while EPSS estimates exploitation probability over the next 30 days.
KEV records vulnerabilities that CISA knows attackers have exploited in the wild. An engagement-specific exploit goes further by proving reachability in the tested scope, so a prioritization policy should not compress these signals into one unexplained score.
CodeAnt brings exploit context into development through EPSS-based code-security prioritization and code-level attack-path analysis. Its vulnerability database exposes the records behind that triage.
For example, the CVE-2026-1609 entry presents severity and CWE alongside impact and exploit preconditions. Engineers can inspect those fields instead of accepting an opaque priority label.
Breach and Attack Simulation for detective controls
NetSPI BAS runs attacker behaviors against endpoint and network controls. It can also exercise SIEM and related detective controls.
The result shows whether those controls logged or detected the activity. It also records any alert or prevention response.
The platform organizes individual simulation actions as procedures. Plays and playbooks assemble those actions into broader scenarios.
A custom playbook can chain procedures with other playbooks. Its configuration controls their order and timing.
*NetSPI’s public BAS documentation shows that a custom playbook can contain procedures and other playbooks. Image: NetSPI.*
The endpoint BAS agent is documented as a non-persistent executable that runs in memory and checks into the platform. Cloud-specific plays instead use persistent infrastructure deployed in the customer’s cloud account.
NetSPI exposes health and status for both agents and cloud deployments. Because this infrastructure runs inside the customer’s environment, the plan needs the authorization and rollback controls described in an automated pentesting checklist.
*The documented BAS Agents view distinguishes endpoint agent records by operating system and status. Image: NetSPI.*
Detection-focused engagements can map simulated activity to the MITRE ATT&CK knowledge base. Teams can then inspect coverage by tactic and technique.
The result shows whether controls observed that activity. It cannot establish whether an unrelated application vulnerability exists.
The same evidence boundary separates AI pentesting from traditional DAST. A finding only supports a conclusion about the behavior and target that the test exercised.
Integrations, imports, API access, and workflow routing
NetSPI connects to asset systems and identity providers. Other integrations ingest scanner or detective-control data and route work into ticketing systems.
The integration catalog covers cloud platforms and endpoint products. It also connects to identity directories and the Tenable scanner.
Jira and ServiceNow route findings into ticketing workflows. PTaaS can separately import files from Nmap or Nessus.
Other supported import formats include OWASP Dependency-Check and Burp Suite. Several SAST and DAST products can supply findings through file import as well.
A connector’s name does not reveal what it exchanges. Confirm whether it imports assets or findings, and whether it also updates the source system when a record changes in NetSPI.
The implementation must define authoritative fields and duplicate handling. This guide to connecting pentesting with DevSecOps explains their effect on remediation.
Reports, dashboards, assignments, and audit evidence
The platform generates PDF and HTML reports. Live dashboards provide trend analysis over time.
Role-based views tailor that information to different audiences.
Teams can assign each finding to an owner and track it against an SLA. Comments preserve the discussion around remediation.
Teams can also apply custom severity. Current product materials say findings include written reproduction steps and remediation instructions.
A report records the work performed. It does not prove that a system meets every framework requirement.
Compare the proposed deliverable with a real sample security report. The testing guidance in NIST SP 800-115 provides a neutral benchmark.
For web applications, the OWASP Web Security Testing Guide provides a neutral reference for the test areas a report may need to cover. The engagement scope should state which of those areas were exercised.
If an auditor or customer requested the test, define the scope and reporting period before kickoff. State the tester’s independence in the agreement.
The same agreement should define the severity method. It should also identify the evidence produced after retesting.
This compliance penetration-testing guide explains why report formatting cannot repair a scope mismatch. For a specific case, map the deliverable to the actual SOC 2 penetration-testing requirements instead of accepting “audit ready” as a control statement.
MCP, API, administration, and access control
NetSPI’s MCP server lets a compatible AI assistant query platform data through the user’s existing permissions. The assistant can inspect available data models and schemas before requesting filtered records or details about a finding or engagement.
The server can export results as CSV or JSON. It can also generate a PDF report.
Setup requires a container with platform credentials. An API token authorizes the connection.
The MCP server retrieves and analyzes existing NetSPI data. It does not run autonomous penetration tests.
Its client has the same exposure as another data consumer. Teams therefore need scoped platform permissions and protected tokens.
Administrators can configure MFA and allowed login IPs alongside module permissions. The same area manages API tokens and integrations.
Notification settings are also available there. Administrators can configure SLAs and tags through the platform.
NetSPI calls the wider service AI-accelerated, but its public materials do not provide a buyer-level architecture for the models used during testing. Procurement should document which testing steps use AI and which findings receive human validation.
The review should document where the model runs and which data reaches it. Retention terms must cover both inputs and outputs.
MCP documentation explains access control for queries over platform data. It does not answer those testing-architecture questions.
What is good about NetSPI’s feature set?
NetSPI keeps expert testing and the remediation record in the same operating model. A manually verified finding enters the findings view with asset context, then receives an owner and SLA before moving through remediation and retesting.
That workflow gives program teams a live record of the engagement. They do not have to rebuild a static report as a separate tracking system.
The visibility modules watch the perimeter and aggregate asset context between engagements. BAS then tests whether detective controls observed a defined attacker behavior, while prioritization helps teams separate technical severity from exploit likelihood.
The benefits of AI-assisted pentesting follow the same principle. Automation is most useful when it removes repetitive work without obscuring the evidence or the human decision behind a finding.
The breadth suits organizations that test applications and specialist infrastructure. The proposal must name each service and module entitlement.
The proposal should state the cadence and deliverable. It must also define the retest allowance.
Without those details, platform breadth does not define the purchase.
NetSPI feature limits to check before you buy
The first limit is packaging. NetSPI documents PTaaS and EASM as separate modules.
CAASM and BAS are modules as well. Its user guide says administrators can assign permissions only for subscribed services.
Product pages also say visibility and simulation come with pentesting. Request the SKU and entitlement table before comparing the variables that drive penetration-testing cost.
The second limit is cadence. Weekly discovery and cloud-configuration scans provide more coverage than an annual test.
They do not inspect every change as it happens. Teams that deploy several times a day should compare the published cadence with a continuous-pentesting CI/CD workflow.
The third limit is the source-code workflow. NetSPI offers secure code review as an assessment and can ingest findings from several SAST products, but its public PTaaS documentation does not establish a first-party scanner that comments on each pull request.
Teams that need pre-merge scanning can start with what SAST does and the boundary between SAST and DAST. They should also separate the roles of code review and penetration testing instead of expecting one assessment to replace the other.
Infrastructure repositories require explicit IaC security scanning, which is not the same as scanning a deployed cloud account for configuration errors. Regulated teams then need a defined AI pentesting compliance workflow that joins code findings with offensive-test evidence.
The fourth limit is operational setup. BAS needs an endpoint agent or cloud deployment for the scenarios it runs, while MCP needs a compatible client and container configuration.
MCP also requires credentials and scoped platform access. Retesting has its own operational step because changing a status does not schedule the work.
NetSPI vs CodeAnt AI features by use case
Buyer job | NetSPI | CodeAnt AI |
|---|---|---|
Broad offensive-security program | More than 50 published test types | Application pentesting and code security |
External and internal asset visibility | EASM/CAASM, cloud configuration, dark-web and domain monitoring | Not positioned as a general CAASM or dark-web-monitoring platform |
Detective-control validation | BAS agents, deployments, playbooks, MITRE ATT&CK mapping | Not the primary product job |
Application pentesting | Expert-led web, API, mobile, thick and virtual application testing | Agentic black-, white-, and gray-box application pentesting |
Source-code security before merge | Secure code review service plus third-party SAST imports | PR-native SAST, attack paths, EPSS context, and AI fixes |
Source-informed offensive testing | Depends on the assessment | Includes source-informed penetration testing |
Program reporting | Live platform findings, dashboards, PDF/HTML reports, assignments, SLAs, and retesting | Application-security report and reverify workflow |
Choose NetSPI when the program needs human-led testing across applications and infrastructure. Its catalog also covers specialist targets.
Visibility modules extend the program into exposure monitoring. BAS provides the control-validation layer.
Choose CodeAnt AI when the main problem sits inside the software-delivery loop. It scans pull requests and connects source-level context to application testing, then carries findings through fixes and reverification.
Compare the products on the same authorized application with the same success criteria. This AI pentesting provider checklist provides an evaluation frame for the pilot.
Who should choose NetSPI?
NetSPI fits organizations that need a managed offensive-security program across several types of target. It connects findings and asset context to remediation and retesting, while adjacent modules cover exposure visibility and detection validation.
The model suits systems that do not live in a pull request. Those assessments require human testing and specific access.
NetSPI is a weaker fit as the sole answer to PR-time code security. If the objective is to stop a vulnerable change before merge, compare it with CodeAnt’s code-security dashboard.
The pilot should test whether engineers can reproduce and fix a finding in their normal workflow. It should confirm closure after rescanning.
Before signing, request a written scope that answers five procurement questions:
the exact test types and target inventory;
the PTaaS, EASM, CAASM, and BAS entitlements;
the scan, manual-test, report, and retest cadence;
each integration’s data direction and system of record; and
the included retest allowance and completion criteria.
Use those terms to design a scoped pilot under an agreed AI penetration-testing methodology. The result should show whether the purchased workflow produces evidence that engineers can reproduce and remediate.
