What is scanner output attestation in plain language?

Scanner output attestation is the discipline that makes the scan execution and the findings it produced verifiable as unaltered after the fact. The evidence chain page covers structural layers (scan execution to finding to retest). Attestation sits on top of that chain and answers a different question: can the audit reader, the regulator, or a downstream consumer verify that the scan output recorded today is the same scan output the scanner emitted at execution time. The answer rests on three artefacts. A canonical record of what the scanner emitted at the moment of execution (the raw evidence rows, the module identifier, the configuration the scan ran under, the started_at and completed_at timestamps, the actor reference). A tamper-evidence anchor that binds the canonical record to its contents (a content hash, an integrity reference recorded in the activity log at write time, or an external attestation token where the workspace operates with one). A verification procedure that reproduces the anchor from the stored record and confirms the bytes match.

How is attestation different from the scan-to-finding evidence chain?

The two pages cover sequential layers of one chain. The evidence chain guide answers what was connected to what (scan execution to finding to retest to closure). Attestation answers whether the connections themselves can be proved to be unchanged. The evidence chain guide is satisfied when every closure traces in one record back to its scan execution. Attestation is satisfied when an independent reader can verify that the record itself has not been silently rewritten between the scan and the audit. A programme that operates the evidence chain without attestation passes operational use and fails high-trust audit where the auditor asks "how do you know this record has not been edited since the scan ran". A programme that operates both passes the audit conversation by reading the attestation record against the canonical scan output.

How is attestation different from evidence retention and governance?

Retention answers how long the evidence stays available and under what governance disposal happens. Attestation answers whether the retained evidence is provably unaltered while it is being retained. Retention by itself can hold a record that has been silently edited; attestation makes the silent edit visible. The two pair: retention sets the window the attestation has to hold across, and attestation makes the retained record defensible at the end of that window. ISO 27001 A.5.33 and DORA Article 8 read retention through the policy of how long the record is held; attestation reads the same record through whether the integrity proof still verifies when the record is recalled for audit.

What are the typical failure modes that break chain of custody?

Six failure modes recur across enterprise programmes. Scanner UIs that allow the operator to edit finding evidence or scan parameters after the fact without recording the edit alongside the original, so the audit reads the edited version as if it were the original. Findings re-keyed across tools (scanner to ticketing to spreadsheet to report) where each handoff drops the source-execution reference, so the chain ends at the last hop. Retention windows shorter than the audit-recall window, so the scan execution evidence is disposed before the auditor asks for it. Suppression or severity-override events recorded in chat rather than against the finding record, so the recall reads the closed finding without the rationale that closed it. Imported third-party scanner outputs landing without the source-execution reference, so the chain originates inside the platform with no upstream proof. Activity log retention bands shorter than the engagement evidence retention, so the action history is rolled off the platform before the engagement record is closed.

How do imported third-party scanner outputs carry attestation through to closure?

Imported findings from Nessus, Burp Suite, CSV exports of CSPM tools, or manual entry from consultancy deliverables enter the chain at the import event. The import workflow records the source format, the upload actor, the upload timestamp, and the source-emitted scan execution reference where the source data exposes it. The original third-party artefact (the .nessus file, the Burp Suite JSON export, the CSV) should be retained alongside the import event so the chain originates at the vendor source and continues through the import event into the platform records. Programmes that strip the original artefact at import lose the attestation surface upstream of the platform; the platform record reads as if it were the origin and the audit cannot reconcile the imported findings against the vendor scan. The defensible pattern is the import event holding the source-emitted reference, the original artefact archived to durable storage under the workspace governance, and the per-finding evidence section carrying both the platform identity and the source-emitted identity so the chain reads end to end.

How do continuous monitoring schedules interact with the attestation chain?

Continuous monitoring runs scans on a schedule (daily, weekly, biweekly, monthly per asset class). Each scheduled execution produces its own scan execution record with the schedule reference attached, and each execution should produce its own attestation anchor at write time. The chain across many cycles reads as a sequence of attested scan executions, each one verifiable independently, with the recurring detection identity inheriting prior workspace decisions through the per-target match key. Programmes that consolidate many cycles into a single attestation record (one anchor across a quarter of scans) lose the per-cycle verifiability that lets the audit reproduce any single execution. The defensible pattern is one attestation anchor per scan execution, with the activity log recording the link between the schedule reference and the executed scan so the cycle history reads as a chain of attested events rather than a single rollup.

