TL;DR — open security alerts found in your IBM org repo; please fix them before the deadline
The bot opened this issue because open security alerts were found in your repository.
Your job is to resolve those alerts — fix the vulnerable dependency, patch
the code flaw, or revoke the leaked secret. The bot manages the issue itself: it updates the
issue body daily and closes it automatically once all alerts are gone. You do not need to
close, edit, or label the issue — just fix the underlying security alerts.
What is this issue?
Once a day the security-ops automation scans every active repository in the IBM GitHub org
for three kinds of open security alerts:
Dependabot Alerts
Scanner runs daily at 06:00 UTC
Vulnerable third-party dependencies identified by GitHub's Dependabot service. Each alert
carries a CVE or GHSA identifier and the package that needs to be updated.
Code Scanning Alerts
Scanner runs daily at 07:00 UTC
Potential security vulnerabilities in your own source code found by tools such as
CodeQL (e.g. SQL injection, cross-site scripting, unsafe deserialization).
Secret Scanning Alerts
Scanner runs daily at 07:00 UTC
Credentials, API keys, tokens, or other secrets that were accidentally committed to the
repository and detected by GitHub's secret scanning service.
Enforcer
Runs daily at 08:00 UTC
Reads every open security issue, evaluates individual SLA deadlines, posts warning
comments as deadlines approach, and archives repos only when an SLA is breached.
If any alerts are found for your repository, the bot creates — or updates — one
security tracking issue in your repo. A single issue covers all three alert types
together so you receive only one notification, not dozens.
The issue is refreshed every day
On every daily run the bot re-reads the live alerts from GitHub and rewrites the issue body
to reflect the current state. Once all open alerts in your repository have been resolved, the
bot will automatically close the issue on the next run — no manual action needed.
SLA deadlines — how they work
Each alert has its own individual deadline calculated from the date the alert was first
discovered and the severity-based SLA defined in the org-wide policy:
| Severity |
SLA (days to remediate) |
Triggers warnings & archiving? |
| Critical |
7 days |
Yes |
| High |
30 days |
Yes |
| Medium |
90 days |
Yes |
| Low |
No deadline |
No — tracked for visibility only |
Each alert is evaluated independently. A critical alert discovered today has a 7-day deadline;
a high alert discovered two weeks ago may have 16 days left. The issue body shows the deadline
for every alert in the table.
What happens as the deadline approaches
1
Issue opened
The bot creates the security tracking issue the first time alerts are found. You (and
other admins named in the issue) receive a GitHub notification. No action is required at
this point — but it is a good time to review the alerts and start planning remediation.
2
Warning comments posted (3 days before deadline, then 1 day before)
When 3 days remain before any alert's deadline, the Enforcer posts a warning comment
listing the affected alerts. A second warning is posted when only 1 day remains. Each
comment @mentions the repo admins so you receive a notification. The warnings are posted
once per threshold per alert — you will not receive repeated pings for the same alert.
3
Archive notice posted & repo archived (if SLA is breached)
If an alert's deadline passes without the alert being resolved, the Enforcer posts a
final archive notice listing the breached alerts and archives the repository. The security
issue is then closed automatically. See the section below for what this means in
practice.
✓
Issue closed automatically — no action needed
Once all open alerts are resolved (fixed or dismissed in GitHub), the next daily scan
finds nothing to report and closes the issue for you. You do not need to close it
manually.
The right action depends on what state the issue is in when you see it:
1
Read the issue body. It lists every open alert by type, severity, and
(for Dependabot) the affected package and whether a fix PR already exists. If a fix PR is
already open, you may only need to review and merge it.
2
For Dependabot alerts: enable Dependabot security updates in your
repo settings (Settings → Advanced Security → Dependabot security updates → Enable). This
lets Dependabot automatically open fix PRs for vulnerable dependencies, dramatically
reducing manual effort.
3
For code scanning and secret scanning alerts: review each alert directly in
the GitHub Security tab of your repo. Fix the code issue or, if the alert is a false
positive, dismiss it with a reason in the GitHub UI.
4
If you cannot fix an alert before its deadline: first check whether the
alert can be
dismissed in GitHub (e.g. it is a false positive, used in
tests only, or has no actionable path to remediation). Dismissed alerts are removed from
the tracking issue on the next daily run. If the alert is genuine and cannot be resolved
right now, request an exemption as a last resort — open an issue in
IBM/security-ops-bot using the
"Request security enforcement exemption" template. Your request will be reviewed
by the security team; once approved it is processed automatically within 10 minutes.
Exempt repos are still scanned and tracked, but archiving is never triggered for them.
5
Do not close the tracking issue manually. The bot checks the alerts
daily and will close the issue for you once they are all resolved. No action is needed
for the security issue.
What does "repo archived" mean — and how to recover
Archiving makes the repo read-only
When a repo is archived on GitHub it becomes read-only: code can still be cloned and viewed,
but no new commits, issues, pull requests, or pushes are possible. This is a last-resort
enforcement action taken only after all warnings have been posted and the SLA deadline has
passed without remediation.
To get an archived repository restored to an active state:
1
Resolve the security alerts that triggered the archiving (the archive notice comment lists them).
2
Contact the IBM GitHub org administrators to request that the repo be unarchived.
3
Once unarchived, the next daily scan will confirm the alerts are resolved and will not
re-open a security tracking issue — no further enforcement action will occur.
Frequently asked questions
Do I need to do anything with the issue itself?
No. The issue is managed entirely by the bot. You should not close it,
edit its body, or add labels to it. Just work on resolving the underlying security alerts
in the GitHub Security tab, and the issue will close itself once they are all gone.
Why did I receive an email notification about this?
An Email Notifier component sends a formal email to repo admins when a new
security tracking issue is opened, when a warning comment is posted, and when an archive
notice is posted. The notification is sent to the email address associated with your GitHub
account in the IBM internal directory.
There are alerts I can't fix right now — will the repo definitely be archived?
Only if the alert's individual SLA deadline passes without the alert being
resolved or dismissed. Low-severity alerts have no deadline and will never trigger archiving.
For higher-severity alerts, consider these options in order: (1) resolve the alert by fixing
the underlying issue; (2) dismiss it in the GitHub Security tab if it is a false positive or
not applicable to your use case; (3) as a last resort, request an exemption (see below).
The alerts on this issue look wrong or stale. What should I do?
The issue body is refreshed every day based on the live alert state in
GitHub. If you resolved an alert and it still appears in the issue, check whether GitHub
has already marked the alert as resolved in the Security tab. The issue will be updated on
the next daily run (within 24 hours).
My repo cannot resolve its alerts right now. When should I request an exemption?
Exemption is a last resort — use it only when the alert is genuine (not
dismissible) and there is no near-term path to remediation (e.g. a legacy repo awaiting
decommission, or a known issue blocked on an upstream fix with no ETA). Before requesting,
check whether the alert can be dismissed in the GitHub Security tab as a false positive or
not applicable. If exemption is the right call, open an issue in
IBM/security-ops-bot using the
"Request security enforcement exemption" template. Provide your repository name
in the issue title (format:
[EXEMPT REQUEST] <repo-name>) and a clear
justification in the body. Your request will be reviewed by the security team — you will
receive an
"Awaiting approval" comment shortly after submission to confirm it was
received. Once a reviewer approves it (by adding the
approved label), the
automation processes the request within 10 minutes and will confirm via a comment on your
issue. Exempt repos are still scanned and their alerts appear in the org's security reports,
but no tracking issue is created and archiving is never triggered.
I dismissed an alert as a false positive in GitHub — will the issue update?
Yes. Dismissed alerts are no longer counted as open by GitHub's API. On
the next daily run the scanner will no longer see the dismissed alert, and it will be removed
from the tracking issue. If all alerts are dismissed or resolved, the issue will be closed
automatically.