Software Securityhome
Fix a findingSearch
Phase 3 of 6

Development

Write code that keeps untrusted input, secrets and privileges in their place, with dependencies, reviews and a build pipeline you can trust.

Does the code keep untrusted input, secrets and privileges where they belong, and can the pipeline that builds it be trusted?

Start here: Fix a finding

Security practices in this phase

  1. Secure coding

    Use the safe API for each sink: bound parameters for SQL, argument arrays for commands, context-aware encoding for HTML, and allowlists for redirects and outbound requests.

    Done when: Each weakness class the change touches has a test that fails on the vulnerable pattern.

  2. Secrets out of code

    Load credentials at runtime from a secrets manager or the platform, and scan every commit for secrets.

    Done when: No secret is in the repository or its history, and a leaked one can be rotated without changing code.

  3. Dependency selection

    Check a new package’s maintenance, provenance and install scripts before adding it, pin it with a lockfile, and install only from the registry you intend.

    Done when: New dependencies are reviewed in the pull request, and the lockfile pins every one.

  4. Security code review

    Review pull requests for the boundaries they touch: input parsing, authorization checks, output encoding, secrets and error handling.

    Done when: Branch rules require an approving review from someone other than the author before merge.

  5. AI coding assistants

    Review assistant output like any other contribution, keep secrets out of prompts and context, and limit what coding agents may run or change.

    Done when: Generated code goes through the same review and checks, and agents run with scoped permissions.

  6. CI security checks

    Run static analysis, secret scanning and dependency checks on every pull request, and decide in advance which findings block a merge.

    Done when: The blocking criteria are written down, findings are triaged within an agreed time, and exceptions expire.

  7. Pipeline hardening

    Pin actions to commit SHAs and images to digests, give jobs least-privilege tokens, keep untrusted pull-request code away from secrets, and protect release branches.

    Done when: Workflow permissions are read-only by default, and release jobs cannot be triggered from forks.

Guides

121 guides

