Software Development Security · Topic 2 of 4
Development Ecosystem Controls
Security controls for languages, libraries, IDEs, runtimes, CI/CD pipelines, code repositories and configuration management, plus SAST, DAST, IAST and SCA.
- 3 min
- Includes a diagram
- Every ecosystem element (languages, libraries, tools, IDEs, runtimes, pipelines, repositories) needs controls.
- SAST reads code; DAST tests the running app; IAST observes from inside; SCA checks dependencies.
- Protect pipelines: least privilege, independent approval of pipeline changes, ephemeral runners, signed artifacts.
What it is
The development ecosystem is everything used to build software: languages, libraries, tools, IDEs, runtimes, pipelines and repositories. Attackers increasingly target this ecosystem, because compromising a build can compromise every customer. Each element needs its own controls.
How it works
Ecosystem elements and controls
| Element | Risk | Controls |
|---|---|---|
| Programming languages | Memory-unsafe languages allow overflows | Prefer memory-safe languages where possible; secure coding standards |
| Libraries and dependencies | Vulnerable or malicious packages, dependency confusion | Software composition analysis, approved sources, private registries, lock files with hashes |
| Tool sets and IDEs | Malicious plugins, secrets in local files | Approved plugins, secret scanning, managed workstations |
| Runtimes | Vulnerable runtime versions | Patch and pin runtimes, container image scanning |
| CI/CD pipelines | Tampered builds, stolen credentials | Least-privilege pipeline accounts, protected pipeline definitions, ephemeral isolated runners, signed artifacts |
| Code repositories | Unauthorized changes, leaked secrets | MFA, branch protection, required reviews, pull-request-only access for contractors |
| Configuration management | Untracked or drifting configuration | Version-controlled configuration, approved baselines |
| Test environments | Real data exposure | Masked or synthetic data |
If engineers can edit the pipeline definition that builds and checks their own code, they can disable the checks. Require independent approval for pipeline configuration changes.
Application security testing
| Tool | How it works | Finds |
|---|---|---|
| SAST (static) | Analyzes source code without running it | Unsafe data flows, insecure functions, early in development |
| DAST (dynamic) | Tests the running application from outside | Runtime and configuration issues, injection |
| IAST (interactive) | Agent inside the running app observes behaviour during tests | Flaws with precise code locations |
| SCA (software composition analysis) | Compares dependencies with known-vulnerability data and licences | Vulnerable or non-compliant libraries |
| Secret scanning | Looks for credentials in code and commits | Keys and passwords before they reach the repository |
| Fuzzing | Sends malformed input | Crashes and input-handling flaws |
Build integrity
- Build in clean, ephemeral environments so residue from one build cannot affect another.
- Sign artifacts and verify signatures at deployment.
- Record provenance (what was built from which source, by which pipeline).
- Keep a software bill of materials for each release.
Secrets in development
Do not store credentials in code or configuration files. Use secrets managers and short-lived credentials issued at run time, so a compromised laptop does not expose production credentials.
How the exam asks about this
- "Enforce a ban on deprecated cryptographic functions on every commit." A static analysis rule that fails the build.
- "Public package with a name like an internal one is pulled into builds." Private registry with namespace pinning.
- "Dependencies resolve to the latest release at each build." Lock files with hash verification.
What to remember for the exam
- Every ecosystem element (languages, libraries, tools, IDEs, runtimes, pipelines, repositories) needs controls.
- SAST reads code; DAST tests the running app; IAST observes from inside; SCA checks dependencies.
- Protect pipelines: least privilege, independent approval of pipeline changes, ephemeral runners, signed artifacts.
- No secrets in code; use vaults and short-lived credentials.
- Pin and verify dependencies.
A compromised build system can insert malicious code into signed, trusted releases. Protect the pipeline as carefully as production.
Common mistakes
Relying on annual attestations to enforce coding rules.
Letting builds pull the newest dependency versions automatically.
Using production data in test environments.
Check yourself
Which testing approach analyzes source code without executing it?
Static application security testing (SAST).
What does software composition analysis find?
Known-vulnerable or non-compliant third-party components.
Why use ephemeral build runners?
Each build starts clean, so residue or compromise from one build cannot carry into another.
Topic 2 of 4 in Software Development Security
Test yourself on Software Development Security
The full ISC2 CISSP question bank has 1,113 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISC2. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.