How does SecPortal support scanner output attestation?

SecPortal records each scan execution against the engagement and the verified domain or connected repository, with the actor reference, the modules executed, the credential reference for authenticated scans, the rule pack version for code scans, the schedule reference for continuous monitoring runs, and the started_at and completed_at timestamps. Each scanner-emitted finding writes against the workspace with the source class, the source-emitted reference where applicable, the canonical asset reference, the finding template identifier, the source severity, and the workspace severity. The activity log captures every state transition (creation, status change, assignment, suppression, severity override, retest, closure, disposal) with the named actor, the timestamp, and the entity reference; the activity log carries 30, 90, or 365 day retention by plan tier and supports CSV export so the chain can be packaged at any time inside the retention window. Bulk finding imports record the source format, the upload actor, and the source-emitted reference per row. Finding overrides are keyed to the workspace, the template, and the target so per-target decisions stay per-target and inherit on recurring detections. Honest scope: SecPortal does not maintain a packaged digital signing service for scan output, does not maintain an HSM-backed signing infrastructure, does not maintain an automated notarisation service, does not push attestation records to a customer-controlled append-only log or transparency log through packaged connectors, and does not synchronously create attestation tickets in Jira, ServiceNow, Slack, PagerDuty, or Opsgenie. The attestation chain is operated as a workspace discipline against the structured fields and the activity log the platform exposes; the recompute procedure and the external anchoring choice are workspace decisions rather than platform automations.

How do compliance frameworks read the attestation chain?

Auditors read attestation through three artefact classes. The attestation policy (which records are anchored, which algorithm is used, how often the recompute procedure is executed, what disposal evidence looks like) is the policy evidence read at audit kickoff. The per-execution attestation record (the activity log entry that binds the scan execution to the content anchor at write time) is the operating evidence sampled at fieldwork. The verification trace (the documented recompute against the canonical record at recall time) is the integrity evidence read to defend the chain. ISO 27001 A.5.33 protection of records and A.8.15 logging read the attestation policy and the activity log retention. SOC 2 CC4.1 monitoring controls and CC7.1 detection read the per-execution attestation record. SOC 2 CC8.1 change management reads attestation across credential rotation and rule pack updates. PCI DSS v4.0 6.3.3, 10.5.1 audit trail protection, and 11.3 read attestation through the scan record retention and the audit trail integrity requirements. NIST SP 800-53 Rev. 5 AU-2 event logging, AU-9 protection of audit information, AU-12 audit record generation, and SI-7 software firmware information integrity read attestation through the audit record protection and integrity verification chain. NIST CSF 2.0 PR.DS protect data security and DE.AE detect anomalies and events read the attestation surface as the integrity layer that supports detection evidence. DORA Article 8 ICT asset identification and Article 9 protection and prevention read attestation as the integrity proof for the ICT incident record. A scanner programme that cannot answer how the scan output is anchored, how the anchor is verified, and when the anchor was last recomputed fails every one of these readings.

← Back to Scanner Information

Scanner guide15 min read

Scanner Output Attestation and Chain of Custody

A clean evidence chain says what was connected to what. Attestation says the connections themselves have not been silently rewritten between the scan and the audit. The two pair: the chain proves provenance, the attestation proves integrity. High-trust audits ask both questions. Regulated industries (finance, healthcare, federal, critical infrastructure) ask the integrity question at every fieldwork conversation. Enterprise procurement increasingly asks it during vendor reviews. This guide covers what attestation actually is at the scanner output layer, the canonical record fields a defensible chain needs to hold, the six failure modes that turn a working chain into an undefendable one, how authenticated scanning and continuous monitoring interact with the attestation surface, and how SecPortal supports the discipline without claiming a packaged signing service the platform does not run.

The page sits next to the scanner evidence chain guide (structural layers from scan to finding to closure) and the scan evidence retention and governance guide (how long the record is held and under what governance disposal happens). Attestation is the integrity layer that sits on top of both.

What attestation is at the scanner output layer

