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: contact an IBM org security
administrator to request that the repository be added to the exemption list. 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, the only ways to prevent archiving are to resolve or dismiss the
alert in GitHub before its deadline, or to have the repo added to the exemption list by an
IBM org security administrator.
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 is used internally but is inactive. Can it be exempted?
Repos can be added to an exemption list by the IBM org security
administrators. Exempt repos are still scanned and their alerts are recorded in the org's
security reports, but no tracking issue is created and archiving is never triggered. Contact
your org admin if you believe your repo warrants an exemption.
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.