标签：#secrets

This is a follow-up to an article we published in The Hacker News introducing time to revoke as a critical CISO metric. This version provides a practical guide for measuring it across exposed secrets and non-human identities. 👉 TL;DR: Time to revoke is a security metric that measures how long an exposed credential remains usable after it has been confirmed valid. Measuring it requires teams to record when a credential is validated and when its invalidation is confirmed. From that baseline, CISOs can track median and P90 time to revoke, the percentage of exposed secrets revoked within SLA, owner coverage, the percentage that remain valid after detection, and the incidents that require manual escalation. Detection is not the same as credential revocation Detection tells you when a credential was found. A remediation ticket tells you when work was assigned or closed. Neither tells you whether the exposed access was fully neutralized. For leaked credentials, "Did we find it?" is the first question. "How long did it remain valid?" is just as important, if not more so. If a leaked API key, cloud credential, service account token, OAuth secret, private key, or database connection string is still valid, it is a point of ingress. Until it is revoked, rotated, or otherwise invalidated, it remains a path an attacker can use. Credential rotation only counts when the exposed credential is disabled, expired, or otherwise rendered unusable. That makes time to revoke a critical CISO metric. It connects detection to business risk by measuring the exposure window security teams need to close. What is time to revoke in secrets remediation? Time to revoke measures how long an exposed credential remains usable after it has been confirmed valid. Time to revoke = confirmed invalidation timestamp − validation timestamp The clock starts when the organization verifies that the credential works and stops when it confirms that the credential can no longer be used. Closing a ticket, deleting a

Why identity-local signals and topology signals are two layers of the same blast radius The credential with the widest blast radius sometimes has no secret to flag. See how GitGuardian and Anyshift rank risk by what actually breaks. By Louis Fradin • 23 Jul 2026 • 7 min read 👉 TL;DR: Identity-local signals show whether a credential or machine identity is risky. Topology signals show what breaks if that identity is abused. GitGuardian identifies and ranks exposed credentials and risky machine identities; Anyshift's graph adds downstream context by showing which services depend on the resources those identities reach. Together, they help teams prioritize by both credential severity and operational blast radius. A leaked credential is also a topology problem A leaked credential creates risk beyond the identity itself. Its real impact depends on the services and resources connected to what that credential can access. Identity-local signals answer the first question: how risky is this credential or machine identity on its own? Is it plaintext? Guessable? Stale? Overprivileged? Production-exposed? Tied to an admin identity? Those signals matter because they identify the secrets and machine identities most likely to be abused. But they do not answer the next question: what breaks if that credential is used? That answer lives in the topology around the credential. A database credential may sit on one pod and unlock one datastore, but the operational blast radius extends to every service that depends on that datastore. Some of those services never hold the credential at all. Some may not even have a secret signal to score. Want to run the same analysis on your own stack? Explore the Anyshift Graph API to query dependencies, blast radius, and production impact directly. Learn more That is where identity-local signals and topology signals become two layers of the same blast radius: one tells you why the credential is dangerous, and the other tells you how far the damage can tr

GitHub said this week that Copilot CLI, when it runs inside a GitHub Actions workflow, will accept the built-in GITHUB_TOKEN for authentication. Per the July 2 changelog, the previous path required creating and storing a personal access token. The operational read is small and precise: one fewer human-owned credential to mint, rotate and inherit. The exact scope of the change The changelog covers a narrow surface. It applies to Copilot CLI when invoked from a GitHub Actions workflow, and it swaps the required credential from a PAT to the workflow's ambient GITHUB_TOKEN . GitHub does not describe changes to how Copilot CLI authenticates outside Actions, and this post will not extrapolate to those contexts. If your Copilot CLI usage lives on a developer laptop or in another CI system, nothing in this announcement moves for you. Why the PAT was the wrong credential to leave in the loop A personal access token has almost none of the properties you would want from an automation credential. It does not expire on a job boundary. It carries a person's identity, not the workflow's. It sits in Actions secrets long enough to outlive the engineer who created it. And its scopes were chosen by that engineer, at that moment, often wider than the job actually needs. GITHUB_TOKEN is the opposite shape. Actions mints it at the start of a job, scopes it through the workflow's permissions: block, and revokes it when the job ends. If the token leaks, the window for abuse is the runtime of the job, not the years until somebody remembers to rotate it. When the person who wrote the workflow leaves, the pipeline does not silently break because a token expired with their account. For scripted Copilot CLI calls that had to be wrapped in a PAT, that is the whole win. The tool authenticates against the workflow instead of against a human. Wiring it up The workflow-side pattern is the same one every GITHUB_TOKEN -consuming step already follows: declare permissions: explicitly at the job level, k