Also part of this phase

  • WEP: RC4 key reuse and weak IVsCase study · Identity & cryptography

    Separate WEP’s repeated-keystream failure, weak-IV key recovery, and unkeyed integrity weakness through a concrete two-packet exercise.

  • Lucky Thirteen and POODLE: two different oraclesCase study · Identity & cryptography

    Compare two CBC oracles by their signal, protocol rules, and attacker prerequisites instead of treating them as interchangeable padding bugs.

  • DROWN: one RSA key across incompatible protocolsCase study · Identity & cryptography

    Map an RSA key across services to see how an SSLv2 oracle could compromise TLS traffic on a different endpoint.

  • Sweet32: the cost of a small block sizeCase study · Identity & cryptography

    Read the 2016 Sweet32 demonstrations as evidence about traffic volume, repeated secrets, and session lifetime rather than treating a block-size threshold as an instant exploit.

  • Run Kubernetes workloads with only the privileges they needGuide · Runtime, cloud & APIs

    Review pod settings, service accounts and effective permissions together before treating a namespace as an isolation boundary.

  • Prove network and admission policies enforce the intended boundaryGuide · Runtime, cloud & APIs

    Verify allowed traffic and rejected deployments in the cluster instead of treating policy files as evidence of isolation.

  • Bound background jobs and make retries safeGuide · Runtime, cloud & APIs

    Keep queues, workers and paid dependencies within a defined budget when clients retry, cancel or disappear.

  • Case study: the Shai-Hulud npm worm (2025-2026)Case study · Software supply chain

    How a self-replicating npm worm turned stolen tokens into hundreds of infected packages in 2025, how its 2026 successors hijacked release pipelines and trusted publishing, what npm and GitHub changed in response, and the publishing, install and response practices that stop it.

  • Case study: the tj-actions/changed-files compromise (CVE-2025-30066)Case study · Software supply chain

    In March 2025 an attacker moved the version tags of a popular GitHub Action, and of a reviewdog action before it, to code that printed CI secrets into build logs. This case study traces the token chain back to one pull_request_target workflow, sizes the exposure, and shows how it was caught and which controls held.

  • Case study: the xz Utils backdoor (CVE-2024-3094)Case study · Software supply chain

    How a multi-year maintainer takeover planted a backdoor in xz Utils release tarballs, how build-time injection hid it from the git repository, why a performance anomaly exposed it, which systems shipped it, and what it teaches about reproducible builds and maintainer health.

  • Case study: the Codecov Bash Uploader compromise (2021)Case study · Software supply chain

    How a credential leaked through Codecov's Docker image process let an attacker change the Bash Uploader that many CI pipelines downloaded and ran, which sent their environment variables, and the secrets in them, to the attacker for two months in 2021.

  • Case study: event-stream and ua-parser-js, two npm package takeoversCase study · Software supply chain

    Two ways attackers took over popular npm packages: event-stream (2018), handed to a stranger who added a targeted, encrypted payload through a new dependency, and ua-parser-js (2021), whose maintainer's account was hijacked to publish versions that installed malware for four hours. Timelines, detection and the controls that stop both.

  • Case study: the polyfill.io CDN takeover (2024)Case study · Software supply chain

    How the sale of the polyfill.io domain and project in February 2024 turned a script tag on more than 100,000 websites into a channel for malicious redirects by June, why Subresource Integrity could not have protected it, and the controls that would have.

  • Harden managed Kubernetes on EKS, AKS and GKEGuide · Runtime, cloud & APIs

    Know what your provider secures and what you still own, then lock down API access, cloud identity, nodes, pod privileges and admission with settings that are generally available in Kubernetes 1.37, checked against the CIS and NSA/CISA baselines.

  • Keep HTTP services up under application-layer DDoSGuide · Runtime, cloud & APIs

    Bound every phase of an HTTP request, patch for the HTTP/2 attack classes, rate limit at the edge and the origin, and shed load deliberately, with nginx, Envoy and Node.js settings tested against slow clients and bursts.

  • Harden container images from Dockerfile to admissionGuide · Runtime, cloud & APIs

    Build minimal, non-root images pinned by digest, keep secrets out of every layer, then scan, sign and verify the exact digest before it runs with dropped privileges.

  • Harden the images you ship against CIS, STIG and SCAP benchmarksGuide · Runtime, cloud & APIs

    Hold each image your team ships (container base images, golden VM images, Kubernetes node images) to a published benchmark through a pinned SCAP Security Guide profile, scan every build with OpenSCAP, and fail the build on any failure that a deviation register does not explain with an owner, an approver and an expiry.

  • Case study: the LastPass breach (2022)Case study · Identity & cryptography

    How an attacker went from a compromised developer laptop to a DevOps engineer's home computer, the keys to LastPass's cloud backups and a copy of customer vaults; why each vault's safety then rested on its master password and PBKDF2 iteration count; and what it teaches about backup keys, privileged endpoints, KDF upgrades and unencrypted metadata.

  • Case study: the Okta support-system breach and session tokens in HAR files (2023)Case study · Identity & cryptography

    How a service account password saved to a personal browser profile let an attacker download customers' HAR files from Okta's support system, replay the session tokens inside them against five customers, and stay unseen for two weeks; and why HAR files are credentials, admin sessions need binding, and every exposed credential must be rotated.

  • Case study: Moffatt v. Air Canada, a chatbot that misstated the refund policy (2022-2024)Case study · AI security

    How an airline's website chatbot told a grieving customer they could claim a bereavement fare after travel, what the British Columbia Civil Resolution Tribunal decided in February 2024, and the grounding, testing and correction practices that keep an automated answer consistent with the policy it describes.

  • Case study: the Nx s1ngularity compromise and its AI-assisted payload (2025)Case study · AI security

    How a pull-request-title injection in a GitHub Actions workflow on an outdated branch gave an attacker the Nx npm token in August 2025, how the malicious versions tried to turn developers' own AI command-line tools into file-search agents, and the workflow, publishing and agent controls that stop the same chain.

  • Case study: the Amazon Q Developer extension compromise (2025)Case study · AI security

    How an over-scoped GitHub token, extracted from an AWS CodeBuild pull request build, let a threat actor commit code to the Amazon Q Developer extension for VS Code that shipped in version 1.84.0 in July 2025, why the injected code aimed at the Q Developer CLI failed, and the CI and AI-agent controls the incident argues for.

  • Case study: Storm-0558 and the forged Microsoft tokens (2023)Case study · Identity & cryptography

    How a stolen 2016 consumer signing key and a token validation gap let Storm-0558 read enterprise Exchange Online mail in 2023, and what the review board found about rotation, logging and culture.

  • Case study: ingress-nginx CVE-2025-1974 and the exposed admission webhook (2025)Case study · Runtime, cloud & APIs

    How an admission webhook open to the whole Pod network made ingress-nginx's configuration-injection bugs a 9.8 cluster-takeover risk in 2025, and what its 2026 retirement means.

  • Case study: First American's EaglePro document exposure (2019)Case study · Application security

    How sequential IDs in unauthenticated links exposed First American's title documents in 2019, after its own penetration test found the flaw and a clerical error let it go unfixed.

  • Case study: Spring4Shell (CVE-2022-22965)Case study · Application security

    How Spring's data binding let request parameters reach the class loader on JDK 9 and later in 2022, why the denylist workaround leaked, and what it teaches about framework-level mass assignment.

  • Case study: CrowdStrike Channel File 291 (July 2024)Case study · Application security

    How a CrowdStrike content update crashed Windows hosts in July 2024: a field-count mismatch hidden by wildcard tests, a missing bounds check, and no staged rollout.

Find your next answer

Type to search. Search runs in your browser.

Searches run in your browser, but the host can infer them from the index files they load. The address shows your search so you can bookmark or share it.