Skip to content

Security automation

Combine scan schedules, repository policies, and notifications while checking what actually ran or was delivered.

Build a repeatable review routinePermalink to Build a repeatable review routine

Automation helps a team assess repositories regularly, apply a consistent review threshold, and send results to the people responsible for follow-up. It does not replace investigation, authorize live testing, merge fixes, or establish that a repository is secure.

Before configuring automation, choose the correct workspace, connect the repository, and make sure you have permission to change its settings. Review a manual scan first so the team understands its coverage and can choose meaningful policy rules and notification recipients.

  1. Agree on a response

    Decide who reviews confirmed findings, who validates candidates, and what happens when coverage is insufficient.

  2. Set the policy

    Choose the severity threshold and whether unknown severity and inadequate coverage should fail the policy.

  3. Choose the cadence

    Create a daily or weekly schedule that suits the repository's review needs.

  4. Connect notifications

    Add a destination and choose the events the responsible team needs.

  5. Check the outcomes

    After a scheduled time and a matching event, inspect the run, its policy verdict, and the recorded delivery rather than stopping at successful configuration.

Schedules: when to request a scanPermalink to Schedules: when to request a scan

A repository can have one daily or weekly schedule at a UTC time. You can turn it off without deleting it. A saved or enabled schedule is configuration; Last run tells you whether a scheduled attempt started, was skipped, or failed.

Policies: how to judge a resultPermalink to Policies: how to judge a result

A repository policy defines conditions for a scan result to pass or fail. Only confirmed findings contribute to finding-based failure rules; coverage is a separate condition and can fail a result with no findings. Look for the actual verdict on the scan report when available.

Integrations: where notifications goPermalink to Integrations: where notifications go

Workspace notification destinations support email, Slack, Microsoft Teams, and HTTPS webhooks. Choose a destination the responsible reviewers can access and subscribe to the events you need. Saving it does not test the destination or prove that a notification was delivered.

Choose notification eventsPermalink to Choose notification events

The notification choices include a scan finishing, a scan being unable to finish, and a scan failing its policy. Every event includes new event types when they become available; Choose events lets you select a narrower subscription. No explicit event selection means every event, not none.

Verify each part independentlyPermalink to Verify each part independently

ConfiguredEvidence of an outcome
Schedule savedA recorded last-attempt outcome and, if started, the linked scan.
Policy savedA policy verdict on the specific scan result.
Destination addedA recorded delivery outcome after a matching event.

Availability, repository eligibility, permissions, and quota can affect what happens next. A successful settings change is not a promise that execution or delivery is available everywhere. Follow the visible status and contact support with the relevant scan or destination name when an expected outcome is missing.