Weekly Security Roundup: Identity-First Defaults and Faster Triage

by TechHub

This week's security updates focused on making controls easier to apply consistently at scale across GitHub and Azure DevOps, while threat research highlighted how attackers abuse collaboration tools and OS-native scripting. The broader direction continues toward identity-first access (OIDC, Workload Identity, Entra) to remove long-lived secrets, plus guidance for AI incident response and cryptographic readiness. It continues last week's theme: reduce ambient privilege, tighten trust boundaries, and make secure defaults workable, whether through tokenless CI/CD, org-wide scanning baselines, or faster containment when users are socially engineered into granting access.

GitHub supply chain and code security: OIDC, registries, SBOMs, and better triage mechanics

GitHub security platform changes reduce per-repo one-off configuration and improve org-wide operations. Building on last week's workload identity direction (for example, npm Trusted Publishing OIDC expansion), orgs can now configure multiple private registries per ecosystem (npm, Maven, NuGet, Docker, pip, RubyGems, and others) at the organization security settings level. This removes the previous “one registry per ecosystem” limit and reduces repo-by-repo workarounds. GitHub also added OIDC auth for org-level private registries (via REST API too), enabling Dependabot and code scanning dependency resolution to use short-lived federated credentials instead of stored secrets. Initial integrations include Azure DevOps Artifacts, AWS CodeArtifact, and JFrog Artifactory. Together, these changes match last week's “operate it well” direction: fewer secrets and less per-repo drift. Code scanning moved closer to normal workflow with a new public preview that lets teams link code scanning alerts to GitHub Issues, with bidirectional navigation (alert “Tracking” section, issue “Security alerts” section). New has:tracking and no:tracking filters (including in Security Campaigns) help enforce hygiene such as “every actionable alert has a work item” without building custom dashboards. SBOM exports from Dependency Graph are now asynchronous, which avoids the previous 10-second timeout on large repos. API users must switch to a two-step flow: GET /repos/{owner}/{repo}/dependency-graph/sbom/generate-report returns a {sbom-uuid}, then poll GET /repos/{owner}/{repo}/dependency-graph/sbom/fetch-report/{sbom-uuid} (HTTP 201 while processing, HTTP 302 redirect when ready). This matters for CI/inventory pipelines that previously retried and triggered duplicate backend work, matching last week's push toward more predictable automation at scale. Detection and prioritization also improved. CodeQL 2.25.2 adds Kotlin support up to 2.3.20, reduces false positives in Java/Kotlin, C/C++, and C#, and updates @security-severity scoring. Notably, multiple XSS queries moved from 6.1 (medium) to 7.8 (high) across languages, and several log injection queries dropped from high to medium (Rust log injection rose from low to medium). If you gate builds or triage by severity, scoring shifts can reorder backlogs. This pairs with last week's org-wide reporting message: reprioritization helps only if teams notice it. GitHub also continues emphasizing what is actually running, extending last week's runtime-context integration (Dynatrace). Repository properties now include deployable and deployed signals from artifact/deployment metadata, which can help target rulesets and branch protection to repos that ship. Dependabot and code scanning alerts now show runtime risk context on alert pages so teams can treat “in prod” differently than “dormant.”

GitHub secret scanning and rapid exposure baselining

Secret scanning updates combined new detections, tighter enforcement (notably for fork-heavy enterprises), and API improvements for large-scale automation. This continues last week's operational thread around secret scanning APIs/webhooks and delegated visibility, with an emphasis on consistent automation and audit trails instead of manual chasing. Detection expanded with Cloudflare partner patterns: cloudflare_account_api_token, cloudflare_global_user_api_key, cloudflare_user_api_token. Push protection defaults expanded too: when secret scanning is enabled (including free public repos), additional patterns now block commits by default, including Cloudflare tokens and types like figma_scim_token, google_gcp_api_key_bound_service_account, langsmith_license_key, langsmith_scim_bearer_token, openvsx_access_token, and posthog_personal_api_key. This reinforces last week's “default guardrails” approach where default-on reduces reliance on repo owners remembering settings. For Enterprise Managed Users (EMU), push protection now follows the fork ancestor chain: if any repo in the hierarchy has push protection enabled, forks inherit it. This closes a gap where secrets could leak through forks created outside licensed contexts. REST API improvements support internal tooling at scale:

Azure DevOps Advanced Security: default CodeQL setup and org-wide alert coordination

Azure DevOps Advanced Security focused on making CodeQL adoption and triage less pipeline-centric and more centrally managed. In public preview, CodeQL default setup provides one-click enablement at repo/project/org scope, removing the need to author and maintain Azure Pipelines YAML, install CodeQL tasks, wire builds, and keep configuration current. With default setup, scans run automatically on a schedule adjustable at org level. This mirrors GitHub's direction: centralized controls that are easier to audit and harder to forget. A key control is setting which agent pool runs scanning jobs via org-level repo settings, which helps with network/compliance boundaries and capacity management. The updated combined alerts experience in Security Overview adds an org-wide view (default branch across repos) and security campaigns: shareable, filtered alert views that stay live as new matching findings arrive. This matches last week's org-level reporting theme (and this week's GitHub tracking mechanics): central visibility plus consistent workflows is what makes “fix across the estate” feasible when queries or CVEs reshuffle priorities.

Threat research: social engineering via Teams/Quick Assist and macOS AppleScript tradecraft

Two research writeups reinforced a recurring defender reality: attackers abuse legitimate workflows (collaboration, remote help, scripting) and then move quickly into hands-on-keyboard activity using native tooling to blend in. This extends last week's token-focused attack coverage (AiTM, device-code phishing): compromise often comes from trusted UX where users authorize access rather than from password theft. Microsoft documented a human-operated intrusion chain starting with cross-tenant Microsoft Teams helpdesk impersonation, quickly turning into recon, persistence, lateral movement, and exfiltration. The actor convinces a user to accept Teams contact and approve remote assistance (often Quick Assist), then within 30-120 seconds runs cmd.exe/PowerShell recon. Techniques include DLL side-loading using vendor-signed binaries from user-writable paths (often C:\\ProgramData), registry-stored encrypted config, outbound-HTTPS C2, and lateral movement via WinRM (5985). Exfiltration uses rclone.exe to external cloud storage with tuned parameters. The post includes KQL hunts correlating Teams events with remote-assist launches, detecting signed-host sideload patterns in ProgramData, registry breadcrumbs, and rclone command lines, plus mitigations across Teams external collaboration controls, Safe Links for Teams, ASR rules, WDAC, Conditional Access, and WinRM scoping. Practically, it is the “legitimate workflow abuse” sibling of last week's device-code story: both rely on trusted UX and short windows where containment and revocation playbooks must be fast. On macOS, Microsoft Threat Intelligence detailed a “Sapphire Sleet” campaign driven mostly by user-initiated execution of lures (for example, compiled AppleScript Zoom SDK Update.scpt) rather than exploits. Tradecraft centers on AppleScript's do shell script running staging like “curl → osascript,” with attacker user agents (mac-cur1...mac-cur5) mapping to stages (AppleScript loaders, ZIP-delivered .app bundles). The chain includes credential theft via a fake password prompt app, exfil via Telegram Bot API, persistence via LaunchDaemons, interactive backdoors opening zsh shells, and a technique to manipulate TCC by copying/modifying ~/Library/Application Support/com.apple.TCC/TCC.db and injecting sqlite rows granting AppleEvents control. The writeup includes IOCs (domains/IPs/paths/hashes) plus Defender XDR/Sentinel KQL hunts for Script Editor spawning curl/osascript, TCC.db changes, suspicious LaunchDaemon creation, Telegram Bot API traffic, and ZIP staging. Alongside last week's router/DNS hijack story, it is a reminder that initial compromise can look like normal user behavior, so hunts often start from downstream process/auth/permission signals.

Azure identity-first security patterns: passwordless AKS secret sync and Entra ID for Storage SFTP

Platform guidance continues replacing embedded credentials with identity federation and scoped authorization, with two practical examples. This also ties to last week's managed identity blast-radius guidance: identity-first helps only when scoping and separation are done well. For AKS, a guide shows syncing secrets from Azure Key Vault into namespaces using External Secrets Operator (ESO) with AKS Workload Identity, avoiding stored client secrets in-cluster. Steps include enabling AKS OIDC issuer + Workload Identity, creating a User-Assigned Managed Identity (UAMI), binding it to a Kubernetes ServiceAccount via a Federated Identity Credential (audience api://AzureADTokenExchange), and granting Azure RBAC read access (often Key Vault Secrets User). ESO uses SecretStore (authType WorkloadIdentity) and ExternalSecret to materialize values into Kubernetes Opaque Secrets, with refreshInterval (example 30s) controlling rotation propagation. Troubleshooting focuses on RBAC scope, federated issuer/subject mismatch, and missing OIDC/workload identity enablement. Last week's “gotcha” still applies: do not reuse the same UAMI broadly. Workload Identity makes token acquisition easier, so identity hygiene (environment separation, narrow RBAC) matters more. Entra ID integrated auth for Azure Storage SFTP was highlighted as a way to stop managing storage-account local users and instead authenticate via Microsoft Entra ID, authorizing via Storage data-plane RBAC (and optional ABAC conditions). A practical gotcha is that SFTP sessions are token-driven, so token lifetime and refresh behavior affects long transfers and persistent sessions. Validate client behavior before rolling into partner and batch pipelines. This matches last week's AiTM/device-code lessons: token handling (revocation, CAE/session constraints, client refresh behavior) increasingly determines access resilience for both attackers and automation.

AI and cryptography readiness: operational playbooks, not just features

Two guidance pieces addressed areas where classic security operations needs adaptation (AI systems and cryptographic readiness), echoing last week's governance/operability theme. Features help most when paired with operating models, observability, and clear ownership. On incident response, Microsoft's “Same fire, different fuel” argues core IR still applies (clear ownership, contain first, calm comms), but AI complicates triage and verification because outputs are probabilistic and harms do not map cleanly to CIA. The practical shift is AI-specific observability: anomalous output patterns, safety/classifier score shifts, spikes in user reports, and behavior changes after model/app updates. It recommends staged remediation: “stop the bleed” in the first hour (disable features, throttle, filters/blocklists), “fan out and strengthen” over 24 hours via automation, and “fix at the source” via classifier/model/guardrail updates, then verify with longer watch periods rather than one-off tests. It also calls out responder wellbeing when investigations involve harmful content. This overlaps with last week's agent governance theme: you need kill switches, clear guardrails, and telemetry to separate abuse, misconfiguration, drift, and toolchain issues. On cryptography, Microsoft outlined building a cryptographic inventory as the basis for cryptographic posture management and post-quantum readiness. The inventory spans certificates/keys, protocols/ciphers, embedded libraries, algorithms referenced in source, secrets/credentials, and hardware-backed crypto, and it is continuous: discover → normalize → assess → prioritize → remediate → monitor for drift. Developer relevance is work you can backlog: use GHAS/CodeQL to find crypto primitives/algorithms, pair with Defender for Endpoint/Vulnerability Management for certificate/component inventory, use Azure Key Vault as a key/secret/cert source of truth, and centralize signals in Microsoft Sentinel to avoid ad hoc ownership. It also complements last week's sovereignty/key-control thread: you cannot govern what you cannot inventory.

Other Security News

GitHub training content moved from prompt-injection basics to tool-using agent scenarios. Season 4 of the GitHub Secure Code Game introduces a vulnerable “ProdBot” with exploit-then-fix levels covering sandbox escape, untrusted web ingestion, MCP server tool connections, persistent memory risks (including poisoning), and multi-agent environments. It is designed for quick Codespaces runs and maps to OWASP agentic-app risks, complementing last week's agent governance and agentic SOC framing with hands-on failure modes.