Scanner output attestation is the discipline that makes a recorded scan execution verifiable as unchanged after the fact. The audit reader, the regulator, or a downstream evidence consumer can take the stored record, follow the documented recompute procedure, and confirm the bytes are the same bytes the scanner emitted at execution time. The discipline rests on three artefacts that have to exist together.

A canonical record of what the scanner emitted

The raw evidence rows the scanner produced (HTTP request/response pair for web checks, SAST rule match with file path and line number for code checks, certificate observation for TLS checks, DNS response for domain enumeration checks). The module identifier and version. The configuration the scan ran under (credential reference for authenticated scans, rule pack version for code scans, module list for external scans, schedule reference for continuous monitoring runs). The actor reference (named workspace member for manual scans, schedule reference for automated runs, import event reference for bulk imports). The started_at and completed_at timestamps. Normalised to a stable serialisation so the same record produces the same bytes across re-reads.

A tamper-evidence anchor that binds the record to its contents

The content hash of the canonical payload computed at write time. Recorded in the activity log alongside the actor and the timestamp at the moment of write. The hashing algorithm documented as part of the attestation policy (SHA-256 is the routine default; programmes operating at higher assurance levels often double-anchor against SHA-512 or pair the in-platform anchor with an external transparency-log entry). The anchor is recorded inside the platform retention window so it stays adjacent to the canonical record it binds.

A verification procedure that reproduces the anchor

The documented steps to recompute the content anchor from the canonical record at recall time and confirm the recomputed value matches the recorded anchor. Without the procedure, the anchor is a string in a log table; with the procedure, the anchor is an integrity proof a third party can verify. The procedure has to be reproducible without the original operator present (recompute steps written down, recompute inputs available in the retained record, recompute outputs comparable to the stored anchor).

A scanner output programme that holds the canonical record without the anchor passes operational use and fails the audit conversation about integrity. A programme that holds the anchor without the canonical record cannot recompute and the anchor is unverifiable. A programme that holds both without a documented verification procedure has produced an artefact no auditor can read. The three artefacts pair.

How attestation sits next to the evidence chain and retention

Three scanner-info disciplines compose into one defensible record. The evidence chain answers what was connected to what. The retention layer answers how long the record stays available and under what governance disposal happens. Attestation answers whether the retained, connected record has been silently rewritten in between.

Layer	Question answered	Failure if missing
Evidence chain	Scan execution to finding to retest to closure traced in one record.	Closure decisions cannot be reproduced from structured fields alone.
Retention	How long the chain stays available and under what governance disposal happens.	Audit recall fails because evidence has rolled off before the auditor asks for it.
Attestation	Whether the retained chain has been silently rewritten between scan and audit.	The record reads as if it were the original even when it has been edited; the integrity question cannot be answered.

High-trust audits ask all three. Routine enterprise audits often accept the first two and ask the third opportunistically. Regulated environments (FedRAMP, DORA-scoped ICT, healthcare PHI, payment-card environments, critical infrastructure) ask the integrity question every time. The discipline pays back when the auditor asks the question that the chain alone cannot answer; building the attestation surface ahead of the question is cheaper than reconstructing it under fieldwork pressure.

Six failure modes that break chain of custody

Custody breaks quietly. The record reads as defensible at the leadership view and as undefendable at the audit table. The six failure modes below cover most of what surfaces at fieldwork as an integrity question the team cannot answer.

Silent in-place edits without an event record

A scanner UI or a workflow tool lets an operator edit finding evidence, change the affected asset, or rewrite the scan parameters after the scan has run, and the edit overwrites the original without recording the change. The audit reads the edited record as if it were the scanner-emitted record. The right pattern is every edit landing in the activity log with the named actor, the timestamp, and the before-and-after values, while the canonical scan output stays bound to the scan execution and is never silently overwritten by a downstream workflow edit.

Source reference dropped at handoff

Findings re-keyed across tools (scanner to ticketing to spreadsheet to report) where each handoff drops the source-execution reference. The chain ends at the last hop and the audit reader cannot walk back to the scan that originated the finding. The right pattern is the per-finding record carrying the source class, the source-emitted reference, and the canonical workspace identity end to end so the chain stays intact through every downstream consumer.

Retention windows shorter than the audit recall window

