Security Center monitors public GitHub repositories in real time and alerts you when an AccessKey pair belonging to your Alibaba Cloud account or a Resource Access Management (RAM) user is exposed. When a leak is detected, act immediately: revoke or replace the compromised credential first, then remove the exposed content from GitHub.
Security Center scans GitHub only. Any third party who obtains both the AccessKey ID and the AccessKey secret can use them to access your Alibaba Cloud resources.
How it works
When a leak is detected, Security Center notifies you through one or more channels depending on whether the exposed AccessKey secret is still valid:
| Channel | Triggered when |
|---|---|
| Alert on the AccessKey Leak Detection page | Any leak is detected, regardless of secret validity |
| Console prompt | Secret is still valid |
| Email or internal message | Secret is still valid |
By default, only account contacts receive notifications.
The validity check built into these notification channels helps you prioritize remediation: if you receive a console prompt or email, the credential is still active and must be revoked immediately.
AccessKey pair leaks are high-severity incidents. Enable all available notification methods so you hear about leaks as fast as possible.
Configure alert notifications
In the Security Center consoleSecurity Center consoleSecurity Center console, go to Notification Settings in the left-side navigation pane.
On the Email/Internal Message tab, find AccessKey Pair Leak Information and configure the Notification Method.
To add recipients beyond the default account contacts:
Open the Common Settings page.
In the Notification Type column, choose Security message > Security Notice.
Click Modify in the Contact column and update the recipients.
Changes to notification recipients apply to all Security Center notifications, and also to notifications from Anti-DDoS and Web Application Firewall (WAF).
On the Common Settings page, navigate to the section and modify the message recipients.
Changes to the recipients in this section also apply to other notifications from Security Center, and from other services like Anti-DDoS and WAF.
Respond to an AccessKey pair leak
When you receive a leak alert, act on two parallel tracks simultaneously: revoke or replace the compromised credential in the RAM console, and remove the exposed content from GitHub.
Prioritize revoking the credential. Once the credential is disabled or deleted, the exposure is neutralized even if the file still exists in Git history. Cleaning up Git history is time-intensive and is secondary to credential revocation.
Step 1: Identify the leak source
Log in to the Security Center consoleSecurity Center consoleSecurity Center console. In the top navigation bar, select the region (China or Outside China) where the affected asset resides.
In the left-side navigation pane, choose Risk Governance > AccessKey Leak Detection.
Find the event and click Details in the Actions column.
In the File Details section, click the Username, File Name, or Repository Name value to open the source on GitHub.
Step 2: Revoke or replace the compromised credential
Security Center cannot automatically revoke leaked credentials. Rotate the credential in the RAM console first, then mark the event as handled in Security Center.
In the RAM console:
If you no longer need the leaked AccessKey pair, delete it. See Delete an AccessKey pair for a RAM user.
If your workloads still depend on it, disable the leaked pair and issue a new one. See Disable an AccessKey pair for a RAM user.
Make sure rotating the credential does not break your core business workflows before proceeding.
On GitHub:
Contact the relevant team to delete or hide the file or repository that contains the leaked credential.
Step 3: Mark the event as handled
After rotating the credential, close the event in Security Center:
On the AccessKey Leak Detection page, find the event and click Handle in the Actions column.
In the dialog box, select a handling method and click Handle Now.
Available handling methods:
| Method | When to use |
|---|---|
| Manually Deleted | The leaked AccessKey pair has been deleted |
| Manually Disabled AccessKey Pair | The leaked AccessKey pair has been disabled |
| Add to Whitelist | You want to add the event to the whitelist |
After you select a handling method, the event status changes to Handled. If you selected Add to Whitelist, the status shows Added to Whitelist and the event moves to the Handled list. To remove an event from the whitelist, find it in the Handled list, open the details page, and click Cancel the whitelist.
Review AccessKey pair call records
After a leak, check whether the exposed credential was used by unauthorized parties. Use ActionTrail to query the call history.
Tip: You can also use the AccessKey pair audit feature in ActionTrail to review access logs. See Query the logs of an AccessKey pair.
In the Security Center consoleSecurity Center consoleSecurity Center console, go to the AccessKey Leak Detection page and copy the AccessKey ID.
Log in to the ActionTrail console.
In the left-side navigation pane, choose Events > Event Query.
In the top navigation bar, select the region from the drop-down list.
Select AccessKey ID from the Read/Write Type drop-down list, paste the AccessKey ID, and select a time range.
Find the relevant event and click View Event Details in the Actions column.
For a description of the fields in management events, see Management event structure.
Monitor for abnormal AccessKey pair usage
After handling the incident, set up ongoing monitoring to catch future anomalies early.
Detect threats with Security Center
Security Center uses AI models trained on years of attack data to flag suspicious API calls — for example, calls from IPs with an attack history, bulk use of multiple users' AccessKey pairs, or calls to sensitive APIs using a previously leaked credential.
Log in to the Security Center consoleSecurity Center consoleSecurity Center console. In the top navigation bar, select the region.
In the left-side navigation pane, choose Detection and Response > Alert.
If you have activated Agentic SOC, navigate to Agentic SOC > Alert instead.
Set Alert Type to Cloud threat detection and check for alerts on abnormal AccessKey pair calls.
(Optional) Configure alert notifications: go to System Settings > Notification Settings, find Alert in the Notification Item column, and select your preferred methods.
The Basic Edition supports only the internal message notification method.
Set up ActionTrail built-in alerts
ActionTrail provides two built-in alerts specifically for AccessKey pair monitoring:
Alert of Frequency of AK Abnormal Usage
Root Account AK Usage Detection
To enable these alerts, see Configure event alerts.
Identify anomalies with ActionTrail Insights
The Insights feature in ActionTrail analyzes historical call patterns and surfaces AccessKey pairs with abnormal activity rates. To enable Insights and review Insights events, see Query Insights events in the ActionTrail console.
Prevent future leaks
Apply the following practices to reduce the risk of future AccessKey pair exposures:
Avoid root account AccessKey pairs. Use RAM users instead.
Never hard-code credentials. Store AccessKey pairs in environment variables. See Credential security solutions.
Use private repositories. Keep source code in private GitHub repositories or an internal code-hosting system to prevent accidental exposure.