Your Security Program Is a Dependency Graph, Not a Checkbox List

Bygaz

Why this matters right now

Most teams are still doing security as a department, not as a dependency graph.

They buy tools, wire alerts into Slack, and hope their cloud security posture management and secrets manager make them “secure enough.” Then an incident hits and they realize:

  • Identities don’t map cleanly to workloads.
  • Secrets are sprawled across repos, CI, and screenshots in Confluence.
  • Incident response plans are a PDF that nobody has read since onboarding.
  • Supply chain trust is an assumption, not a controlled input.

What’s changed is not the slogans (zero trust, shift left, etc.). What’s changed is the blast radius of a single design flaw:

  • One over-privileged CI role can let an attacker:
    • Pull all code,
    • Push a backdoor to a shared library,
    • Exfiltrate long-lived cloud credentials,
    • Disable logging.
  • One misconfigured OIDC trust from your GitHub to your cloud can become a permanent beachhead.
  • One compromised maintainer account in an open-source dependency can turn into production code execution in hours, not weeks.

Cybersecurity by design is about constraining those blast radii through the core architecture: identity, secrets, cloud posture, software supply chain, and incident response. If you build them as orthogonal afterthoughts, you will fight fires forever.

If you design them as a single system of record for “who/what can do what, where, and how fast we can force-rotate,” you can actually reason about risk.

What’s actually changed (not the press release)

Three structural shifts matter for engineering leaders:

  1. Identity has become the actual perimeter

    • Traditional perimeter: IP ranges, VLANs, VPNs.
    • Now: everything is public internet + mutual auth + identity.
    • Your effective perimeter is:
      • Your IdP (SAML/OIDC),
      • Your workload identities (cloud IAM roles, SPIFFE/SPIRE, service accounts),
      • And every integration target that trusts them.

    Consequence: A single identity misbinding or too-broad role assumption is equivalent to leaving a data center door open.

  2. Secrets and identities are now highly dynamic

    • Old world: static API keys in env vars for months.
    • New world: short-lived tokens, OIDC-based federation, workload identities.
    • But:
      • Many orgs adopt a secrets manager while keeping long-lived keys.
      • CI/CD and local-dev often bypass new mechanisms “temporarily.”

    Consequence: Your threat surface is the union of old and new patterns, and the old ones rarely get fully removed.

  3. Software supply chain is now a viable primary attack vector

    • Attackers target:
      • Package registries (npm, PyPI, etc.).
      • CI/CD systems.
      • Build scripts and plugins.
    • They only need one transitive dependency with:
      • No signature,
      • No pinning,
      • No provenance checks.

    Consequence: “We run SAST/DAST” is irrelevant if your build system is compromised.

  4. Incidents are faster and more automated

    • Ransomware, wormable exploits, automated spray attacks.
    • Offense has mature automation (scanning, credential stuffing, credential harvesting).
    • Most defenders still:
      • Rotate secrets manually,
      • Update firewall rules by ticket,
      • Validate logs by hand.

    Consequence: Manual response is increasingly equivalent to no response.

How it works (simple mental model)

Treat your security program as a directed graph with five main node types:

  1. Identities

    • Humans (engineers, contractors).
    • Machines (services, functions, CI jobs, batch tasks).
    • Third parties (SaaS integrations, vendors).

  2. Secrets

    • Credentials that bootstrap identity:
      • Passwords, SSH keys, API keys, TLS private keys.
    • And credentials that grant authorization:
      • Cloud access keys, DB credentials, OAuth tokens.

  3. Resources

    • Compute: VMs, containers, serverless.
    • Data: DBs, object storage, queues.
    • Control plane: IAM, KMS, DNS, network config, CI/CD.

  4. Supply chain artifacts

    • Source repos, dependencies, build scripts, container images, SBOMs.

  5. Response levers

    • What you can change fast:
      • Revoke tokens, rotate keys.
      • Disable users/roles.
      • Block network paths.
      • Redeploy clean images.