The activity log retention rolls off after 30 days while the engagement evidence stays available for a year. The auditor recalls the engagement and the action history that produced its closures is gone. The right pattern is the activity log retention chosen against the audit recall window the workspace operates under, with the retention band documented in the attestation policy and the plan-tier choice made deliberately rather than as an operational accident.

Rationale held in chat instead of on the record

Suppression, severity override, or closure rationale is captured in chat threads and the per-finding record carries only the outcome. The recall reads the closed finding without the rationale that closed it. The right pattern is every workspace decision landing against the finding record with the rationale text visible to the audit reader, while chat threads stay as the working conversation that produced the decision rather than as the system of record.

Imported third-party output landing without source reference

A Nessus or Burp Suite export imports as platform-native findings without the source scan execution reference, the original artefact, or the upload event being archived. The chain originates inside the platform with no upstream proof. The right pattern is the import workflow recording the source format, the upload actor, the source-emitted reference, and an archive of the original artefact so the chain reads end to end from the vendor scan into the platform record.

Anchor recorded without a recompute procedure

The platform records a content hash on each scan output but the verification procedure is undocumented. The auditor asks how the anchor verifies and the programme cannot demonstrate the recompute. The anchor is a string in a log table rather than an integrity proof. The right pattern is the attestation policy carrying the recompute procedure with named inputs, named outputs, and a worked example that the auditor can reproduce against any stored execution.

What an audit-grade attestation record actually contains

Eight fields cover most audit conversations. The record holds enough to recompute and verify any single scan execution against its anchor without depending on personnel memory or external context.

Field	What it holds
Scan execution reference	Workspace, target, modules executed, started_at, completed_at, actor, source class (external, authenticated, code, manual, imported).
Canonical scan output payload	The raw evidence rows the scanner emitted, serialised to a stable encoding so re-reads produce identical bytes.
Content anchor	Hash of the canonical payload computed at write time, with the hashing algorithm documented in the attestation policy.
Scan configuration	Credential reference for authenticated scans, rule pack version for code scans, module list for external scans, schedule reference for continuous monitoring runs.
Actor reference	Named workspace member for manual scans, schedule reference for automated runs, import event reference for bulk imports.
Retention band	Plan tier under which the record is being retained (30, 90, or 365 days for the activity log; engagement retention for the finding record).
Disposal record	Timestamp and actor for any deletion or supersede event, recorded in the activity log before the data is removed.
Recompute procedure	Documented steps to recompute the content anchor from the canonical payload and confirm the recomputed value matches the stored anchor.

The eight fields do not have to live in eight separate tables. They have to live on structured records the workspace can recall, recompute, and present in one packet at audit fieldwork. Programmes that hold the fields scattered across scanner UIs, ticketing systems, shared drives, and chat threads cannot package the chain inside the audit window without manual reconstruction; programmes that consolidate the fields into a single workspace with retention and activity logging hold the chain on the system of record.

Authenticated scanning and the credential lifecycle

Authenticated scanning adds credential context to the chain. The scan execution carries the credential reference for the lifetime of the scan, and the credential reference is itself a versioned artefact with a rotation history. The attestation chain has to bind each finding to the credential reference active at the scan execution that produced it, and the credential lifecycle has to read against the scan execution timeline so the audit reads authentication state coherently across rotations.

The mechanism splits into three rules. The scan execution carries an immutable credential reference for the lifetime of the scan; once the scan completes, the credential reference on the execution does not change even if the underlying credential rotates. The activity log records every credential lifecycle event (creation, update, rotation, revocation, deletion) with the named actor, the timestamp, and the credential reference. The credential record itself carries its own version coordinate so the chain stays coherent across rotations and the authentication state under each historical scan can be reconstructed without inferring it from external sources.

For the operational lifecycle of credentials at scanner-side discipline, the scanner credential rotation and lifecycle guide covers the rotation pattern that pairs to the attestation chain on the scan execution side. The encrypted credential storage feature covers the AES-256-GCM-at-rest primitive the credential reference resolves to.

Continuous monitoring schedules and per-cycle attestation

Continuous monitoring runs scans on a schedule (daily, weekly, biweekly, monthly per asset class). Each scheduled execution lands as its own scan execution record with the schedule reference attached, and each execution should produce its own attestation anchor at write time. The chain across many cycles reads as a sequence of attested scan executions, each one verifiable independently.

