Weekly Security Roundup - GitHub hardening, agent controls, threats

by TechHub

This week's Security roundup focuses on turning guidance into enforceable defaults across GitHub and Microsoft platforms. On the GitHub side, maintainers get practical hardening with gh-secure, a shift to stateless GitHub App installation tokens (plus a header deprecation deadline), and tighter vulnerability reporting and advisory collaboration APIs, alongside CI controls for Dependabot and quieter scheduled code scanning. We also look at real-world threat tradecraft (Zimbra command injection, RMM abuse, Azure DevOps pipeline pivots, and targeted malware) and the parallel push to secure action-taking AI agents with clear identity, policy enforcement, runtime isolation, and telemetry.

This Week's Overview

GitHub security tooling and platform changes for maintainers

gh-secure: one-command repo hardening for secret leak prevention

Building on last week's theme of turning GitHub security guidance into enforceable, repeatable defaults (from CI/CD controls to Secret Protection), GitHub highlighted gh-secure from the GitHub Security Lab as a fast way to improve baseline repository hygiene with a single command, with the explicit goal of reducing accidental secret leaks in public code. The positioning is pragmatic: run it quickly, get guardrails in place, and move on.

For teams that live in GitHub-native workflows, the tool is meant to be reachable where you already work, including the Copilot app, Copilot CLI, and the GitHub CLI. That makes it easier to bake quick checks into contributor onboarding or a standard “new repo checklist” before code goes public.

GitHub App auth: stateless installation tokens now default (and header deprecation date set)

In the same “identity-first operations” direction we covered last week (SSO enforcement and credential automation), GitHub completed its rollout of stateless GitHub App installation tokens, and new tokens are now issued by default in the ghs_APPID_JWT format. These tokens are significantly longer than the legacy format, which is where most breakage risk sits (validation rules, storage limits, proxies, and log redaction).

If you operate integrations that persist tokens anywhere (databases, secrets stores, CI variables) or pass them through size-sensitive infrastructure (reverse proxies, API gateways, WAFs), validate your length assumptions now. GitHub also called out that the X-GitHub-Stateless-S2S-Token header will be deprecated on November 30, 2026, so any code relying on that header should be updated before the cutoff.

Vulnerability reporting and advisories: better structure, throttling, and collaboration APIs

GitHub expanded private vulnerability reporting with structured forms, including required fields such as a minimum-length proof of concept and optional enforcement of CWE (Common Weakness Enumeration). Repos can define requirements in .github/VULNERABILITY_REPORT.yml, and GitHub added an API path to retrieve the enforced form so tooling that files reports via REST can stay compliant.

To reduce bulk or automated submissions, GitHub also introduced daily rate limits on new private vulnerability reports, with per-repo customization and allow-listing of trusted reporters via GitHub Advanced Security settings. For maintainers, that is a tradeoff that prioritizes signal over volume, but it also means you may need to coordinate with bug bounty partners and scanners so legitimate submissions do not get blocked.

On the advisory side, GitHub shipped confidential comments on repository security advisories (visible only to users with write access) and made them auditable, with the important caveat that confidentiality cannot be toggled after posting. In parallel, a public preview REST API now supports reading/adding/editing advisory comments (including advisories created from private vulnerability reports) and adds comment count fields to advisory responses, while the confidential comment feature is exposed via GraphQL but not REST.

Advisory data integrations: GraphQL gets CVE and review timestamps plus better filters

GitHub added new fields to the SecurityAdvisory GraphQL object, including CVE data and NVD/GitHub review timestamps, which reduces the need to fall back to REST for common advisory metadata. It also introduced severities and isWithdrawn filters on the securityAdvisories query, aimed at making downstream integrations (dashboards, risk scoring, alerting) more efficient and less error-prone.

If you maintain internal mirrors of the GitHub Advisory Database or enrich advisory records with EPSS (Exploit Prediction Scoring System) and NVD context, these additions can simplify data pulls and make “show me active, high-severity advisories” queries cheaper. It is a good week to check whether your GraphQL schemas and codegen need updates to take advantage of the new fields.

CI and dependency security: Dependabot runner controls and code scanning behavior changes

This continues last week's push to make CI/CD security controls practical to roll out at scale (from workflow execution protections to easier scanning coverage) as Dependabot now supports repository-level controls for which GitHub Actions runners it uses for version and security updates, including runner type plus optional custom labels and runner groups. That matters for enterprises that isolate network access (private registries, internal build networks) or require hardened runners for anything that touches dependency manifests and lockfiles.