I built a zero-knowledge secret sharing tool. Text and files are encrypted in the browser with AES-GCM 256 before upload - the server only ever sees ciphertext. The decryption key lives exclusively in the URL fragment (#k=...). URL fragments are never sent in HTTP requests (RFC 9110 §4.2.3), so Cloudflare Workers, D1, and R2 never see it - even in logs. A few things I tried to do right: Single-use by default: Durable Objects handle atomic read→decrement→delete with blockConcurrencyWhile, no race conditions on concurrent requests Paranoid mode: returns not_found instead of expired/burned, no timing oracle Revoke endpoint: delete a drop before it's read using a SHA-256'd token with constant-time comparison CLI: burnafter send / burnafter receive - full E2E from terminal, key never touches a browser - /security page with a live in-browser AES-GCM demo and a manual Node.js decryption snippet so you can verify without trusting me Stack: Cloudflare Workers + D1 + R2 + Durable Objects. No third-party crypto libs. Live: https://burnafterread.casablanque.com Source: https://github.com/casablanque-code/burnafterread Verify: https://burnafterread.casablanque.com/security

Why This Deserves More Attention Than It Gets Credential leaks are one of the most common and preventable security incidents in software. Bots actively scan GitHub for newly pushed API keys, database URLs, and private credentials — and they find them within minutes of a commit going public. Rotating compromised credentials is painful, and in some cases the damage is done before you even realize what happened. This isn't just an enterprise problem. It happens on solo side projects, open-source repos, and internal tools at startups. And the root cause is almost always the same: someone treated secrets like regular configuration and didn't have a clear strategy for keeping them out of version control, logs, and error messages. The patterns in this guide aren't bureaucratic overhead. They're the minimum viable approach for any app that talks to a real database or a real API. What Environment Variables Actually Are An environment variable is a key-value pair that lives in a process's environment — a set of values the operating system makes available to any running program. Every process inherits the environment of the process that spawned it. In Node.js, you access them through process.env : const port = process . env . PORT ; const dbUrl = process . env . DATABASE_URL ; In Python: import os port = os . environ . get ( ' PORT ' ) db_url = os . environ . get ( ' DATABASE_URL ' ) The core idea — and the reason env vars are the standard approach — is that they decouple what the app does from where it runs . The same application code can point at a local development database or a production cluster. The code doesn't change; only the environment does. This is the heart of the 12-Factor App principle: store config in the environment, not in the code. The .env File: What It Is and What It Isn't In local development, you don't set environment variables by hand before every terminal session. Instead, you use a .env file — a plain text file at the root of your project with one key

Modern applications depend on secrets. Every application requires: Database Passwords API Keys SSH Keys TLS Certificates Cloud Credentials OAuth Tokens Service Account Keys The biggest question is: Where should we store them securely? Unfortunately many organizations still store secrets in: Git Repository Docker Image Application Config Files Environment Variables Shared Documents Excel Sheets This creates a massive security risk. This is why Secret Management platforms like HashiCorp Vault became critical in modern cloud-native environments. 🔗 Resources ** Support the Journey on GitHub: If you're following along, consider starring and forking the repo:** https://github.com/17J/30-Days-Cloud-DevSecOps-Journey What is a Secret? A secret is any sensitive piece of information used to authenticate or authorize access. Examples: Database Password AWS Access Key JWT Signing Key API Token TLS Certificate Private Key OAuth Secret If a secret gets exposed: Attacker ↓ Application Access ↓ Database Access ↓ Infrastructure Compromise What is Secrets Management? Secrets Management is the process of: Store Protect Rotate Control Audit sensitive credentials securely. A modern secrets management platform provides: Centralized storage Encryption Access control Secret rotation Audit logs Dynamic credentials Why Secrets Management Matters Imagine this scenario: database : username : admin password : Password123 committed into GitHub. Result: Developer Pushes Code ↓ GitHub Repository ↓ Credential Leak ↓ Database Breach This happens more often than people realize. The Problem with Traditional Secret Storage Many teams use: .env Files Kubernetes Secrets Configuration Files Hardcoded Passwords Problems: Difficult rotation No audit trail Poor access control Risk of accidental exposure Compliance failures What is HashiCorp Vault? HashiCorp Vault is a centralized secrets management platform designed to securely store, access, and manage secrets. Think of Vault as: Central Secret Bank for you

Threat-intel reports from recent years document campaigns in which attackers obtain AWS IAM credentials from developer workstations, use them to enumerate cloud accounts and access Kubernetes clusters. From there, attackers deploy poisoned container images to move laterally and harvest secrets. The MITRE ATT&CK chain maps to: T1552.001 ( Credentials in Files ) → T1078.004 ( Valid Accounts: Cloud Accounts ) → T1610 ( Deploy Container ) → T1496 ( Resource Hijacking ). This is not an isolated case. The Shai-Hulud supply chain attack harvested Kubernetes credentials from CI and developer workstations, feeding exactly this kind of attack chain. This research started with a short list of questions: What are Kubernetes secrets, exactly? What can an attacker do with them? How can defenders harden their clusters? So before we look at what we found in the wild, and how to harden clusters to mitigate impacts, let's define what Kubernetes secrets are. Three Surfaces, Three Secret Formats A simplified view of the cluster has three sides that matter for this post: A developer, or automation pipeline, talks to the Kubernetes API server with credentials. That is the canonical front door. On every node, the kubelet exposes its own HTTPS API. The same credentials can authenticate to it directly when it is reachable on the network. The cluster's nodes pull images from container registries (Docker Hub, GitHub Container Registry, ECR, Quay, GitLab, ACR…) using a second set of credentials. Kubernetes Architecture These are the attack surfaces where leaked secrets have the most impact, and three secret formats unlock them: TLS client certificates are used by humans through a kubeconfig file with the kubectl command to connect to a Kubernetes cluster. JSON Web Tokens, or Service Accounts, are non-human identities (NHI) used to automate cluster operations from CI/CD jobs, controllers, and integrations. By default, JWTs have no expiration date — which is why a JWT leaked years ago can still