hunting-non-human-identity-and-secret-reachability

Solid

Hunt machine credentials that are live, over-privileged, and actually reachable, not just present. Covers non-human identities and secrets across code, configuration, and infrastructure definitions: API keys, service-account credentials, and long-lived tokens. Separates a secret that merely exists from one an attacker can reach and use, and adjudicates each by whether it is still valid, how much it grants, and whether an untrusted path leads to it. Use when reviewing secret exposure, machine identities, or the blast radius of a leaked credential, and when a scanner reports many secrets and you need to know which ones matter. A reachable, live, over-privileged credential is the finding.

AI & Automation 4 stars 1 forks Updated yesterday MIT

Install

View on GitHub

Quality Score: 80/100

Stars 20%
23
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Hunting non-human identity and secret reachability: existence is not the bug, reach is A secret scanner tells you a credential is present. That is a lead, not a finding. The questions that decide severity are different: is this credential still valid, how much does it grant, and can an attacker actually reach it? A dead key in old history is noise. A live, broadly scoped token that an untrusted path leads to is an incident. Machine identities now vastly outnumber human ones, so the volume is overwhelming; the method that matters is separating reachable and powerful from merely present. ## When to use - You are reviewing secret exposure or the machine identities in a system. - A scanner reports many secrets and you need to know which are exploitable. - You want the blast radius of a leaked credential, not just its location. ## Scope check Inventory and validate credentials in systems you own or are authorized to test, and test validity only against your own accounts. If you can't name the authorization, stop. ## The loop 1. **Inventory the machine identities and secrets.** Enumerate credentials across source, configuration, infrastructure definitions, build output, and runtime surfaces: keys, service-account credentials, and long-lived tokens. Record where each lives and which identity it belongs to. This is the candidate set, not the finding set. 2. **Determine reachability.** For each credential, ask who can reach where it sits. A secret in a public ...

Details

Author
UnboundCompute
Repository
UnboundCompute/security-agent-skills
Created
5 days ago
Last Updated
yesterday
Language
N/A
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

secret-detection

Keeping credentials out of source, and what to do once one is in: rotate before removing, because deleting the line does not un-leak it. Covers where a secret may live, safe .env templates, why a client-reachable config value is public, and running a scanner rather than eyeballing for patterns. Use when writing code that reads a credential, creating config or .env templates, before committing, or after discovering a secret in a repository.

22 Updated 1 weeks ago
ShieldNet-360
AI & Automation Solid

hunting-iam-privilege-escalation-paths

Hunt privilege-escalation paths in cloud identity and access management: a low-privileged principal that chains role assumptions, policy rewrites, role-passing, and over-broad trust relationships to reach an administrative or data-access principal. Covers the identity-to-permission-to-resource graph, the known escalation primitives (passing a more privileged role to a service, rewriting a policy to a permissive version, assuming a role whose trust condition is too loose), and the boundary controls that should stop the chain. Use when reviewing cloud IAM, role and policy configuration, or an identity graph. A reachable path from an untrusted principal to admin is the finding.

4 Updated yesterday
UnboundCompute
AI & Automation Solid

hunting-supply-chain-risks

Hunt for the ways an attacker gets code into your build without touching your repo: dependency confusion (a public package shadowing an internal name), typosquatting and slopsquatting (a package named after a model's hallucination), poisoned pipeline execution (untrusted input running as a build step), and over-privileged or injectable CI. Use when reviewing a build pipeline, a dependency manifest, an internal package registry, or a CI/CD configuration. The app code can be clean while the artifact you ship is not.

4 Updated yesterday
UnboundCompute