Now map edges as “can cause or change” relationships:

  • Identity → Resource (authorization)
  • Secret → Identity (bootstrap)
  • Supply artifact → Resource (deployed into)
  • Identity → Supply artifact (who can modify what)
  • Response lever → Identity/Resource/Secret (revocation/rotation)

Cybersecurity by design means:

  1. Constrain edges

    • Principle of least privilege is just: minimize edges and their power.
    • Example: CI job role can only:
      • Read a subset of repos,
      • Push to one registry,
      • Assume a narrow deploy role in one account.

  2. Shorten edge lifetimes

    • Prefer short-lived, derived credentials over long-lived secrets.
    • Example: Workload identity grants a 15-minute token for DB access, not a static password.

  3. Make response levers stronger than attacker levers

    • You must be able to:
      • Invalidate a compromised identity faster than it can propagate.
      • Rebuild from verified sources faster than malware spreads.

  4. Design for observability of critical edges

    • Log:
      • Who assumed what role, from where, for what action.
      • Supply chain changes (new dependency, new signing key).

If you can’t sketch this graph for your org at “crayon-level,” you will discover it under duress during an incident.

Where teams get burned (failure modes + anti-patterns)

1. IAM as a dumping ground

  • Single “admin-ish” role used by:
    • CI/CD,
    • Debugging scripts,
    • On-call engineers.
  • Broad permissions like *:* or “FullAccess” managed policies.
  • Human accounts with long-lived keys “just in case” automation breaks.

Result: One compromised credential = full environment compromise, including logs and backups.

2. Secrets manager as a fancy key-value store

  • Secrets vault exists, but:
    • Rotation is manual “when remembered.”
    • Orchestration doesn’t update consumers automatically.
    • People keep copies in .env, CI variables, wiki pages.

Result: Vault provides compliance comfort but doesn’t materially reduce credential exposure risk.

3. CI/CD as the soft underbelly

  • CI pipeline has:
    • Broad SSH keys or deploy keys across many repos.
    • Permission to create new IAM roles or modify network rules.
  • Build scripts curl | bash from arbitrary URLs.
  • No per-branch or per-environment isolation of permissions.

Real-world pattern:
An org had great production IAM hygiene but gave their Git-based CI system full admin in the prod account “for flexibility.” An attacker compromised a developer’s OAuth token, modified a build config to exfiltrate cloud credentials, then used CI’s admin rights to pivot into prod. Root cause: CI identity design, not missing scanners.

4. Over-trusting SSO and IdP integration

  • Assumption: “We use SSO, so we’re fine.”
  • Reality:
    • Poor group hygiene (everyone in “Engineering” group → prod access).
    • SCIM/role mappings are opaque and untested.
    • IdP logs rarely integrated into central security analytics.

Result: Misconfigured group grants unintended admin; no one notices until after abuse.

5. Incident response theater

  • Runbooks exist, but:
    • Not exercised under time pressure.
    • Not wired to real automation (e.g., “rotate keys” actually means “open a ticket”).
  • On-call doesn’t have:
    • Clear authority to disable risky systems.
    • A known minimal set of “kill switches.”

Real-world pattern:
A team experienced credential theft via a mis-routed logging sink. They knew they had to rotate secrets, but:
– No mapping from which secrets existed to which services.
– No automated rollout.
– Partial rotation left ghost credentials active for weeks.

Practical playbook (what to do in the next 7 days)

Assume you’re a lead or CTO with limited time. Aim for small, high-leverage design corrections, not a giant program.

Day 1–2: Establish a rough dependency graph

  1. Draw your core identities and resources

    On a whiteboard or doc:

    • Identities:
      • Human: “Eng”, “Ops”, “Contractor”.
      • Machine: “API service”, “Batch jobs”, “CI/CD”, “Monitoring”.
    • Resources:
      • Cloud accounts/projects.
      • Primary databases, object stores.
      • CI/CD, artifact registries.
      • Identity providers.

  2. Mark high-privilege identities

    For each identity, note:

    • Can it:
      • Change IAM policies?
      • Decrypt KMS keys?
      • Access production data stores?
      • Modify CI/CD config?

    If yes to multiple, mark as “Tier 0.” These are your crown-jewel identities.

