Scans

Security scanning is the recurring, automated inspection of your environment for weaknesses: network scanners probe hosts, ports, and services; web application scanners exercise running applications for injection flaws and broken authentication; dependency scanners check your code's third-party packages against known vulnerability databases. External scans view your systems the way an attacker on the internet would, while internal scans assess what someone who already has network access could reach.

How a scan runs matters as much as what it targets. Authenticated (credentialed) scans log in to systems and can verify patch levels and configuration directly; unauthenticated scans approximate an outsider's view and miss anything not exposed to the network. Agent-based scanning installs software on each host for continuous visibility, while agentless approaches query infrastructure over the network or through provider APIs, which is how most cloud posture tools work. Mature programs combine several of these rather than relying on one; Vulnerability Scanning Guidance covers the scan types, cadences, and scanner options in detail.

For compliance, the execution record is the evidence. Most frameworks do not mandate an exact frequency (PCI DSS is the notable exception, requiring quarterly external scans), but auditors consistently test three things: that you defined a scanning cadence, that you followed it, and that you acted on the results. Scan records in Openlane hold that proof: when scans ran, what they covered, and who reviewed them.

How Scans Work in Openlane

A scan record represents one execution of a security check against a named target such as a domain, an IP address, or a codebase. Each record carries a scan type and a status, and a failed run stays on the record rather than disappearing, because a coverage gap has to be visible before anyone can own it.

Scan type	Typical use
Domain	Checks against a public domain or endpoint you operate
Vulnerability	Vulnerability scans of infrastructure or application targets
Vendor	Security review scans of a third party
Provider	Scans generated from a cloud or service provider

We offer domain and vulnerability scanning as a platform add-on for teams that want scans executed for them; scanners you already operate keep working alongside it, with each run recorded as a scan.

Cadence is part of the record, not a separate spreadsheet. Each scan carries an optional cron-style schedule and next-run timestamp alongside the date of the actual execution. Accountability fields track who performed the scan, who it is assigned to, and who reviewed it, either as free text or as linked users and groups.

Scans sit at the front of the exposure pipeline. They link to the assets and entities from your registry that they cover, and the vulnerabilities and findings they surface reference the scan as their source. You can attach the raw report as a file, connect the scan to evidence records, and link it to the controls and subcontrols it operates so each completed run doubles as control evidence. The full field list is in the API reference.

Working with Scans

Prove Your Scan Cadence to an Auditor

Give each recurring scan job a record with its scanSchedule and nextScanRunAt set, then update scanDate and status after every run and attach the report file. Link the scan to the monitoring control it operates, such as your system monitoring control. When the auditor asks how you know scans run on schedule, you filter scan records by target and hand over a dated, reviewable history instead of assembling screenshots from a scanner console.

Record Runs from Your Existing Scanner

Add a post-run step to your scanner's pipeline that creates a scan record with the target, type, date, and performedBy, sets the status to COMPLETED, and uploads the output file. If the results include vulnerabilities, create those records and link them back to the scan so the discovery chain stays intact. When a run fails, record it as FAILED rather than skipping it: auditors ask about coverage gaps, and a documented failure with an assignedTo owner reads as a working process, while a silent gap reads as a lapse.

Track Vendor and Provider Review Scans

Use the VENDOR scan type for security scans you run against third parties during due diligence, linked to the vendor's entity in your registry, and the PROVIDER type for scans originating from a cloud or service provider. The reviewedBy fields capture who signed off on the results, which is exactly what a vendor management control expects you to demonstrate.

FAQ

Does Openlane run scans for me, or do I record scans from my own tools?

Both. Domain and vulnerability scanning is available as a platform add-on if you want Openlane to execute scans. Independently of that, any scanner you already run can feed scan records into Openlane, which is how most teams keep their existing tooling while centralizing the evidence trail.

How often should we scan?

There is no universal mandate. A monthly external scan plus scans after significant changes is a common baseline; Payment Card Industry Data Security Standard (PCI DSS) specifically requires quarterly external scans by an approved vendor. What auditors actually test is adherence, so we recommend setting scanSchedule to the cadence you genuinely follow, because a documented monthly schedule with quarterly execution is worse than an honest quarterly schedule. See Vulnerability Scanning Guidance for cadence recommendations by environment.

A scan completed with no results. Should I still record it?

Yes. A completed scan with nothing found is cadence evidence: it shows the check ran and the target was clean at that point in time. Monitoring that never produces a record looks indistinguishable from monitoring that never happened.

Examples

CSV

# Create
Target,ScanType,Status,ScanDate,PerformedBy
api.acme.io,DOMAIN,COMPLETED,2026-02-01T01:00:00Z,Security Automation
vendor-security-review,VENDOR,PROCESSING,2026-02-05T15:00:00Z,GRC Team

# Update
ID,Status,ScanDate,NextScanRunAt,PerformedBy
SCN01J9SCAN11111111111111,COMPLETED,2026-02-10T02:00:00Z,2026-03-10T02:00:00Z,Security Automation
SCN01J9SCAN22222222222222,FAILED,2026-02-10T02:10:00Z,2026-02-11T02:00:00Z,Security Automation

GraphQL

mutation {
  createScan(
    input: {
      target: "api.acme.io"
      scanType: DOMAIN
      performedBy: "Security Automation"
    }
  ) {
    scan {
      id
      target
    }
  }
}

mutation {
  updateScan(
    id: "SCN01J9SCAN11111111111111"
    input: {
      target: "api.acme.io"
      assignedTo: "Security Automation"
    }
  ) {
    scan {
      id
      target
    }
  }
}

Go Client

ctx := context.Background()

performedBy := "Security Automation"
_, err := client.CreateScan(ctx, graphclient.CreateScanInput{
	Target:      "api.acme.io",
	PerformedBy: &performedBy,
})
if err != nil {
	return err
}

assignedTo := "Security Automation"
_, err = client.UpdateScan(ctx, "SCN01J9SCAN11111111111111", graphclient.UpdateScanInput{
	AssignedTo: &assignedTo,
})
if err != nil {
	return err
}

CLI

openlane scan create \
  --target "api.acme.io" \
  --type DOMAIN \
  --assigned-to "Security Automation"

openlane scan update \
  --id "SCN01J9SCAN11111111111111" \
  --status COMPLETED