Programmes that consolidate many cycles into a single attestation record lose the per-cycle verifiability the audit reader walks to reproduce any single execution. One anchor across a quarter of scans cannot defend any one cycle if the auditor picks a date and asks to recompute that cycle alone. The defensible pattern is one attestation anchor per scan execution, recorded in the activity log at write time against the schedule reference, with the cycle history reading as a chain of attested events rather than a rollup.

For the recurring-detection identity that lets per-target findings inherit prior workspace decisions across cycles without breaking the attestation chain, the scan baseline and trend comparison guide covers the recurring detection mechanics each cycle inherits from. For the schedule-level cadence discipline that the audit reads against, the scan scheduling and baseline cadence guide covers the cadence pattern that pairs to the per-cycle attestation discipline.

Imported third-party scanner output

Imported findings from Nessus, Burp Suite, CSV exports of CSPM tools, container scanner exports, or manual entry from consultancy deliverables enter the chain at the import event. The chain has to originate at the vendor source and continue through the import event into the platform records, not start inside the platform with the import event treated as the origin.

The import event records the source format and the upload actor

Every bulk import lands as an activity-log event with the source format (Nessus, Burp Suite, CSV, vendor name), the upload actor, the upload timestamp, and the count of rows processed. The event reference attaches to each per-finding record produced by the import so the chain from per-finding back to import event is one foreign-key hop.

The original artefact archives to durable storage

The .nessus file, the Burp Suite JSON export, the CSV upload, or the consultancy deliverable archives against the engagement under the workspace governance. The archive is the upstream proof the platform chain originates from. Programmes that strip the artefact at import lose the attestation surface upstream of the platform; the platform record reads as the origin and the audit cannot reconcile the imported findings against the vendor scan.

Per-finding evidence carries both identities

Each imported per-finding record carries the platform identity (workspace template, canonical asset reference, source class) and the source-emitted identity (vendor plugin id, vendor finding id, vendor severity). The chain reads end to end without dropping either identity. The scanner finding tag and label taxonomy guide covers the translation between source-emitted vocabulary and workspace controlled vocabulary that preserves both layers.

Importing third-party scanner output guide pairs to attestation

The importing third-party scanner results guide covers the import mechanics. The attestation discipline this guide covers sits on top of those mechanics; the import event becomes the platform-side anchor that binds the per-finding record to the archived vendor artefact.

Severity calibration, finding overrides, and the source signal

Severity calibration and finding overrides are workspace decisions on top of the scanner-emitted output. The attestation chain has to preserve both the source-emitted scanner severity and the calibrated workspace severity so the divergence is visible. Programmes that overwrite the scanner-emitted severity with the calibrated severity lose the source signal the audit reads to reproduce the rationale for the calibrated band.

The clean pattern is the per-finding record carrying source severity and workspace severity as separate fields, the override event landing in the activity log with the named actor and rationale, and the audit reader reconstructing the rationale by reading the activity log against the per-finding record. Cluster-level severity calibration follows the same pattern: the cluster severity is a deliberate workspace decision recorded in the activity log, distinct from per-target severity and from source-emitted severity.

For the severity normalisation discipline that produces the workspace severity from heterogeneous source signals, the scanner output severity normalisation guide covers the calibration pattern that pairs to the source-preserving attestation discipline. For the per-target suppression mechanism that travels with the recurring detection, the scanner finding suppression and deferral controls guide covers the suppression event chain the audit reader walks.

Internal attestation vs external anchoring

Internal attestation records the content anchor in the activity log at write time inside the platform. The recompute procedure verifies the chain against the platform retention. This is the right pattern for routine operations and most enterprise audits, where the audit reader trusts the platform retention and verifies integrity through the recompute procedure inside the workspace.

External anchoring writes the content anchor out to a customer-controlled append-only log, a transparency log, or a regulator-readable artefact store at customer-controlled intervals. The integrity proof lives separately from the platform that holds the data, so a compromise of the platform after the scan cannot rewrite the audit. This is the right pattern when the audit reader requires proof of non-repudiation against the platform itself, which is typical at federal assurance levels, financial market infrastructure, and critical infrastructure environments.

