[security-observability] Daily Security Observability Report — 2026-06-27 #41910
Closed
Replies: 1 comment
-
|
This discussion has been marked as outdated by Daily Security Observability Report. A newer discussion is available at Discussion #42532. |
Beta Was this translation helpful? Give feedback.
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
This report covers the last 7 days of security observability across all agentic workflow runs in the
github/gh-awrepository (2026-06-20 through 2026-06-27). Firewall analysis reveals a period of high blocking activity on 2026-06-22 (8,345 blocked requests, 65.2% block rate), driven predominantly by Google/GCP domain access attempts and localhost connections, consistent with browser-automation tooling reaching out-of-policy endpoints. Activity returned to lower levels on 2026-06-24 (776 blocked, 16.0% block rate), and today's fully analyzed runs show 0 blocked requests — today's bulk of 103 firewall-enabled runs are still under analysis. DIFC integrity filtering recorded zero events in this window, indicating no tool calls were flagged for integrity or secrecy violations — a healthy baseline.Key themes: browser-based workflow sandbox escape attempts via Google APIs; Playwright CDN access blocked as expected; two unexpected blocks of
api.github.comandgithub.comfrom a run that should have those allowlisted. No cross-cutting issues observed between the two signals.Firewall Analysis
Key Firewall Metrics
Firewall Request Trends
Firewall activity shows a pronounced spike on 2026-06-22 (8,345 blocked out of 12,792 requests) followed by significant reduction on 2026-06-24 (776 blocked out of 4,844 requests). Today (2026-06-27), the 4 fully analyzed runs show 0 blocked requests — the bulk of today's runs are still being processed. The spike pattern on June 22 corresponds to a high volume of browser-automation or Playwright-based workflow runs that attempted Google API access, which is blocked by default in the sandbox firewall policy.
Top Blocked Domains
Google/GCP domains dominate the blocked list (61% of all blocks), followed by
localhost:8080and unknown endpoints. The presence ofplaywright-akamai.azureedge.net,playwright-verizon.azureedge.net, andplaywright.azureedge.netconfirms Playwright browser automation was active in some runs. Critically,proxy.golang.organddocs.astro.buildblocks suggest development/build tool activity that may benefit from allowlisting if legitimate.Most Frequently Blocked Domains
Policy Rule Attribution
Policy: 9 rules, SSL Bump disabled, DLP disabled
The current policy uses 9 firewall rules. No per-rule hit attribution was available from the fresh audited runs (all returned 0 blocks). Historical blocks align with the
deny-raw-ipv4and domain-based deny rules.View Firewall Audited Runs Detail
Domains accessed by audited runs (all allowed):
api.githubcopilot.com:443— GitHub Copilot APIapi.anthropic.com:443— Anthropic Claude APIgithub.com:443— GitHubo205451.ingest.us.sentry.io:443— Sentry telemetryotlp-gateway-prod-eu-west-2.grafana.net:443— Grafana OTLPView Complete Blocked Domains List (Alphabetical)
Firewall Security Recommendations
Investigate
api.github.comandgithub.comblocks: These domains appear in the allowlist of the sandbox firewall policy, yet 2 block events were recorded. Verify the policy version applied to those specific runs and ensure the allow rules are being applied before the deny rules.Evaluate
proxy.golang.orgallowlisting: Go module proxy access suggests workflows that build or test Go code. If these are legitimate build operations, consider addingproxy.golang.orgto the firewall allowlist for build workflows.Review
antigravity-unleash.goog: Two blocks of the Unleash feature flag service suggest a workflow that relies on this service at runtime. If legitimate, allowlistantigravity-unleash.goog:443.Document Google/Chrome API access: The high volume of Google domain blocks (>60% of all blocks) is consistent with Playwright/Chromium browser automation. Review whether these runs are expected to access Google APIs; if not, investigate for potential sandbox escape attempts.
Monitor localhost:8080 blocks: 14 blocks of
localhost:8080indicate a workflow is attempting to connect to a local service that isn't running in the sandbox. Review which workflows generate these blocks and whether local service startup ordering is the cause.Audit
docs.astro.buildaccess: One block of the Astro documentation CDN suggests a workflow may be fetching external documentation at runtime — an unusual pattern worth investigating.DIFC Integrity Analysis
Key DIFC Metrics
No DIFC integrity-filtered events found in the last 7 days.
Both the fresh
filtered_integritylog query and the cached snapshot (last updated 2026-06-23) confirm zero DIFC gateway events across all workflow runs in this period. This indicates:DIFC charts (events timeline, top filtered tools, reason breakdown) are not generated as there are no events to visualize.
DIFC Tuning Recommendations
Baseline is healthy — Zero DIFC events across 168+ workflow runs is expected behavior if workflows are accessing only appropriately tagged resources. No immediate tuning required.
Maintain monitoring — Continue daily DIFC analysis. A sudden increase in filtered events would indicate either a new workflow accessing higher-sensitivity data, or a potential policy misconfiguration.
Review DIFC policy coverage — With new workflows being added regularly (103 runs today alone), periodically verify that the DIFC policy covers all new MCP servers and tool categories being deployed.
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: §28294661074
Beta Was this translation helpful? Give feedback.
All reactions