GitHub also adjusted scheduled code scanning default setup behavior: weekly scheduled scans now start only after a push or pull request triggers an analysis. This avoids dormant repositories being treated as active due to validation or language-detection scans, which can reduce noise and unwanted resource spend in large orgs.

Upcoming crypto compatibility change: X25519-only TLS ends for GHE.com (data residency)

Following last week's SHA-1 HTTPS sunset, GitHub Enterprise Cloud with data residency will stop accepting TLS clients configured for X25519-only key agreement on October 7, 2026. GitHub will continue to support FIPS-approved P-256 and P-384, so the practical work is to find any impacted clients (older TLS stacks, strict crypto policies, pinned cipher group configs) and update them before the date.

This can surface in places you do not immediately associate with browsers, including Git remotes in build agents, dependency fetchers, webhook delivery validators, and enterprise proxies that terminate TLS. If you run compliance-focused TLS policies, confirm that your client hello offers P-256/P-384, not only X25519.

GitHub Advanced Security trials open up for GitHub Team

After last week's enterprise-focused GitHub Advanced Security enforcement controls, GitHub Team organizations can now start self-serve trials of GitHub Advanced Security, covering GitHub Code Security and GitHub Secret Protection. Trials are accessible from multiple entry points (org Overview, Billing and licensing, and Risk Assessment), which lowers the friction to run a time-boxed evaluation without procurement work up front.

If you want a meaningful trial, plan for at least one “real” repo with active CI so you can test alert triage workflows, baseline suppression, and pull request guardrails. Pair that with a secret scanning push-protection test to see how well the developer experience fits your team.

Securing AI agents: governance, execution boundaries, and threat reality checks

This week connected three practical threads: how to govern agents in large organizations, how to isolate agent execution when tools can take actions, and why defenders are treating agent identity and monitoring as first-class security concerns.

Multitenant agent governance with Entra, Agent 365, Purview, and policy enforcement

Building directly on last week's MCP governance and identity-aware tool authorization patterns, Microsoft published a federated reference architecture for governing AI agents across multiple Microsoft Entra tenants, using Agent 365 as a centralized inventory. The design combines Foundry and Copilot Studio for building agents, Purview for governance, and an Azure API Management AI gateway for runtime enforcement, evaluation, and operations.

Two implementation details stand out for builders: Model Context Protocol (MCP) is treated as a first-class integration surface for tools and context, and policy/telemetry are built in via Open Policy Agent (OPA) and OpenTelemetry. If you are already multi-tenant (subsidiaries, M&A, partner-operated tenants), this architecture gives a concrete way to standardize identity, access control, and auditing without forcing every agent into one tenant.

Execution boundaries for action-taking agents on AKS: OpenSandbox, Kata, and MCP tool separation

This complements last week's “Agent Control Loop” emphasis on enforcing constraints outside the prompt by focusing on where the agent code actually runs: separating the MCP tool interface from the sandbox lifecycle (OpenSandbox) and the runtime isolation layer (Kata Containers). The reference implementation is AKS-based, and the framing is clear - tool access and execution isolation should not be the same component if you want credible boundaries.

The piece also compares this approach with Azure Container Apps Sandboxes and Dynamic Sessions, which helps teams choose between “bring your own isolation design on Kubernetes” and a more managed platform option. If your agent uses credentials (even short-lived ones), the mention of a credential vault plus isolation-by-default is a reminder to treat tool invocation as a privileged operation, not a simple HTTP call.

Digital Defense Report themes: attackers use AI too, and agents need identity and monitoring

This reinforces last week's point that “healthy is not safe” for agents by zooming out to incident trends: Microsoft's 2026 Digital Defense Report write-up emphasized how connected identities, infrastructure, applications, and supply chains shape modern incidents, and it explicitly called out AI's growing role in attacker workflows. One practical takeaway for builders is that securing AI agents is not just about prompt injection defenses, but also about identity, access control, and monitoring as agents start to take actions.

A related post focused on governments, but the priorities map cleanly to enterprises: assume incident spread via identity compromise, speed up response for AI-accelerated threats, and improve bidirectional information sharing. For dev teams shipping agentic features, these posts are a cue to build around auditable identities, least-privilege tool permissions, and telemetry that security teams can actually query.

Active threats and incident tradecraft: email servers, RMM abuse, DevOps pivots, and targeted malware

CVE-2026-73570: unauthenticated command injection targeting internet-facing Zimbra servers