Day 3: Tighten one critical IAM path

Pick one high-risk edge and fix it well:

  • CI/CD → Cloud:

    • Replace broad admin roles with:
      • Per-environment roles (dev/stage/prod).
      • Separate roles for build, deploy, and infra changes.
    • Enforce OIDC with audience and subject constraints where supported, instead of long-lived keys.

  • Human → Prod:

    • Remove long-lived keys for humans where possible.
    • Require just-in-time elevation for admin via approvals and time-bound roles.

Make the changes small but production-grade: tested, documented, and reversible.

Day 4: Fix one secrets lifecycle gap

Pick a single secrets class that touches production:

  • Example: DB credentials for your primary app.

Then:

  1. Move it into your secrets manager if not already there.
  2. Implement rotation that:
    • Can be performed without manual code change (e.g., app reads from manager at startup or on schedule).
    • Has a documented, tested runbook.
  3. Rotate once and verify:
    • All consumers reloaded the secret.
    • No hidden copies surfaced.

This gives you a template for other secrets.

Day 5: Supply chain minimum viable hardening

For your main production service:

  1. Pin dependencies

    • Use lockfiles (e.g., package-lock.json, poetry.lock, go.mod).
    • Disallow “latest” in critical paths.

  2. Restrict CI modifications

    • Limit who can change CI configs or workflows.
    • Require code review by a small, trusted group for:
      • Build scripts,
      • Deployment configs,
      • Package publishing scripts.

  3. Artifact provenance

    • Ensure:
      • Only CI builds can publish images or artifacts.
      • Artifacts are tagged with build metadata (commit hash, build ID).

You don’t need full-blown in-toto/SLSA in a week. You do need to remove “anyone can change build scripts and push to prod.”

Day 6: Minimum viable incident response

Answer, in writing, with names and commands:

  1. If a production credential is leaked, who can:

    • Rotate it.
    • Redeploy all affected services.
    • Validate that old credentials no longer work.

  2. If a high-privilege identity is compromised, who can:

    • Disable it in the IdP.
    • Revoke sessions.
    • Inspect recent activity.

  3. What are your “emergency brakes”?

    • E.g., disable external traffic to an app via WAF or gateway.
    • Pause CI/CD pipelines.

Run a 60-minute tabletop with the on-call engineer and one product owner. No tools, just talk through a past or plausible incident and see where the plan breaks. Capture gaps.

Day 7: Decide one design rule you’ll enforce going forward

You cannot fix everything now. You can prevent future debt.

Pick one rule that fits your environment and communicate it clearly:

Examples:

  • “No new long-lived cloud access keys. All new workloads use OIDC-based credentials.”
  • “All new services must use the shared secrets manager; local .env is for dev only.”
  • “CI/CD cannot have direct admin access to prod; infra changes go through infra-as-code and a dedicated role.”
  • “No new dependencies without being pinned and passing automated checks.”

Document it in your engineering standards and enforce via code review and CI checks where possible.

Bottom line

Cybersecurity by design is not about buying more scanners or running more training. It’s about treating identity, secrets, cloud posture, supply chain, and incident response as one coherent control system.

If you:

  • Identify and constrain your Tier 0 identities,
  • Shorten secret lifetimes and centralize their lifecycle,
  • Reduce CI/CD blast radius and enforce provenance,
  • Make response levers real and rehearsed,

you gain something most teams don’t have: the ability to predict how your system fails under attack, and to bound how bad “bad” can get.

You won’t be perfect. You don’t need to be. You need to ensure that a single compromised key or misconfigured role is an incident, not an existential event—and that is purely a design choice, not a budget line.

Similar Posts