API security posture assessment workflow
eight-layer record, one engagement
Most enterprise teams run API security as a series of one-shot pentests against individual APIs. The audit chain expects more: an estate inventory, schema and specification governance, authenticated coverage per API, a consolidated finding catalogue across scanners and reviews, an exception lifecycle, change-event detection, programme metrics, and a recurring audit-evidence pack. Run API security posture as a programme cycle on one engagement record so the operating loop reads against a live record between cycles rather than reconstructing the posture at audit week.
No credit card required. Free plan available forever.
API security posture is a programme cycle, not a one-shot pentest
Most enterprise teams describe their API security as a series of pentests on individual APIs plus an OWASP API Security Top 10 checklist filed against the application security policy. The single-frame description conceals the eight-layer posture record an audit chain expects to read against: the estate inventory, the schema and specification governance, the authenticated coverage rule, the per-API finding catalogue, the exception lifecycle, the change-event taxonomy, the programme metrics, and the recurring audit-evidence pack. The defensible programme runs all eight layers on one workspace so the operating loop reads against a live record between cycles rather than reconstructing the posture at audit week.
SecPortal is not an inline runtime protection layer (WAAP, API gateway, API firewall) and does not block live traffic. SecPortal holds the pre-production and continuous-assessment record: estate inventory, schema governance, authenticated and external scanning, bulk-import intake for third-party assessment output, finding catalogue with calibrated CVSS 3.1 and OWASP API Security Top 10 mapping, override register with the eight-field decision chain, change-event response queue, recurring posture report through AI-generated narrative, and audit evidence pack the GRC team reads against ISO 27001, SOC 2, PCI DSS, NIST 800-53, NIST CSF 2.0, NIS2, and DORA fieldwork. The workflow below is what shape that operating loop takes on the workspace.
Eight layers of an API security posture record
The posture record holds eight layers that the audit chain reads independently. A programme that runs strongly on the inventory layer but weakly on the change-event layer produces an evidence pack that fails on the change-event side; a programme strong on the finding catalogue but weak on schema governance carries a stale threat model the next regulator question exposes. The layers below are the structural reason the posture record is more than a finding list.
API estate inventory and ownership binding
A current list of REST, GraphQL, gRPC behind HTTP, and webhook APIs in scope, each bound to an owning team, an environment tier (production, staging, development), an exposure class (public, partner, internal), and a verified domain or repository on the workspace. Estate inventory without ownership binding is a spreadsheet that nobody updates; estate inventory with ownership binding is a queryable record that drives every downstream queue.
API surface discovery and shadow or zombie API detection
Comparison of the documented inventory against what is actually reachable on the verified domains and repositories. New endpoints discovered on production that are not on the inventory enter the shadow API queue; deprecated endpoints still reachable on production that should have been retired enter the zombie API queue. The discipline is a continuous reconciliation rather than a one-shot audit.
Schema and specification governance
A held record of the OpenAPI, GraphQL SDL, gRPC proto, or AsyncAPI specification for each API in the inventory. Specifications without a version held on the workspace are unreviewable. The governance layer captures the current spec, the prior spec, the named author, the named reviewer, the framework citations the spec carries, and the cross-reference to the engagement that produced the latest review.
Authenticated coverage and credential lifecycle
For every API in the inventory, the authenticated scan coverage running on documented credentials (cookie, bearer, basic, form, mTLS, API key, OAuth client credentials) with each credential held in the encrypted credential vault, scoped to the verified domain, and bound to the engagement that runs the scan. Credential lifecycle (issue, rotate, expire, revoke) is recorded with named actor and timestamp.
Posture findings and prioritisation
The current set of open posture findings on the API estate produced by authenticated scanning, external scanning, code scanning, manual review, imported third-party output, bug bounty intake, and internal disclosure intake. Each finding carries the affected API reference, the OWASP API Security Top 10 mapping or other taxonomy, the calibrated CVSS 3.1 vector, the routing rule, the named owner, the SLA tier, and the framework citation set the finding reads against.
Change-event detection and drift signal
A continuous read of how the estate inventory, the schema corpus, the authenticated coverage, and the finding catalogue change across scan cycles. Seven event classes recur: new API added, API exposure class changed, schema breaking change, endpoint added or removed, authentication mode changed, new finding type observed, finding resolved or regressed. Each event class has a named owner and a documented response window.
Exception lifecycle and accepted-risk register
Posture findings that the programme accepts as risk, suppresses, defers, or compensates against another control land on the override register with the eight-field decision chain (linked finding, severity, compensating controls, residual likelihood, residual impact, business rationale, expiry, review cadence). Active overrides have a named expiry; expired overrides reopen the finding rather than persisting silently.
Programme metrics and audit evidence pack
Per-cycle metrics (estate currency, shadow detection rate, specification governance currency, authenticated coverage rate, exception coverage, fix verification rate, drift fire rate) and the audit evidence pack the GRC team reads against ISO 27001, SOC 2, PCI DSS, NIST 800-53, NIST CSF 2.0, CIS Controls, NIS2, and DORA assessor fieldwork.
Seven failure modes that quietly hollow out API posture programmes
Most API posture failures look like sensible defaults: scan against a target list, file the OpenAPI spec on the repository, track findings on the scanner tool, accept exceptions in a document, run the assessment cycle once a quarter, report posture at quarter-end. The cost arrives at audit week, at the post-incident review, or at the regulator inquiry that asks the programme to reconstruct an answer the record never carried.
No estate inventory, so posture reads against the wrong scope
The team runs scans against a static target list while engineering ships new APIs every week. The posture report reads against ninety percent of the estate the assessor expects, and the missing ten percent is where the unauthenticated admin endpoint hides. The fix is opening the estate inventory as a queryable record on the workspace and reconciling it against the verified domains and the connected repositories on a documented cadence so the inventory ages on a clock the team can read.
Shadow APIs and zombie APIs persist because nothing is tracking them
A new microservice ships, exposes endpoints on the public ingress, and never lands on the inventory. A deprecated v1 endpoint stays reachable while v2 carries the actual traffic, and the v1 path is the one the attacker finds. The fix is a continuous discovery loop on the verified domains that compares observed reachable endpoints against the documented inventory and promotes the gap onto the shadow or zombie queue with a named owner and a documented response window.
Specifications are stale, so reviewers cannot read what changed
The OpenAPI document on the repository was last updated nine months ago. The deployed surface drifted, the security review consumed the wrong spec, and the threat model is based on a behaviour the API no longer has. The fix is holding the current specification per API on the workspace with named author and reviewer, comparing it against the prior version on each review cycle, and promoting unreviewed differences onto a queue rather than asking reviewers to chase the spec.
Authenticated coverage is partial, so high-impact endpoints never appear in posture
Scans run against the anonymous surface and assume the authenticated paths are covered by a separate engagement that nobody opened this quarter. Broken Object Level Authorization, Broken Function Level Authorization, mass assignment, and excessive data exposure all hide behind login screens that the scan never reached. The fix is binding authenticated coverage to each API in the inventory, storing the credential in the encrypted credential vault scoped to the verified domain, and producing per-API coverage that names which role tiers and environments the scans actually reached.
Findings sit on three tools and the consolidated posture read is a slide nobody trusts
Authenticated DAST findings live in one tool, code scanning findings in a second, imported third-party assessment findings in a spreadsheet, and bug bounty submissions on a managed platform. The consolidated read is a slide the security lead authors from memory every quarter. The fix is one workspace that holds findings from every source on a common identity (affected API reference plus finding template plus environment) with the source attribution preserved, so the consolidated read is queryable rather than narrative.
Change events are noticed only at audit time, never as operating signal
A breaking schema change, a new public endpoint, or a regressed finding lands on the estate and the posture programme reads about it three months later when the audit pack is assembled. The fix is running change-event detection on every cycle (scan, scan-import, schema-upload, code-merge, override-decision) and surfacing the event class onto a queue with a named owner and a documented response window, so the operating loop reads against the change before it accumulates into an audit observation.
Exceptions persist silently and the assessor reads the override register as the audit gap
A high finding was accepted with a six-month exception two years ago. The decision record sits in an old document, the expiry passed silently, the underlying finding was never reopened, and the assessor reads the override register as a control weakness rather than as a defensible exception lifecycle. The fix is the override register on the workspace with the eight-field decision chain, the named expiry date, the named review cadence, and the automatic reopen when the exception window lapses so the audit reads against a live lifecycle rather than a static spreadsheet.
Six scan and intake sources feeding one posture record
Posture is a consolidated read across more than one source. Programmes that maintain separate records for authenticated DAST, external scanning, code scanning, manual review, third-party imports, and bug bounty signal force the security lead to author the consolidated picture from memory. The intake sources below land on one workspace with provenance preserved so the consolidated read is queryable rather than narrative.
Authenticated scanning behind stored credentials
Authenticated DAST runs against each API in the inventory using credentials held in the encrypted credential vault. The scan reaches login-protected REST endpoints, bearer-protected paths, OAuth-protected resources, basic-auth admin surfaces, and form-login bridges. Findings carry the request, the response, the calibrated severity, and the OWASP API Security Top 10 mapping. Each scan binds back to the API in the inventory and to the engagement that scheduled the cycle.
External scanning for exposure and configuration
External scanning reads the public surface of each verified domain that hosts APIs. SSL and TLS posture, HTTP security headers, DNS exposure, port reachability, subdomain enumeration, and technology fingerprinting feed the exposure layer on every API in the inventory. The result is a per-API exposure summary that pairs to the authenticated coverage on the same engagement so the posture read covers both the outside view and the inside view.
Code scanning for repository-borne API issues
Static analysis and dependency analysis run on the repositories that ship each API. Hard-coded secrets, vulnerable dependencies, dangerous patterns, and insecure framework configuration land as findings on the workspace with the affected file path, the rule reference, and the suggested fix. The repository connection ties the code-scanning finding back to the same API in the inventory the authenticated scan reads against.
Manual review and pentest findings on the engagement
Business-logic flaws, mass assignment paths, GraphQL introspection abuse, OAuth misconfiguration, JWT trust issues, and API rate-limiting gaps land as manual findings on the engagement with the named reviewer, the proof of concept, the calibrated CVSS vector, and the framework citation. Manual findings sit on the same record as scanner output, so the posture read does not need to reconcile two systems.
Bulk import of third-party assessment output
Findings from third-party pentests, vendor assessments, partner penetration test deliverables, and historical scanner output (.nessus, Burp XML, CSV with column mapping) ingest onto the workspace with the source attribution preserved. The intake binds each imported finding to the affected API reference, the calibrated severity, and the framework citation so the posture read includes third-party signal without losing provenance.
Bug bounty and disclosure intake feeding the API posture record
External researcher submissions on managed bug bounty platforms and the internal disclosure intake channel land as findings on the API engagement after the dedup discipline runs against the open catalogue, the closed catalogue, the override register, and the scanner catalogue. The intake ledger preserves the platform identifier, the calibrated severity, and the disclosure-handling terms so the audit reads the external research input alongside the internal scan record.
Seven change-event classes the posture loop reads on every cycle
Change-event detection is what turns posture from a quarterly slide into an operating record. The seven classes below cover the events that recur on enterprise API estates. Each class has a named owner and a documented response window so the audit reads the event chronology and the response rather than the absence of a record.
| Event class | What it signals | Documented response |
|---|---|---|
| New API added to the estate | A new REST, GraphQL, gRPC, or webhook surface arrives on the inventory because engineering shipped a microservice, a partner integration went live, or a discovery loop found an undocumented endpoint on production. The event opens an onboarding queue with the named owner, the documented threat-model deadline, and the baseline scan that has to fire before the API enters steady-state. | Named API owner opens an onboarding engagement, captures the schema and the authentication model, schedules the baseline authenticated and external scans, and confirms the inventory entry within the documented response window. Until the baseline scan fires, the new API carries an explicit unverified marker on the posture report. |
| API exposure class changed | An API that was internal moves to partner, an API that was partner moves to public, or an API that was public moves to internal. The exposure change rewrites the threat-model assumptions, the required authenticated coverage, the rate-limiting expectation, and the framework citation set the API reads against. | Named API owner records the exposure change on the engagement, the security review queue captures the change for review against the new exposure class, the scan schedule updates to match the new authenticated-coverage expectations, and the activity log holds the named decider and the rationale. |
| Schema breaking change without prior security review | A schema change introduces a new endpoint, a new field, a new authentication scope, a new role hierarchy, or a removed deprecation that was load-bearing. The change shipped without a security review on the engagement, so the threat model is now stale and the next posture report would read against the wrong shape. | The change-event queue lands the diff on the API engagement, the named reviewer reads it against the prior version, the resulting findings (mass assignment exposure, new BOLA surface, new privileged role, new unauthenticated endpoint) open on the engagement, and the spec governance record updates with the named author and reviewer. |
| Authentication mode changed | A bearer-token API moves to OAuth, a basic-auth API moves to bearer, a public API gates behind an API key, or a session-cookie API splits into two flows for SPA and BFF. The credential vault and the authenticated scan coverage have to follow the change, or the next scan reads the wrong shape. | Named API owner updates the credential entry in the encrypted credential vault scoped to the verified domain, the engagement records the named credential rotation actor and timestamp, the scan schedule updates to the new mode, and the activity log carries the lifecycle. |
| New finding type observed on the API | A finding category that the API never carried before (excessive data exposure, server-side request forgery from a new internal call, broken function-level authorization on a newly added admin path) appears on the scan output or the manual review. | Named API owner inherits the new finding through the routing rule, the SLA tier reads against the calibrated severity, the override register captures any compensating control, and the recurring posture report names the new finding type in the next operating cycle read. |
| Finding resolved or regressed against a prior cycle | A finding that was open last cycle now reads as resolved on the current scan, or a finding that was closed reads as reopened because the fix reverted, the deployment rolled back, or the underlying issue regressed against a code change. | Retest workflow pairs the verification artefact to the original finding and moves the state on the same record, the aging clock keeps running on the original capture date, and the regression is held as a fresh decision on the engagement with the named reviewer, rather than the prior closure being overwritten. |
| Coverage dropped because authentication, credentials, or scope changed | A scan that reached the authenticated surface last cycle now reads only the anonymous surface because the credential expired, the verified domain dropped, the scope policy changed, or the scanner authentication failed. The coverage gap is silent unless something names it. | Change-event queue surfaces the dropped coverage onto the API engagement with the failure code (credential expired, domain unverified, authentication failure, scope policy update), the named owner restores coverage within the documented response window, and the activity log carries the lifecycle so the audit reads the gap and the recovery. |
Six named roles the posture programme runs against
Posture programmes that run against an undifferentiated AppSec inbox collapse decision accountability into a single role that the audit chain cannot reconstruct. The six roles below name each accountable role so the routing rule, the override decision, the change-event response, and the audit-evidence read each have a named owner.
API security programme owner
The named role accountable for the API estate posture read. The owner reads the inventory against the discovery loop on each cycle, schedules the threat-model and review cadence, approves the override register decisions that touch API findings, and signs the recurring posture report. The role sits inside the AppSec or product security team in most enterprise programmes.
API owner per service or product line
The engineering or product role accountable for each API in the inventory. Captures the schema and authentication mode at onboarding, accepts the routing-rule output for API findings against their service, runs the retest cycle on resolved findings, and reads the change-event queue against their service. The owner is named at API granularity rather than at team granularity so the routing rule never reads against an unowned record.
Authenticated scan operator
The role accountable for the authenticated scan coverage running against each API. Maintains the credentials in the encrypted credential vault scoped to the verified domain, schedules the recurring scans through continuous monitoring, troubleshoots authentication failures, and walks the per-API coverage report back to the API owners on the documented cadence.
Manual reviewer or pentester on the engagement
The role that adds manual review findings to the engagement (business-logic flaws, GraphQL introspection abuse, OAuth misconfiguration, JWT trust issues, mass assignment paths, rate-limiting gaps). Manual findings land on the same record as scanner output with the calibrated CVSS, the proof of concept, and the framework citation.
GRC partner and audit-evidence consumer
The GRC or compliance role that reads the audit evidence pack against ISO 27001 A.5.7, A.8.8 and A.8.16, SOC 2 CC7.1 and CC7.2, PCI DSS 6.3.1 and 11.3, NIST 800-53 RA-5 and SI-2, NIST CSF 2.0 ID.RA and DE.CM, NIS2 Article 21, DORA Article 9 and 24. Consumes the live record rather than asking the AppSec team for a fresh narrative each cycle.
Security leadership and audit committee read
The CISO and the audit committee read the recurring posture read for the API estate against the wider programme metrics. AI-generated reports compose the read from the live engagement record so the operational view and the leadership view never disagree on the underlying chronology.
Eight queues the posture engagement runs concurrently
During an active operating cycle the engagement runs eight queues at the same time. Each queue has a named owner, a documented cadence, and an unresolved-item escalation rule so operating drift surfaces before the audit cycle reads against a stale record.
- Estate inventory queue: every API on the documented inventory with an owner, an environment, an exposure class, a verified domain or repository, and a current specification version.
- Shadow and zombie API queue: every endpoint surfaced by the discovery loop that does not match the inventory, with the named owner, the named decision rule, and the documented response window.
- Schema review queue: every API whose specification carries an unreviewed diff against the prior version, with the named reviewer and the named review date.
- Authenticated coverage queue: every API whose authenticated scan coverage carries a gap (missing role tier, missing environment, credential expired, authentication failure) against the documented coverage rule.
- Finding intake queue: every new posture finding produced by authenticated scanning, external scanning, code scanning, manual review, bulk import, bug bounty intake, or internal disclosure intake awaiting calibration, routing, and owner assignment.
- Change-event queue: every event the change-event taxonomy named (new API, exposure change, schema breaking change, authentication mode change, new finding type, regression, coverage drop) with the named owner and the response window.
- Exception review queue: every override on the API estate with a review date inside the next governance cycle, the named expiry, and the renewal rationale captured on the live record rather than reconstructed at audit week.
- Audit evidence read queue: the rolling estate inventory, the schema governance ledger, the per-API coverage record, the finding catalogue, the override register, the change-event log, and the activity log CSV export ready for the GRC team to read against the framework citations.
Seven programme metrics the posture record produces
A single aggregate metric (open finding count or scan pass rate) hides the operating picture the audit chain reads against. The seven metrics below pair against the posture layers so the recurring report surfaces each layer separately and the audit-evidence pack reads against a structured taxonomy rather than a narrative.
Estate inventory currency
The fraction of APIs in the estate inventory with a verified ownership binding, an environment classification, an exposure class, and a current-version specification on the workspace. Programmes operating below ninety percent on inventory currency cannot answer a regulator question about the estate at the moment the question is asked.
Shadow and zombie detection rate
The count of shadow APIs and zombie APIs detected per cycle on the discovery loop, with the time-to-resolution against the named owner. The rate trending toward zero on a mature programme indicates the discovery loop is current; a sustained non-zero rate indicates engineering is shipping APIs the inventory does not see.
Authenticated coverage rate per API
The fraction of APIs in the estate with authenticated scan coverage at the role tiers the threat model requires. Coverage gaps name the APIs where BOLA, BFLA, mass assignment, and excessive data exposure can hide behind login screens the scan never reached.
Specification governance currency
The median age of the held specification per API on the workspace and the fraction of APIs whose held specification carries a named reviewer and a named review date inside the review cadence window appropriate for the API criticality.
Per-API finding catalogue depth and severity mix
The open finding count per API, the calibrated severity mix, the median time-to-fix per severity tier, the SLA breach rate per severity, and the trend over the prior cycles. The metric reads against the per-API record so the programme posture is a queryable summary rather than a single aggregated number.
Exception coverage and override-register currency
The count of active exceptions on the API estate, the median age since last review, the fraction with a named expiry inside the documented horizon, and the count of expired exceptions that reopened the underlying finding rather than persisting silently.
Change-event response window adherence
The fraction of change events (new API, exposure change, schema breaking change, authentication mode change, new finding type, regression, coverage drop) resolved within the documented response window per event class. The metric surfaces operating drift before the audit cycle reads against a stale record.
Five boundaries that keep API posture distinct from adjacent disciplines
API security posture sits between five adjacent disciplines: engagement-level API pentests, the wider ASPM record, the cloud-resource CSPM record, the outside-in EASM record, and runtime inline API protection. The boundaries below keep API posture on its own discipline while naming where it pairs against each adjacent record.
API security testing (engagement-level pentest)
The API security testing workflow runs a single API pentest as a tracked engagement: scope the surface, run authenticated scans, layer manual review, triage findings, deliver the report, retest the fix. This workflow is the wider programme posture cycle the engagement-level pentests feed: estate inventory, schema governance, continuous authenticated coverage, change-event detection, exception lifecycle, and recurring audit-evidence pack. The two pair: each engagement-level pentest contributes findings and evidence to the posture record on the wider programme.
Application security posture management (ASPM)
The ASPM explainer covers the wider application-security posture record the API surface sits inside. ASPM consumes findings from SAST, SCA, DAST, IaC, container scanning, secrets scanning, and manual review across the application portfolio. API posture is the API-specific lane of ASPM, with its own inventory discipline, schema governance, authenticated-coverage rule, change-event taxonomy, and OWASP API Security Top 10 framework citation set.
Cloud security posture management (CSPM)
The CSPM explainer covers the cloud-resource posture record the API hosting infrastructure sits inside. CSPM reads against the IAM, network, storage, compute, and logging configuration on the cloud account. API posture is the application-surface lane: the endpoints the runtime exposes, the schema they advertise, and the authorisation logic the application enforces. Both lanes pair on the same workspace so the consolidated read covers the cloud-resource posture and the application-surface posture together.
External attack surface management (EASM)
The EASM explainer covers the outside-in surface discovery record (domains, subdomains, IP ranges, certificates, public services). API posture is the inside-out application-surface record (the endpoints, the schemas, the authentication modes, the authorisation logic). EASM names the API hosts that are reachable from the public internet; API posture names the endpoints those hosts expose and the security logic the application carries. The two pair: the EASM read feeds the estate inventory and the API posture read feeds the audit-evidence pack.
Inline API protection (WAAP and API gateway)
Inline API protection (WAAP, API gateway, API firewall) sits at runtime in front of the API and blocks or rate-limits malicious traffic in production. SecPortal does not provide an inline runtime protection layer. The API security posture workflow on this page is the pre-production and continuous-assessment record that names the inventory, the schema, the authenticated coverage, the findings, the exception lifecycle, and the audit-evidence pack; a runtime protection layer remains a separate operating discipline the programme runs alongside the posture record.
How API security posture runs on SecPortal
The posture workflow rides on the same feature surfaces the wider security programme uses. The API estate opens as an engagement on the workspace, every API in the inventory binds to a verified domain and a connected repository, the authenticated and external scans run on a documented cadence with credentials held in the encrypted vault, the schema governance record sits in document management with version history, findings land on the engagement with the OWASP API Security Top 10 mapping and the calibrated CVSS, the override register captures exception decisions with the eight-field chain, the change-event queue surfaces operating drift, the activity log holds every state change, and AI-generated reports compose the recurring posture read for AppSec leadership, the CISO, the audit committee, and the GRC team.
Estate as an engagement record
The API estate opens on the engagement record with the named programme owner, the inventory list of APIs in scope, the named owner per API, the threat-model reference, the documented coverage rule, and the recurring posture cadence. Every cycle reads against the same engagement so the chronology stays continuous between operating windows.
Authenticated scanning behind credentials
Authenticated scanning reaches the login-protected REST, GraphQL, and form-protected endpoints across each API in the inventory using credentials stored in the encrypted credential vault scoped to the verified domain. The scan output binds back to the API record on the engagement.
External scanning for exposure
External scanning reads the public surface of the verified domains hosting the API estate. SSL and TLS posture, HTTP security headers, DNS exposure, port reachability, subdomain enumeration, and technology fingerprinting feed the exposure layer on every API in the inventory.
Code scanning for repository signal
Code scanning runs static analysis and dependency analysis on the repositories that ship each API through repository connections on GitHub, GitLab, and Bitbucket. The repository signal binds back to the same API in the inventory the authenticated scan reads against.
Findings with API and OWASP mapping
Findings management holds every posture finding with the affected API reference, the OWASP API Security Top 10 mapping, the calibrated CVSS 3.1 vector, the routing rule, the SLA tier, the named owner, and the framework citation set. Findings from every intake source land on the same record.
Documents for specs and policy
Document management holds the current and prior OpenAPI, GraphQL SDL, gRPC proto, or AsyncAPI specification per API with version history, the threat-model artefacts, the named reviewer trail, and the framework citation evidence the assessor reads against.
Overrides for exception lifecycle
Finding overrides capture the eight-field exception decisions (linked finding, severity, compensating controls, residual likelihood, residual impact, business rationale, expiry, review cadence) so the assessor reads against a live lifecycle rather than a static spreadsheet.
Bulk import for third-party signal
Bulk finding import accepts third-party pentest exports, vendor assessment output, partner penetration test deliverables, and historical scanner output (.nessus, Burp XML, CSV with column mapping) so external signal joins the posture record with provenance preserved.
Retesting closes the loop
Retesting workflows pair the verification artefact to the original finding and move state on the same record. The aging clock keeps running on the original capture date so the SLA reads against when the programme received the finding, not when the retest fired.
Team RBAC for accountable roles
Team management scopes engagement access to the named programme owner, the named API owners, the scan operators, and the GRC readers with multi-factor authentication enforced on every account. Access is by named role rather than blanket workspace permissions.
Notifications keep the loop moving
Notifications push change-event signals (new API, schema diff, coverage drop, finding regression, exception expiry) to the named owners on the documented cadence so operating drift does not sit on the engagement waiting for someone to open the queue view.
AI posture and audit reads
AI report generation composes the recurring posture read for AppSec leadership, the CISO briefing, the audit-committee read-out, and the GRC audit-evidence pack from the live engagement record. The operational view and the leadership view never disagree on the underlying chronology because they read the same record.
Continuous monitoring cadence
Continuous monitoring schedules the recurring authenticated and external scans on the cadence the API criticality requires (daily, weekly, biweekly, or monthly) so the posture record reads against a documented operating clock rather than ad-hoc runs.
Activity log evidence chain
The activity log captures every state change on the API estate (inventory add, exposure change, schema upload, scan run, finding intake, override decision, retest result, exception expiry) with timestamp and user attribution. The CSV export is the evidence chain for ISO 27001, SOC 2, NIST 800-53, PCI DSS, NIS2, and DORA fieldwork.
Seven framework reads the posture workflow produces evidence for
The posture workflow produces structured evidence for the framework citations the GRC team carries through audit fieldwork. The reads below are the ones that surface against a defensible posture record; narrative notes pulled from a scanner export do not produce the same answer when an assessor asks how the programme operated the API security record over the period under review.
| Framework citation | What the posture workflow reads as |
|---|---|
| ISO 27001 A.5.7 (threat intelligence), A.8.8 (technical vulnerability management), A.8.16 (monitoring activities) | The API security posture engagement holds the estate inventory, the schema governance record, the authenticated coverage rate, the finding catalogue, the exception register, the change-event queue, and the activity log CSV export. The assessor reads against the live record across threat intelligence input, technical vulnerability handling on the API estate, and monitoring activities on the application surface. |
| SOC 2 CC7.1 (system monitoring) and CC7.2 (anomaly detection and incident response) | The posture workflow contributes to CC7.1 by maintaining the structured monitoring record across estate inventory, authenticated coverage, finding catalogue, and change events; the workflow contributes to CC7.2 through the change-event queue that surfaces anomalies (shadow API, schema breaking change, coverage drop) onto a named-owner queue inside the documented response window. |
| PCI DSS v4.0 Req 6 (secure development) and Req 11.3 (vulnerability testing) | The merchant operates the structured record of API security testing against the cardholder data environment, the recurring authenticated and external scans, the manual review findings, the override register with the eight-field decision chain, and the activity log evidence the assessor reads alongside the internal scan record. |
| NIST 800-53 Rev 5 RA-5 (vulnerability monitoring) and SI-2 (flaw remediation) | The posture workflow produces the structured evidence that the organisation runs continuous vulnerability monitoring against the API estate (authenticated scans on a documented cadence, change-event detection across cycles) and remediates the resulting flaws against documented severity tiers and timeline standards. |
| NIST CSF 2.0 ID.RA (risk assessment), DE.CM (continuous monitoring), RS.AN (analysis) | The workflow contributes to ID.RA-1 through the estate inventory and the per-API risk record, to DE.CM-8 through the continuous authenticated and external scanning, and to RS.AN-5 through the change-event response taxonomy. |
| NIS2 Article 21 (cybersecurity risk-management measures) | The posture engagement is the documented record of how the organisation identifies, monitors, and remediates security risk on the API estate against the in-scope assets, with named API owners, reconstructable decisions, and a queryable audit evidence pack. |
| DORA Article 9 (ICT risk management) and Article 24 (threat-led penetration testing) | The posture workflow contributes to Article 9 through the recurring posture record on the API estate and to Article 24 through the engagement-record evidence of threat-led testing on the in-scope APIs. The held record reads as the reproducible evidence the assessor consumes. |
| OWASP API Security Top 10 (current edition) | Every finding on the API posture record carries the OWASP API Security Top 10 mapping where applicable (BOLA, broken authentication, BOPLA, unrestricted resource consumption, BFLA, unrestricted access to sensitive business flows, server-side request forgery, security misconfiguration, improper inventory management, unsafe consumption of APIs). The framework citation field is a queryable taxonomy so the recurring report reads against the framework rather than as free-text commentary. |
Where API security posture sits in the wider programme
Run API security posture as one of several posture lanes that feed the consolidated security operating record. Adjacent disciplines that pair with the API posture lane include the engagement-level API security testing workflow for time-boxed pentests on individual APIs, the cloud security assessment workflow for the cloud-resource posture the APIs run on, the CSPM finding remediation workflow for the cloud-configuration findings that surface alongside API findings, the DevSecOps scanning workflow for the SAST and SCA signal feeding the API repositories, the security finding ownership and routing workflow for the routing-rule that places API findings on the named owner, and the vulnerability acceptance and exception management workflow for the override register that holds the exception lifecycle on the API estate. Background reading on the wider posture frame is in the application security posture management (ASPM) explainer, the cloud security posture management (CSPM) explainer, and the API security testing checklist.
How it works in SecPortal
A streamlined workflow from start to finish.
Open the API estate as an engagement and bind every API to a named owner
Open the API security posture programme as a dedicated engagement on the workspace. Capture the inventory of REST, GraphQL, gRPC behind HTTP, and webhook APIs in scope. For each API, record the named owner (product or engineering role), the environment tier (production, staging, development), the exposure class (public, partner, internal), the verified domain hosting the surface, and the connected repository that ships the code. The inventory is a queryable record, not a spreadsheet that nobody updates.
Hold the schema or specification per API under named-author governance
Capture the current OpenAPI, GraphQL SDL, gRPC proto, or AsyncAPI specification per API in document management with the named author, the named reviewer, the version stamp, and the review date. On every cycle, the held spec is compared against the prior version and unreviewed diffs land on the schema review queue with a named reviewer and a documented review date. The threat-model reference attaches to the spec so the review reads against the right shape, not the shape from nine months ago.
Schedule authenticated and external scans on a cadence per API criticality
Continuous monitoring schedules authenticated scans against each API at the role tiers the threat model requires, using credentials held in the encrypted credential vault scoped to the verified domain. External scanning reads the public exposure of the hosting domains (SSL, headers, DNS, port, subdomain, technology fingerprint). Code scanning runs static analysis and dependency analysis on the connected repositories. Each scan output binds back to the API in the inventory so the per-API coverage record is queryable rather than reconstructed.
Consolidate posture findings from every intake source onto one record
Findings from authenticated scanning, external scanning, code scanning, manual review on the engagement, bulk import of third-party assessment output (.nessus, Burp XML, CSV), bug bounty intake, and internal disclosure intake all land on the same engagement with provenance preserved. Each finding carries the affected API reference, the OWASP API Security Top 10 mapping, the calibrated CVSS 3.1 vector, the routing rule, the SLA tier, the named owner, and the framework citation set. The consolidated read is queryable, not narrative.
Operate the change-event queue across seven event classes
Change-event detection runs on every cycle and surfaces seven event classes onto the engagement queue: new API added, exposure class changed, schema breaking change, authentication mode changed, new finding type observed, finding resolved or regressed, coverage dropped. Each event class carries a named owner and a documented response window. The change-event queue is the operating signal between audit cycles rather than a slide assembled at quarter-end.
Hold the exception lifecycle on the override register with the eight-field decision chain
Posture findings the programme accepts as risk, suppresses, defers, or compensates against another control land on the override register with the eight-field decision chain (linked finding, severity, compensating controls, residual likelihood, residual impact, business rationale, expiry, review cadence). Active overrides carry a named expiry; expired overrides reopen the underlying finding rather than persisting silently. The override register is what the assessor reads when asking how the programme handled posture findings it did not fix immediately.
Retest fixes against the original finding and verify state on the same record
When engineering ships a fix, the retest workflow pairs the verification artefact (request and response, regression test, screenshot, payload) to the original finding and moves the state to resolved or verified on the same record. The aging clock keeps running on the original capture date so the SLA reads against when the programme received the finding, not when the retest fired. The retest record is the basis for confirming closure on the change-event queue and for the recurring posture read.
Produce the recurring posture report and the audit evidence pack from the live record
On the documented cadence (monthly, quarterly, or per major release), AI-generated reports compose the posture read for AppSec leadership, the CISO briefing, the audit-committee read-out, and the GRC audit-evidence pack from the live engagement record. The activity log CSV export carries every state change (inventory add, exposure change, schema upload, scan run, finding intake, override decision, retest result, exception expiry) and is the evidence chain for ISO 27001, SOC 2, PCI DSS, NIST 800-53, NIST CSF 2.0, NIS2, and DORA fieldwork.
Features that power this workflow
Orchestrate every security engagement from start to finish
Vulnerability management software that tracks every finding
Test web apps behind the login
Vulnerability scanning tools that map your attack surface
Find vulnerabilities before they ship
Encrypted credential storage for authenticated scans
Repository connections for SAST and SCA
Verify ownership before any scan runs
Monitor continuously catch regressions early
Document management for every security engagement
Finding overrides that survive every scan cycle
Bulk finding import bring your scanner data with you
Verify fixes and track reopens on the same finding record
Every action recorded across the workspace
Compliance tracking without a full GRC platform
AI-powered reports in seconds, not days
Collaborate across your entire team
Multi-factor authentication on every workspace
Notifications and alerts for the people who carry the work
Run API security posture as a programme record, not a quarterly slide
Estate inventory, schema governance, authenticated coverage, consolidated findings, change-event detection, exception lifecycle, and audit-evidence pack on one engagement. Free plan available.
No credit card required. Free plan available forever.