Microsoft Security Research detailed exploitation of CVE-2026-73570, an unauthenticated OS command injection affecting internet-facing Zimbra Collaboration Suite servers. The post walks through observed post-exploitation behaviors, includes indicators of compromise (IOCs), and provides concrete mitigation steps.

For defenders, the high-value asset is the set of Microsoft Defender XDR advanced hunting queries (KQL) to detect exploitation, persistence, and collection/exfiltration activity. If you have any Zimbra footprint, the timing is immediate: prioritize patching and put the hunting queries into rotation while you validate exposure.

Phishing + legitimate RMM tools: MSP360 to ScreenConnect for redundant access

Another Microsoft report covered July 2026 phishing campaigns that delivered a legitimate MSP360 RMM installer under deceptive filenames, then used it to deploy ConnectWise ScreenConnect for redundant remote access. The theme is familiar but still effective: use signed, real remote management tools so activity blends into “normal IT” noise.

The write-up includes mitigation guidance, Defender coverage, MITRE ATT&CK mapping, IOCs, and KQL hunting queries. If you allow RMM tools in your environment, you likely need explicit controls (approved tool lists, signer constraints, onboarding workflows) rather than treating all RMM as inherently trusted.

Storm-3068: identity foothold to Azure DevOps pipeline trust abuse and Kubernetes credential theft

This incident narrative lands on the same supply chain and CI/CD trust boundary concerns we highlighted last week (where workflow permissions and enforcement matter as much as code) as Microsoft DART described how Storm-3068 used a self-service password reset compromise to gain persistent identity access, pivoted into Azure DevOps, and abused trusted pipelines to harvest Kubernetes credentials (kubeconfig). The uncomfortable point is that source code is not required to take over delivery systems if identity and pipeline trust boundaries are weak.

The mitigations are practical: harden self-service password reset flows, reduce standing permissions, review pipeline trust relationships, and treat build systems as privileged identity surfaces. If your Kubernetes credentials are accessible from CI, re-check how and where they are stored, and consider narrowing them to workload identity or per-environment short-lived credentials where possible.

Star Blizzard and NeedyMantis: updated delivery chains and modular post-compromise tooling

Microsoft Threat Intelligence reported that Star Blizzard shifted to higher-volume phishing and introduced the RedFlick delivery chain, using scheduled tasks to deploy the CosmicPulse backdoor. The post provides mitigations, Defender detections, hunting queries, and IOCs, with extra value for Microsoft Sentinel users via ASIM queries.

Separately, Microsoft unpacked NeedyMantis as a modular post-compromise malware family, detailing its loader chain, custom encrypted archives, and HTTPS/WebSockets C2 protocol. Both write-ups reinforce a weeklong pattern: persistence and post-compromise capability are getting more modular, so defenders need visibility that survives initial containment (scheduled task auditing, outbound traffic inspection, and endpoint telemetry you can query at scale).

Identity and access changes you need on the calendar

SharePoint Online external sharing: SPO OTP retirement (Oct-Nov 2026) and Entra B2B migration

This extends last week's identity enforcement storyline (SSO authorization, SCIM improvements, and fewer brittle exceptions) as Microsoft is retiring SharePoint Online's one-time passcode (SPO OTP) flow in October-November 2026, pushing external sharing toward Microsoft Entra B2B guest accounts for SharePoint Online and OneDrive. The practical risk is broken access for some legacy sharing links and user journeys that depended on OTP rather than guest identity.

Admins should review external sharing policies, guest governance, and Conditional Access rules to make sure the new guest-based flow works for the right people and fails safely for everyone else. If your business relies on frictionless external sharing (partners, vendors, clients), plan communications and testing now rather than discovering failures during the retirement window.

Platform security operations: patching, perimeter visibility, and secretless app access

Hotpatch via Azure Arc for Windows Server 2025: fewer restarts for eligible security updates

Continuing last week's Azure hardening thread (operational controls you can standardize and audit), Azure Arc-enabled Windows Server 2025 can use Hotpatch to apply eligible security updates without the usual monthly restart cycle, which helps reduce downtime in environments where maintenance windows are tight. The walkthrough covers prerequisites like Secure Boot, VBS/VSM (Virtualization-Based Security/Virtual Secure Mode), and Hyper-V Gen2, plus enrollment steps in the Azure portal.

Hotpatch does not remove the need for planned baseline restarts, but it can change how you schedule them and reduce disruption for routine security updates. If you manage mixed fleets, it is worth validating where Hotpatch applies and how it integrates with Azure Update Manager for consistent reporting and rollout.

