Security settings

Security features span several GitHub endpoints and availability tiers. Octoform reads each requested setting before planning and blocks mutation when GitHub does not expose trustworthy current state.

security

Shape: optional toggle object inside any policy layer.

defaults:
  security:
    vulnerability_alerts: true
    automated_security_fixes: true
    private_vulnerability_reporting: true

Field	Apply operation
vulnerability_alerts	Enable or disable Dependabot alerts
automated_security_fixes	Enable or disable Dependabot security updates
private_vulnerability_reporting	Enable or disable private vulnerability reporting
secret_scanning	Repository update under security_and_analysis
secret_scanning_push_protection	Repository update under security_and_analysis
code_scanning_default_setup	Update CodeQL default setup
immutable_releases	Repository update

Each field is tri-state. A concrete boolean manages it; null cancels an inherited value; omission contributes no policy at that layer.

immutable_releases stops a published release and its assets from being changed after the fact. It is an ordinary managed setting, and turning it on is the direction that is hard to reverse in practice: releases published while it was on cannot be edited afterwards.

Capability evidence

Private repository access to secret scanning and CodeQL default setup depends on GitHub availability and permissions. GitHub may omit unavailable fields instead of returning false. Octoform treats omission as unreadable and reports a blocked change.

The configuration never names a GitHub commercial plan. Owner kind, repository visibility, token permissions, returned fields, and endpoint responses provide the evidence used for each plan.

CodeQL setup boundary

CodeQL default setup is incompatible with a repository-managed advanced setup workflow. Enabling default setup can disable the advanced configuration. Leave code_scanning_default_setup unmanaged for repositories that own a codeql.yml workflow unless the migration is deliberate and separately reviewed.

Since 0.5.0 the plan says so itself. Octoform reads the repository's workflow files, and a policy that would enable default setup where a workflow uploads code-scanning results carries a warning:

    security.code_scanning_default_setup: false -> true  [warning: .github/workflows/codeql.yml upload code scanning results, and GitHub refuses those uploads while the default setup is configured]

It is a warning rather than a block because the migration is a legitimate thing to want. What made it worth reporting is that GitHub refuses the combination without either side reporting a failure: the uploads simply stop arriving.

Workflow files that could not be read produce their own warning, saying so, rather than an assurance that there was nothing to disable.

A second consequence is reported the same way: a repository whose visibility is internal warns that GitHub does not accept internal as a visibility to set, so changing away from it cannot be undone by changing the configuration back.

Plan and apply behavior

• Readable drift becomes an executable change.
• Unavailable or unreadable state becomes a blocked change with its reason.
• Repository-update security fields can be grouped with feature, merge, and repository settings.
• Dedicated security endpoints are attempted independently, so one failure does not suppress unrelated endpoint groups.

Recovery

Declare and apply the previous boolean value. If a GitHub plan or permission change makes the current state unreadable, Octoform cannot safely perform the reversal; restore access or change the setting directly in GitHub, then run a new plan. Removing the field only stops future management.

See Security and trust for credential selection, token lifecycle, output exposure, and incident response.