[security-observability] Daily Security Observability Report — 2026-09-11 #60303
Closed
Replies: 1 comment
|
This discussion was automatically closed because it expired on 2026-09-14T16:44:19.965Z.
|
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Executive Summary
Over the analysis window, the firewall processed 1,172,643 network requests across 100 firewall-enabled workflow runs (50 unique workflows), blocking 1,168,380 requests (99.64%). This extreme block rate is almost entirely driven by a single event: one Impeccable Skills Reviewer run generated 1,168,196 blocked requests to
registry.npmjs.org, most likely a dependency-resolution loop or retry storm rather than malicious traffic. Outside that anomaly, firewall activity is light and unremarkable — 8 unique domains were blocked in total, dominated by expected package-registry and AI-provider endpoints.On the DIFC integrity side, 2,785 filtered events were observed across 54 of 57 analyzed runs spanning 24 unique workflows. The dominant driver (99.7% of events) is agents attempting to read unapproved/public GitHub issues — content below the integrity threshold required by the calling workflow — concentrated in
list_issuesandsearch_issuescalls against thegithubMCP server. Daily Assign Issue To User and Dev account for over 40% of all filtered events, suggesting these workflows routinely enumerate broad issue sets that include untrusted, unapproved content by design (and are being correctly filtered, not mis-configured).No workflow appears in both the firewall-block hot list and the DIFC top-filtered list, indicating the two control planes are catching different, largely independent risk classes: network egress anomalies (firewall) versus content-trust boundary violations (DIFC).
🔥 Firewall Analysis
Key Firewall Metrics
📈 Firewall Request Trends
The log-scale trend makes clear that blocked volume is dominated by a single-day spike, driven almost entirely by one run's repeated npm registry requests. Excluding that anomaly, allowed and blocked traffic both track normal levels (low hundreds to low thousands of requests), consistent with routine MCP tool and package-manager use across workflows.
Top Blocked Domains
registry.npmjs.orgoverwhelmingly dominates blocked volume due to one anomalous run; all other blocked domains are low-frequency and consistent with expected package-manager (Go), AI-provider, and GitHub-infra traffic hitting egress rules rather than malicious destinations.Most Frequently Blocked Domains
Policy Rule Attribution
📋 Policy: 11 rules (most runs), SSL Bump disabled, DLP disabled — a small number of runs reported 9–10 rules, indicating minor policy-version drift across recent workflow runs.
No rule-level hit counts were returned by the audit tool for these runs (
rule_hitswas empty in all responses), so per-rule attribution could not be computed this cycle.View Detailed Request Patterns by Workflow
Remaining ~35 workflows had 0 blocked requests in the analyzed window.
View Complete Blocked Domains List
(unknown),ab.chatgpt.com:443,api.anthropic.com:443,api.github.com:443,github.com:443,proxy.golang.org:443,registry.npmjs.org:443,storage.googleapis.com:443🔒 Firewall Security Recommendations
registry.npmjs.orgfrom 5 runs of one workflow strongly suggests a retry loop, misconfigurednpm install/npm cistep, or an unbounded dependency-resolution loop rather than intentional scanning — review that workflow's package-manager invocation and add retry/backoff limits or allowlist the registry if the traffic is legitimate but blocked by policy.registry.npmjs.organdproxy.golang.orgfor workflows that legitimately need package installation, to avoid noisy false-positive blocks obscuring real anomalies in firewall logs.(unknown)domain blocks (16 occurrences across 3+ workflows) — these typically indicate DNS resolution failures or SNI mismatches; investigate whether they represent misconfigured proxy rules.ab.chatgpt.comblocks across Agent Persona Explorer, Daily CLI Performance Agent, and Issue Triage Agent — confirm these are intentional blocks of an unapproved AI provider rather than workflows that need it allowlisted.🔒 DIFC Integrity Analysis
Key DIFC Metrics
📈 DIFC Events Over Time
Filtering activity is bursty rather than steady, with three clear peaks (Sep 5, Sep 8, Sep 11) each exceeding 690 events, separated by low-activity days (Sep 2, Sep 3, Sep 7). These peaks align with scheduled runs of high-volume issue-scanning workflows rather than indicating an escalating trend.
🔧 Top Filtered Tools
list_issues(1,508) andsearch_issues(1,240) together account for 98.7% of all filtered events — both are broad enumeration calls against the GitHub MCP server that naturally surface a mix of approved and unapproved content, so filtering here is expected behavior rather than a sign of misconfiguration. All other tools (search_repositories,list_pull_requests,get_file_contents,issue_read,get_code_scanning_alert,search_code,list_dependabot_alerts) are filtered rarely (≤12 events each).🏷️ Filter Reasons and Tags
99.7% of filtered events are integrity-based (insufficient resource integrity vs. required threshold); only 9 events (0.3%) were secrecy-based. Tag-wise,
unapproved:public(2,025) andnone:public(2,785, applied to all events) dominate, with only 23 events taggedapproved:public(filtered for other reasons) and 69 events carrying theprivatesecrecy tag — confirming the filter is almost exclusively enforcing the "no unapproved public content" integrity boundary.📋 Per-Workflow DIFC Breakdown
📋 Per-Server DIFC Breakdown
👤 Per-User DIFC Breakdown
(Full list of 57 distinct contributors available in raw event data; long tail of 1–4 events each omitted for brevity.)
💡 DIFC Tuning Recommendations
list_issues/search_issuesfiltering on Daily Assign Issue To User, Dev, and Sub-Issue Closer as expected, not anomalous — these workflows intentionally enumerate broad issue sets, and 99%+ of filters are correctly blocking unapproved/public content from being read. No tuning action needed unless task completion is being materially impacted.privatesecrecy-tagged filters — confirm no workflow is inadvertently attempting to read private repository content it shouldn't have visibility into; these are low-volume but worth a manual spot-check.Generated by the Daily Security Observability workflow (consolidated from Daily Firewall Reporter + Daily DIFC Analyzer)
Analysis window: Last 7 days | Repository: github/gh-aw
Run: https://github.com/github/gh-aw/actions/runs/34618737701
All reactions