Azure Network Security Perimeter metrics GA: monitoring allowed/denied traffic with Azure Monitor

Azure Network Security Perimeter metrics are now generally available in Public Cloud, with guidance on using Azure Monitor metrics for dashboards, workbooks, and metric alerts. That gives security and platform teams a more direct way to track allowed/denied access and traffic patterns across perimeter-protected resources.

If you are rolling out perimeters as a control plane around PaaS resources, metrics and alerts are how you catch misconfigurations early (unexpected denials) and validate that enforcement is actually working (expected blocks). Pairing metrics with diagnostic logs can help separate “policy is blocking correctly” from “a client is broken.”

Sending email from AKS without stored secrets: Workload Identity + Graph permissions scoped to one mailbox

This builds on last week's emphasis on reducing long-lived secrets in automation (from OIDC-based publishing to identity-scoped tool calls) with a practical AKS guide that showed how to send email without storing secrets by using Azure Workload Identity to obtain Microsoft Entra ID tokens, then scoping Microsoft Graph Mail.Send via Exchange Online RBAC for Applications to a single authorized sender mailbox. The core idea is minimizing blast radius: the pod identity can only send as the mailbox you explicitly permit.

For teams trying to remove long-lived credentials from clusters, this is a reusable pattern for “agent or service needs to call SaaS” scenarios. The key implementation work is in correctly wiring workload identity (federated credentials) and validating the Exchange Online application RBAC scoping matches your intent.

Supply chain and developer workflow security: npm OIDC, IDE nudges, and research automation

npm trusted publishing: optional OIDC permissions for dist-tag management

This is a direct follow-on to last week's npm shift toward safer automation (stage-only tokens and fewer bypass paths) as npm trusted publishing can now optionally allow dist-tag management using short-lived OIDC credentials, so teams do not need to keep long-lived access tokens around just to update tags after a release. That is a small workflow change with a real security payoff because dist-tags often get updated outside the actual publish step.

If you already publish from CI with trusted publishing, check whether your process still relies on a separate token for tagging (latest, next, etc.). Moving dist-tag updates under OIDC reduces the number of places a reusable npm token can leak.

Visual Studio: Copilot BYOM agent mode, NuGet Audit fixes, and MCP-enabled Git agent

Following last week's agent security and MCP governance focus, the September Visual Studio update leaned into security-in-the-flow-of-work in a few ways: Bring Your Own Model (BYOM) for Copilot agent mode, Copilot-assisted fixes for NuGet Audit warnings directly from the Error List, and a Git agent for pull request exploration with MCP server support. Taken together, it is a push toward making audit findings and agent tooling usable without context switching.

For teams trying to standardize on specific models (for policy, privacy, or cost reasons), BYOM in agent mode is a practical governance lever, not just a customization feature. The NuGet Audit integration is the kind of small UX change that can improve remediation rates, especially when it guides developers from warning to fix while they are already in the IDE.

GitHub Security Lab: open-source AI agent used to find and disclose 24 Android vulnerabilities

This complements last week's agent hardening conversation by showing an offensive-but-disciplined workflow (scoped tools, verification, and a repeatable runbook): GitHub Security Lab shared how its open-source Taskflow Agent used targeted LLM taskflows to audit Android apps, leading to 24 disclosed vulnerabilities. The post includes a Codespaces-based runbook plus two vulnerability walkthroughs, and it does not dodge operational reality like false positives and severity estimation.

For security teams experimenting with AI-assisted review, the practical value is the repeatable workflow: a scoped taskflow, explicit verification steps, and an environment you can spin up quickly (Codespaces) to reproduce results. If you want to try this internally, plan for human validation time and define what “good enough confidence” looks like before filing issues.

Other Security News

GitHub Universe and Microsoft Ignite both published security-focused guides that can help teams plan learning and roadmap alignment, especially around MCP authorization, supply-chain threat modeling, and “secure AI” themes that cut across identity and data governance.

Microsoft Fabric also pushed hard on governance for agentic AI and analytics at scale, repeatedly emphasizing trusted meaning, provenance, permissions, and shared context (plus concrete platform features like OneLake, Fabric IQ, ontology governance, Real-Time Intelligence, and Purview DLP). If your organization treats analytics platforms as part of the security surface, these updates are a reminder that governance features are now expected to extend into Copilot and agent experiences, not remain a separate admin-only layer.