The two compose. Internal attestation produces the per-execution anchor that the recompute procedure verifies; external anchoring writes the per-execution anchor out to an independent record on a defined cadence. Programmes that operate at the highest assurance level usually combine both; programmes that operate at routine enterprise assurance run on internal attestation alone with a documented recompute procedure and a defined retention window.

How SecPortal supports the attestation chain

SecPortal stores each scan execution and finding against structured fields the attestation chain sits on top of. The mechanism is consistent across external, authenticated, code, manual, and imported sources; the register entry and the source class differ by surface.

Scan execution as the canonical record anchor

Each scan execution records the workspace, the target, the modules executed, the credential reference for authenticated scans, the rule pack version for code scans, the schedule reference for continuous monitoring runs, the actor, and the started_at and completed_at timestamps. The execution reference attaches to every finding the scan emits so the chain from per-finding back to scan execution is one foreign-key hop. The authenticated scanning feature and the external scanning feature cover the scan execution surfaces.

Activity log as the tamper-evident event chain

Every workspace decision against the per-finding record (creation, status change, assignment, suppression, severity override, retest, closure, disposal) lands in the activity log with the named actor, the timestamp, and the entity reference. The activity log carries 30, 90, or 365 day retention by plan tier and supports CSV export so the chain can be packaged at any time inside the retention window. The activity log feature covers the audit trail surface.

Bulk import workflow preserves the source identity

Bulk finding imports (Nessus, Burp Suite, CSV exports of other tools) record the source format, the upload actor, the upload timestamp, and the source-emitted identity per row. The per-finding record carries both the platform identity and the source-emitted identity so the chain reads end to end from the vendor scan into the workspace. The bulk finding import feature covers the import surface.

Per-target finding overrides stay per-target

Finding overrides (false positive, accepted risk, severity adjustment, category revision) are keyed to the workspace, the template, and the target so per-target decisions stay per-target and inherit on recurring detections without propagating to siblings. The override event lands in the activity log with the rationale. The finding overrides feature covers the override mechanism.

Engagement record holds the retention boundary

Findings, scan executions, and the per-engagement activity stream sit under the engagement record, which defines the retention boundary for the audit recall window. The retention band is chosen against the workspace plan tier and the audit recall window the workspace operates under. The engagement management feature covers the engagement record surface.

Honest scope: SecPortal does not maintain a packaged digital signing service for scan output. SecPortal does not maintain an HSM-backed signing infrastructure. SecPortal does not maintain an automated notarisation service. SecPortal does not push attestation records to a customer-controlled append-only log or transparency log through packaged connectors. SecPortal does not synchronously create attestation tickets in Jira, ServiceNow, Slack, PagerDuty, or Opsgenie through packaged integrations. SecPortal does not run an autonomous attestation engine that verifies integrity without human review. The attestation chain is operated as a workspace discipline against the structured fields and the activity log the platform exposes; the content-anchor algorithm, the recompute procedure, the external-anchoring choice, and the disposal evidence pattern are workspace decisions rather than platform automations.

How compliance frameworks read the attestation chain

Auditors read attestation through three artefact classes: the attestation policy (which records are anchored, which algorithm is used, how often the recompute procedure is executed, what disposal evidence looks like), the per-execution attestation record (the activity log entry that binds the scan execution to the content anchor at write time), and the verification trace (the documented recompute against the canonical record at recall time).

Framework	Where it reads the attestation chain
ISO 27001:2022	Annex A 5.33 protection of records and A.8.15 logging read the attestation policy and the activity log retention as the integrity layer of the records inventory.
SOC 2	CC4.1 monitoring controls and CC7.1 detection read the per-execution attestation record. CC8.1 change management reads attestation across credential rotation and rule pack updates.
PCI DSS v4.0	6.3.3 ranking and risk-based remediation; 10.5.1 audit trail protection; 11.3 internal and external scan retention. The audit trail integrity requirement reads the attestation policy directly.
NIST SP 800-53 Rev. 5	AU-2 event logging; AU-9 protection of audit information (the named control that requires audit record integrity); AU-12 audit record generation; SI-7 software firmware information integrity. The attestation chain maps directly to AU-9.
NIST CSF 2.0	PR.DS protect data security and DE.AE detect anomalies and events read the attestation surface as the integrity layer that supports detection evidence.
CIS Controls v8.1	Control 8 audit log management reads the attestation policy and the activity log retention; Control 7 continuous vulnerability management reads the per-execution attestation record.
DORA	Article 8 ICT asset identification and Article 9 protection and prevention read attestation as the integrity proof for the ICT incident record. Article 12 reads the policy and recompute procedure.
FedRAMP	SI-7 software firmware information integrity and AU-9 audit information protection read external anchoring or equivalent integrity controls; routine FedRAMP Moderate engagements often expect the recompute procedure to be exercised on a defined cadence.

