Findings

A finding is an observed security issue: a specific resource, in a specific state, at a specific time. A storage bucket open to the public, a security group allowing inbound traffic from anywhere, a service account with unused admin privileges, an observation from last quarter's penetration test. Where a vulnerability describes a known weakness in the abstract (a CVE with a severity score), a finding describes an instance in your environment, which is why findings carry resource identifiers and source-reported state rather than package versions and patch availability.

Findings mostly come from tools that watch your environment continuously: cloud security posture services like AWS Security Hub, Google Security Command Center (SCC), and Microsoft Defender for Cloud, plus periodic sources like penetration tests and internal reviews. The operational challenge is volume. These tools generate findings faster than any team can individually investigate, so an effective program depends on filtering out noise at the source, triaging what remains by severity and production impact, and validating which findings are real before committing engineering time.

Auditors evaluate the handling process rather than the raw count. An organization with fifty open findings and a documented pipeline from detection through triage to closure demonstrates working monitoring and response; a claim of zero findings tends to invite scrutiny instead. What gets tested is traceability: pick a finding, show who assessed it, what was decided, and how it was closed or accepted.

How Findings Work in Openlane

Integration ingestion is the primary source. The AWS, GCP Security Command Center, and Microsoft Defender for Cloud integrations pull findings and alerts from their providers and normalize them, linking each record to the integration that produced it. The AWS and GCP integrations deduplicate on the source's stable identifier so repeated syncs update existing records instead of creating duplicates, and accept Common Expression Language (CEL) filter expressions in the integration configuration that decide what gets ingested at all; the raw source payload can be retained on the record for auditing and troubleshooting.

Each finding preserves the source's reported data, so triage does not require a trip back to the provider console. Three facts carry most of the triage weight: a normalized security level that makes severity comparable across sources that label it differently, a production marker that separates live exposure from lab noise, and a remediation service level agreement (SLA) that turns the triage decision into a deadline. Remediation guidance from the source travels with the record as recommended actions, giving the eventual assignee a starting point.

Findings connect across the exposure pipeline: to the scans that surfaced them, the vulnerabilities they relate to, the assets and entities they affect, and the remediations and tasks that close them. Two connections matter specifically for compliance: findings map to controls and subcontrols through control mappings, tying detection to the control it implicates, and findings link to risks when a pattern warrants register-level attention. The full field list is in the API reference.

Working with Findings

Triage This Week's Intake

Filter open findings by securityLevel for CRITICAL and HIGH, then narrow to production. Investigate each, and mark the real ones validated so downstream effort concentrates on confirmed issues. When a recurring class of finding is consistently noise, do not keep triaging it by hand: tighten the CEL filter expression on the integration so it never becomes a record. The AWS and GCP SCC integration guides show filter examples, such as ingesting only critical and high severity findings.

Drive Findings to Closure

For each validated finding, create a remediation with an owner, a ticket reference, and a due date consistent with the finding's remediationSLA. The recommendedActions guidance from the source gives the assignee a starting point without a trip back to the provider console. Because integration syncs keep records current, a finding the provider now reports as INACTIVE corroborates that the fix landed; flip open to false once you have confirmed closure on your side.

Turn Detection into Audit Evidence

Map findings to the controls they implicate through control mappings. A finding against an in-scope control, followed by a linked remediation and closure, is the monitoring-and-response chain auditors ask for: the control's monitoring caught an issue and the process resolved it. When the same category of finding recurs across resources or accounts, escalate the pattern to a risk and link the findings to it, so the systemic issue is assessed and treated at the register level rather than fixed one resource at a time.

FAQ

When does something belong as a finding versus a vulnerability?

If it is a known weakness with an identity of its own, typically a CVE tied to a package or version, it is a vulnerability. If it is an observed condition on a specific resource, such as a misconfiguration or policy violation, it is a finding. The cloud integrations make this call during normalization and create the appropriate record type; the two link to each other when a finding is an instance of a known vulnerability.

Our cloud tools produce far more findings than we can handle. What do we do?

We recommend filtering before ingestion rather than after. The AWS and GCP SCC integrations support CEL filter expressions evaluated against each source record, so you can restrict ingestion to the severities, categories, or sources you will actually act on. What does land gets triaged by securityLevel and production, and marked validated before it consumes remediation capacity.

Do open findings look bad in an audit?

Not by themselves. Auditors expect active environments to produce findings continuously; what they test is whether your process works. Open findings with owners, due dates, and linked remediations demonstrate an operating control. A suspiciously empty findings list invites harder questions than a managed backlog does.

Examples

CSV

# Create
ExternalID,Source,DisplayName,Category,Severity,Status,Open,RecommendedActions
gcp-99001,gcp_scc,Public storage bucket,DATA_EXPOSURE,HIGH,OPEN,true,Disable public access and rotate exposed credentials.
gcp-99002,gcp_scc,Legacy TLS policy,CRYPTOGRAPHY,MEDIUM,OPEN,true,Enforce modern TLS baseline.

# Update
ID,Severity,Status,Open,Validated
FIND01J9FIND1111111111111,MEDIUM,IN_PROGRESS,true,true
FIND01J9FIND2222222222222,LOW,CLOSED,false,true

GraphQL

mutation {
  createFinding(
    input: {
      externalID: "gcp-99001"
      source: "gcp_scc"
      displayName: "Public storage bucket"
      category: "DATA_EXPOSURE"
      severity: "HIGH"
    }
  ) {
    finding {
      id
      displayName
    }
  }
}

mutation {
  updateFinding(
    id: "FIND01J9FIND1111111111111"
    input: {
      severity: "MEDIUM"
      state: "ACTIVE"
    }
  ) {
    finding {
      id
      severity
    }
  }
}

Go Client

ctx := context.Background()

displayName := "Public storage bucket"
source := "gcp_scc"

_, err := client.CreateFinding(ctx, graphclient.CreateFindingInput{
	DisplayName: &displayName,
	Source:      &source,
})
if err != nil {
	return err
}

severity := "MEDIUM"
_, err = client.UpdateFinding(ctx, "FIND01J9FIND1111111111111", graphclient.UpdateFindingInput{
	Severity: &severity,
})
if err != nil {
	return err
}

CLI

openlane finding create \
  --display-name "Public storage bucket" \
  --category DATA_EXPOSURE \
  --severity HIGH \
  --source gcp_scc

openlane finding update \
  --id "FIND01J9FIND1111111111111" \
  --severity MEDIUM