# DevSecOps Toolchain — Practical Map, Legacy vs Current > **Intro:** Books and courses age fastest in the tooling layer. The ideas often remain valid, but the product names, integration points, and recommended defaults change. This page keeps the useful old ideas while translating them into a 2026-friendly engineering map. ## How to read this page * **Legacy / older example** means “you will still encounter it in books, mature environments, or legacy estates.” * **Current 2026 preference** means “what a new or modernized implementation should normally favor today.” * **Still valuable idea** captures what survived the tooling churn. ## Cross-phase mapping | Phase | Legacy / older example | Current 2026 preference | Still valuable idea | | ------- | -------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------ | | Prepare | Heavy upfront review packets | lightweight risk questionnaire + delta threat modeling | review risk early, then revisit on change | | Develop | GitFlow everywhere | short-lived branches or trunk-based delivery with protected main | smaller changes are easier to review | | Develop | centralized security scanning factory | self-service IDE, pre-commit, and PR checks | security feedback should be close to developers | | Build | Docker Hub + Docker Content Trust | internal registry + cosign or Notation + SBOMs | artifact integrity must be verifiable | | Build | Clair or OpenSCAP only | Trivy and/or Syft + Grype, plus registry-native scanning | image and dependency scanning belong in the build path | | Test | DAST only before release | fast baseline DAST in CI plus deeper scheduled scans | scanners are useful, but must be tuned | | Test | manual review only for APIs | OpenAPI linting + contract review + targeted authz tests | API definitions are security artifacts | | Deploy | Jenkins job as the central deployment brain | GitHub Actions, GitLab CI, Jenkins-as-code, or GitOps depending estate | deployment must be repeatable and auditable | | Deploy | Elastic Beanstalk style imperative deploy examples | ECS, EKS, Kubernetes GitOps, serverless, or platform-native rollout controllers | deployment logic should be automated | | Operate | perimeter-only focus | workload, cloud, identity, API, and runtime telemetry together | layered defense matters more than one boundary | | Operate | packet-centric IDS as the main runtime signal | runtime detection + cloud events + audit logs + SIEM/SOAR | detection needs multiple event sources | ## Tooling translation matrix | Older product or pattern | What happened | 2026 note | | -------------------------------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Docker Content Trust / Notary v1 | widely cited in older container-security material | plan for cosign or Notation; DCT retirement is in progress | | Twistlock | older container security product name | now Prisma Cloud Compute / Prisma Cloud workload capabilities | | Dome9 | older CSPM name | now part of Check Point CloudGuard | | Signal Sciences | standalone name in older AppSec material | now Fastly Next-Gen WAF, powered by Signal Sciences | | Scout2 | older AWS-only posture tool name | ScoutSuite is the maintained multi-cloud successor | | SourceClear | older SCA product name | use current Veracode SCA, Dependency-Track, or other actively maintained SCA platforms | | Puppet/Chef everywhere | common in older infra-automation books | still present in some estates, but Ansible, cloud-init, Terraform/OpenTofu, and Kubernetes-native patterns are more common for new work | | Jenkins-only delivery model | classic CI/CD pattern | still valid in many enterprises, but not the only default | ## Practical old-versus-new snippets ### 1. Container signing #### Older pattern ```bash export DOCKER_CONTENT_TRUST=1 docker trust sign registry.example.com/team/app:1.2.3 ``` #### Modern pattern ```bash cosign sign --keyless registry.example.com/team/app:1.2.3 cosign verify --certificate-oidc-issuer https://token.actions.githubusercontent.com \ registry.example.com/team/app:1.2.3 ``` **What stayed true:** do not treat unsigned mutable tags as trustworthy release evidence. ### 2. Dependency and image scanning #### Older but still usable ```bash dependency-check.sh --scan . --format HTML --out reports/ ``` #### Modern container and SBOM pattern ```bash syft dir:. -o cyclonedx-json > sbom.json grype sbom:sbom.json --fail-on high ``` **What stayed true:** you need a dependency inventory and a repeatable way to fail or triage serious findings. ### 3. Cloud posture checks #### Older AWS-only style ```bash Scout2 --profile audit-readonly ``` #### Modern alternatives ```bash prowler aws --profile audit-readonly --compliance cis_aws_1.5_0 scout.py aws --profile audit-readonly ``` **What stayed true:** cloud security review should start with API-visible configuration state, not noisy active scanning. ### 4. Kubernetes runtime detection #### Older example from early Falco material ```bash helm repo add falcosecurity https://falcosecurity.github.io/charts helm install falco falcosecurity/falco ``` #### Current 2026-friendly version ```bash helm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update helm install falco falcosecurity/falco \ --namespace falco --create-namespace \ --set tty=true ``` **What stayed true:** runtime detection is most useful when paired with tuned rules, routing, and response playbooks. ## What to modernize first in an older estate 1. replace deprecated or retiring signing paths; 2. add SBOM generation to builds; 3. move secret scanning and contract linting earlier; 4. replace archived posture tools with maintained ones; 5. modernize runtime detection routing and output handling; 6. revisit legacy branch and approval models that exist only because the tools used to require them. ## Decision rule Do **not** modernize tooling just because it is newer. Modernize it when one of these is true: * the old tool is archived, retiring, or operationally painful; * the old integration cannot express the control you now need; * the modern option gives materially better evidence, lower noise, or better automation; * you are rebuilding the surrounding pipeline anyway. ## Related pages * [Develop Phase — Practical DevSecOps Controls](/devsecops-cicd-and-supply-chain/index/develop.md) * [Test Phase — Fast Gates, Deep Tests, and What Still Belongs Out of Band](/devsecops-cicd-and-supply-chain/index/test.md) * [Software Supply Chain Foundations](/devsecops-cicd-and-supply-chain/index-1/software-supply-chain-foundations.md) * [Falco for Runtime Detection — Practical Guide, Legacy Notes, and 2026 Patterns](/attack-paths-testing-detection-and-hardening/index/falco-runtime-detection-practical-guide.md) \---*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.* --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.product-security.expert/devsecops-cicd-and-supply-chain/index/devsecops-toolchain-practical-map-legacy-vs-current.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.