A scanner programme that cannot answer how the scan output is anchored, how the anchor is verified, and when the anchor was last recomputed fails every one of these readings at the integrity question. The discipline is the audit-defensible layer that sits on top of the evidence chain and the retention boundary; building it ahead of the question is materially cheaper than reconstructing it under fieldwork pressure.

An operational checklist

When designing the attestation policy

The policy names which records are anchored (scan executions, per-finding evidence, activity log entries, disposal events).
The policy names the hashing algorithm and a documented recompute procedure with named inputs and outputs.
The policy names the retention bands for each record class against the audit recall window the workspace operates under.
The policy names the external anchoring choice if the workspace operates at higher assurance levels (federal, financial market infrastructure, critical infrastructure).

At scan execution

Each scan execution records the workspace, the target, the modules, the credential reference for authenticated scans, the rule pack version for code scans, the schedule reference for scheduled runs, the actor, and the started_at and completed_at timestamps.
The canonical scan output payload is normalised to a stable serialisation so recomputed anchors match across re-reads.
The content anchor is recorded in the activity log at write time alongside the actor and the timestamp.
Each scheduled cycle produces its own attestation anchor rather than consolidating cycles into one rolled-up record.

At workspace decisions on findings

Severity calibration preserves the source-emitted severity alongside the workspace severity; the override event lands in the activity log with the rationale.
Suppression and exception decisions land against the finding record with the rationale visible to the audit reader rather than in chat threads.
Per-target overrides stay per-target so the recurring detection identity inherits without propagation.
Cluster-level decisions land as separate workspace events with their own rationale and audit trail.

At audit fieldwork

The recompute procedure can be reproduced against any single scan execution within the retention window.
The activity log packet for the audit observation window exports cleanly with named actors, timestamps, and entity references.
Imported third-party findings trace back to the original vendor artefact through the import event and the archived source file.
Disposal events appear in the activity log with the named actor and the timestamp before any record is removed.

Scope and limitations

Scanner output attestation only works when the canonical record is durable, the content anchor is recorded adjacent to the canonical record, and the recompute procedure can be exercised without the original operator present. Programmes that store findings in spreadsheets, in scanner UIs that allow silent edits, or in workflow tools without typed actor and timestamp fields cannot operate the attestation chain at all. The leverage point is consolidating findings, scan executions, and workspace decisions into a workspace with stable foreign keys, a tamper-evident activity log, and a documented retention boundary before attempting to govern the integrity proof.

SecPortal does not replace an HSM-backed enterprise signing service, a transparency log, an external notarisation provider, or a customer-controlled append-only audit store. The attestation chain is operated against the structured fields and the activity log the workspace exposes; the content anchor, the recompute procedure, and any external anchoring choice are workspace decisions rather than platform automations.

For the structural layers the attestation chain sits on top of, the scanner evidence chain guide covers scan execution to finding to retest to closure. For the retention boundary the chain holds across, the scan evidence retention and governance guide covers how long the record is held and under what governance disposal happens. For the audit-side reuse of the same evidence across multiple frameworks, the vulnerability evidence reuse across audits research covers the economics of the chain across the audit calendar.

Frequently Asked Questions

Run scan-output attestation on a workspace auditors and security leaders can both verify

SecPortal stores every scan execution and finding against the engagement and the verified asset register, with the activity log capturing every workspace decision against the per-finding record. CSV export of the activity log packages the chain for the audit observation window without reconstructing history from chat threads. The platform exposes the structured surface attestation rests on; the policy and the recompute procedure are yours.

Start free See the evidence chain