gcp-scc-mute-finding

Principal with securitycenter.findings.setState or findings.setMute can individually mark findings as INACTIVE or MUTED, removing them from the active queue without a rule-based mute config.

derived gcp emits CanModifyConfiguration

match

A conjunctive graph pattern. Variables (?x) bind node ids; every clause must hold.

{'principal': None} HasPermission {'scc': None}

where

node_type(?scc) == SecurityService ?scc.provider_type in ['google.securitycenter.OrganizationSettings', 'google.securitycenter.ProjectSettings'] ?principal has EFFECTIVE securitycenter.findings.setState OR securitycenter.findings.setMute at the scope of ?scc

emit

source type	`Identity`
target type	`SecurityService`
source	`?principal`
target	`?scc`
permissions	`securitycenter.findings.setState` `securitycenter.findings.setMute`
conditions	`iam_permission`
state logic	ACTIVE when ?principal holds effective securitycenter.findings.setState or securitycenter.findings.setMute at ?scc.scope (via roles/securitycenter.findingEditor, roles/securitycenter.adminEditor, or roles/securitycenter.admin). BLOCKED if an IAM deny policy explicitly denies both setState and setMute at the effective scope. Confidence is lower than gcp-scc-mute-config-create (0.80) because this path requires per-finding manual action rather than a persistent rule.

Narrative

{principal.name} holds securitycenter.findings.setState or findings.setMute at {scc.scope} and can individually mark SCC findings as INACTIVE (resolved) or MUTED, removing them from the active finding queue. Unlike a mute config, this requires targeting each finding manually, but project-scoped findingEditor permission suffices - making it accessible to principals without org-level rights. This is a per-finding cover-tracks primitive.

Raw rule rules/derived/gcp/scc.yaml

id: gcp-scc-mute-finding
emits: CanModifyConfiguration
description: Principal with securitycenter.findings.setState or findings.setMute can individually mark
  findings as INACTIVE or MUTED, removing them from the active queue without a rule-based mute config.
match:
- - principal: null
  - HasPermission
  - scc: null
where:
- node_type(?scc) == SecurityService
- ?scc.provider_type in ['google.securitycenter.OrganizationSettings', 'google.securitycenter.ProjectSettings']
- ?principal has EFFECTIVE securitycenter.findings.setState OR securitycenter.findings.setMute at the
  scope of ?scc
emit:
  source_type: Identity
  target_type: SecurityService
  source: ?principal
  target: ?scc
  permissions:
  - securitycenter.findings.setState
  - securitycenter.findings.setMute
  conditions:
  - iam_permission
  state_logic: ACTIVE when ?principal holds effective securitycenter.findings.setState or securitycenter.findings.setMute
    at ?scc.scope (via roles/securitycenter.findingEditor, roles/securitycenter.adminEditor, or roles/securitycenter.admin).
    BLOCKED if an IAM deny policy explicitly denies both setState and setMute at the effective scope.
    Confidence is lower than gcp-scc-mute-config-create (0.80) because this path requires per-finding
    manual action rather than a persistent rule.
  confidence: 0.8
  derived_from:
  - HasPermission(?principal, securitycenter.findings.setState|securitycenter.findings.setMute, ?scc)
  false_positive_note: 'Per-finding muting/inactivating is lower-impact than rule-based mute configs and
    requires the attacker to manually target each finding they wish to suppress. It is most relevant when
    the attacker generates a small number of high-fidelity findings (e.g., a single ACCOUNT_COMPROMISED
    finding for their own activity) and wants to suppress only those. The setState(INACTIVE) operation
    appears as "resolved" in the SCC UI, which may be operationally plausible and less suspicious than
    a broad mute config. This is DEFENSE EVASION only; do NOT chain to access/escalation. Scope: project-scoped
    findingEditor can only setState on findings within that project; org-scoped permission covers all
    projects.'
  narrative: "{principal.name} holds securitycenter.findings.setState or findings.setMute at {scc.scope}\
    \ and can individually mark SCC findings as INACTIVE (resolved) or MUTED, removing them from the active\
    \ finding queue. Unlike a mute config, this requires targeting each finding manually, but project-scoped\
    \ findingEditor permission suffices \u2014 making it accessible to principals without org-level rights.\
    \ This is a per-finding cover-tracks primitive."