8.2 Secure Development Ecosystems & AppSec Testing
8.2 Secure Development Ecosystems & AppSec Testing
Secure software depends on far more than the lines of code written by a developer.
The software-development ecosystem includes the programming language, libraries, development tools, IDE, runtime, code repository, configuration-management process and CI/CD pipeline used to create and deliver the application.
If any part of that ecosystem is compromised, insecure, outdated or excessively privileged, the final software can be affected even when the application's own source code appears correct.
CISSP 8.2 therefore combines two major ideas: secure the environment that creates software, and test the software using complementary application-security techniques.
Secure the Ecosystem
Protect languages, tools, IDEs, runtimes, dependencies and repositories.
TRUST THE TOOLCHAIN CAREFULLYProtect the Delivery Flow
Secure CI/CD, configuration, machine identities, secrets and release artifacts.
PROTECT THE PATH TO PRODUCTIONTest From Multiple Angles
Use SAST, DAST, SCA and IAST for different forms of visibility.
NO SINGLE TEST SEES EVERYTHINGIdentify and Apply Security Controls in Software Development Ecosystems
The current ISC2 CISSP Exam Outline explicitly includes the following areas.
Understand that language choice, implementation and supported versions affect security.
Control third-party packages, frameworks, direct dependencies and transitive dependencies.
Secure compilers, package managers, build tools, scanners and other development utilities.
Protect the developer workspace, extensions, plugins, local credentials and configurations.
Secure the environment in which the application actually executes.
Protect automated build, test, package and deployment workflows.
Control versions, baselines, configuration items and traceability.
Protect source, branches, commits, access paths and repository automation.
Official 8.2 Topics
Where 8.2 Fits
Integrate security throughout the development lifecycle.
WHEN?
Secure the languages, tools, repositories, pipelines and testing environment.
WHERE & WITH WHAT?
Assess whether software-security activities are effective.
DOES IT WORK?
Assess the security impact of externally sourced software and services.
WHO BUILT IT?
Define and apply secure coding guidelines and standards.
HOW SHOULD CODE BE WRITTEN?
What Is a Software Development Ecosystem?
A development ecosystem is the collection of technologies, services, processes and identities that transform an idea into running software.
Source Code Is Only One Part of the Trust Chain
Who is authorised to create or approve changes?
Can the local environment or IDE be trusted?
Can source code be altered without authorised review?
Where do external packages come from and can their integrity be trusted?
Can the compiler, runner or build worker be manipulated?
Can automation be changed or abused to bypass security controls?
Can a release be replaced after it was built and tested?
Does the deployed application run with secure versions, permissions and configuration?
Think in a Chain of Trust
Programming Languages
Programming languages have different security characteristics, runtime models, ecosystems and failure modes.
CISSP does not require one universally "secure" language. The management-level question is: is the chosen language appropriate, supported, understood and securely configured for the system being built?
Use maintained language implementations and versions that continue to receive security fixes.
Consider memory handling, type systems, exception behaviour, concurrency, serialization and other language-specific risks.
Use appropriate security, hardening and diagnostic settings where supported.
Define which language versions, package sources and supporting tools are approved for organisational use.
A language is not secure merely because it has strong features; developers must understand how to use them correctly.
Plan how unsupported language versions and frameworks will be removed before they become long-term risk.
💬 Memory-Safe vs Memory-Unsafe Does Not Mean Secure vs Insecure Security properties reduce classes of risk, not every possible vulnerability
Some languages provide stronger automatic memory-safety protections than others. This can reduce entire categories of memory-corruption defects.
However, a memory-safe language can still contain:
Libraries, Frameworks & Dependencies
Modern applications reuse large amounts of third-party code.
A small application may depend on hundreds or thousands of components once transitive dependencies are included.
A component deliberately selected by the development team.
A component required by another dependency rather than chosen directly by the team.
Pin, constrain or otherwise manage versions in a controlled and repeatable way.
Use approved repositories and package sources rather than arbitrary downloads.
Where practical, verify that the component received is the expected component from the expected source.
Know which components and versions are included so security teams can respond when vulnerabilities are disclosed.
Update or replace components when risk changes, while managing compatibility and regression risk.
Eliminate unnecessary libraries to reduce attack surface and maintenance burden.
Direct and Transitive Dependencies
Your team may never have selected Library C, but your application may still contain and execute it.
📦 Dependency Supply-Chain Risks The library name can be trusted less than the evidence around it
A legitimate component contains a publicly known exploitable weakness.
The package itself intentionally contains harmful code.
A deceptive package name resembles a legitimate popular package.
A build resolves an unintended package from a public or higher-priority source.
A legitimate project account is abused to publish malicious code.
The dependency remains in use even though it no longer receives adequate maintenance.
SBOM - Software Bill of Materials
An SBOM is a structured inventory of software components.
It can help an organisation answer:
An accurate component inventory supports risk analysis and response. It does not prove that every component is trustworthy, vulnerability-free or correctly configured.
Development Tool Sets
Development tools can read source, execute code, resolve dependencies, create release artifacts and access credentials.
Transforms or executes code and may support security-related build options.
Combines source, dependencies and configuration into an artifact.
Resolves and retrieves external components.
Executes functional and security-related tests.
Analyses source, dependencies, running applications or runtime behaviour.
Creates trusted distributable artifacts and may access high-value signing keys.
Can create or modify production infrastructure through automation.
May have direct authority to alter production services.
The Code Review Was Perfect - The Build Was Compromised
Developers commit reviewed, secure source code.
An attacker compromises the build service and adds malicious code after source-code review but before the final artifact is created.
Integrated Development Environment - IDE
The IDE is often one of the most privileged systems in the development lifecycle.
It may access:
Manage plugins and extensions according to risk; they can execute code and access development data.
Keep the IDE and its components on supported security-maintained versions.
Avoid unnecessary long-lived secrets on developer workstations and use secure credential storage.
Developers and local tools should not require production-level privileges for ordinary development.
Separate sensitive environments and credentials where risk justifies it.
The developer workstation remains an endpoint and should be protected as such.
Runtime Security
The runtime is the environment in which software actually executes.
Use maintained runtime versions and frameworks that receive security fixes.
Run the application with only the permissions it requires.
Harden runtime settings, modules, debug options and administrative interfaces.
Provide runtime credentials through protected mechanisms rather than embedding them in source or images.
Use process, container, operating-system or platform isolation appropriate to the risk.
Treat runtime vulnerabilities as application risk even when application source code has not changed.
Code Repository Security
A code repository stores one of the organisation's most sensitive assets: the authoritative history of software changes.
Use authentication appropriate to the sensitivity of the repository; privileged access commonly warrants MFA or equivalent strong controls.
Limit who can read, write, administer, approve and automate changes.
Prevent unreviewed direct changes to important branches where appropriate.
Require risk-appropriate peer review or authorised approval for significant changes.
Detect and prevent credentials, private keys and tokens from being committed where possible.
Maintain useful history of commits, approvals, administrative actions and access events.
Scope repository automation identities narrowly and rotate/revoke credentials appropriately.
Protect repository availability and recoverability so source history is not a single point of failure.
A Controlled Repository Flow
Software Configuration Management - CM
Software configuration management controls the identity, version and authorised state of software configuration items throughout development and release.
Know which source, dependencies, settings, build files and other items form the software baseline.
Track controlled versions and changes over time.
Define an approved known state that can be referenced and reproduced.
Ensure changes are authorised and appropriately reviewed before they alter a baseline.
Know the current state and history of relevant configuration items.
Confirm that the delivered software corresponds to the intended controlled configuration.
Git or another version-control repository is an important tool, but software CM is the wider discipline of identifying, controlling, baselining and tracing software state.
Software Configuration Management Memory Aid
Continuous Integration & Continuous Delivery - CI/CD
CI/CD automates the path that takes software from source code through build, testing, packaging and release or deployment.
Security Controls for CI/CD
Treat pipeline definitions as sensitive code subject to controlled change and review.
Give build and deployment identities only the permissions they need.
Keep deployment credentials and signing keys out of ordinary source and logs.
Do not allow untrusted code to automatically inherit powerful production credentials.
Secure build agents, runners and workers because they execute source and handle artifacts.
Use risk-appropriate automated checks before promotion or deployment.
Protect release artifacts from modification after successful build and testing.
Link the deployed artifact to the source, pipeline and approvals that produced it.
Record security-relevant pipeline and administrative activity for investigation and accountability.
A failed or bypassed security check should produce a controlled outcome rather than silently deploying anyway.
🔑 Pipeline Secrets Are High-Value Assets Machine credentials can be more powerful than human credentials
A deployment token with permanent administrator rights is stored in a repository variable and can be read by every branch build.
Limit which trusted pipeline stages can obtain deployment credentials, restrict the credential's scope and lifetime, and protect the secret from logs and untrusted code.
The Build Passed - But Is This the Same Artifact?
A release passes all security checks.
After the scan, an attacker replaces the deployment package in the artifact store.
Application Security Testing
ISC2 explicitly names four examples:
SAST
Analyse source code, bytecode or similar static representations without requiring the application to be running.
LOOK AT THE CODEDAST
Send requests to a running application and observe its externally visible behaviour.
ATTACK THE RUNNING APPSCA
Identify software components and dependencies and assess known component risk.
CHECK WHAT YOU DEPEND ONIAST
Instrument the application and observe internal behaviour while the application is exercised.
WATCH FROM INSIDE WHILE IT RUNSSAST - Static Application Security Testing
SAST analyses application code or related static representations without requiring the application to be running.
Finding suspicious source patterns, data-flow problems, insecure API use and certain coding weaknesses early.
Can run in the IDE, on pull requests, during builds or as a scheduled analysis.
Can often identify the file, function or line associated with a finding.
May not understand the full runtime configuration, external environment or business workflow.
Poor tuning can create large volumes of false positives and reduce developer trust.
Provide fast feedback close to the developer, then combine with other forms of testing and review.
SAST Memory Aid
DAST - Dynamic Application Security Testing
DAST tests a running application from the outside by sending requests and observing responses and behaviour.
Input/output validation issues, some authentication problems, exposed interfaces and runtime/server configuration weaknesses.
DAST does not require source-code access to perform external testing.
Requires a functioning application deployment that can be safely tested.
Observes behaviour that actually occurs in the running application.
May have difficulty identifying the exact internal code path responsible for a problem.
Authentication, complex workflows and business logic may require additional configuration or skilled manual testing.
DAST Memory Aid
SCA - Software Composition Analysis
SCA focuses on the software components that make up the application.
Identify dependencies associated with known security advisories or vulnerabilities.
Expose components inherited indirectly through other libraries.
Support visibility into what third-party code is present.
Many SCA tools can also support licence and organisational policy checks.
A vulnerable component finding does not automatically prove the vulnerable function is reachable or exploitable in the application.
SCA does not replace SAST, DAST, IAST, code review or design analysis.
SCA Memory Aid
IAST - Interactive Application Security Testing
IAST instruments the application while it runs and observes internal behaviour as automated tests, developers or testers interact with the application.
The application must be executing while interactions take place.
Sensors or agents observe internal behaviour such as code paths, data flow and framework behaviour.
Can combine runtime evidence with internal application visibility.
Can provide detailed contextual findings during CI, QA or other controlled execution environments.
Coverage depends on which application paths are actually exercised during testing.
Instrumentation can introduce operational complexity and performance overhead that must be managed.
IAST Memory Aid
SAST vs DAST vs SCA vs IAST
| Technique | Needs Running App? | Main View | Strongest Clue | Typical Limitation |
|---|---|---|---|---|
| SAST | No | Source / static code representation | "Analyse code before runtime" | Limited runtime/environment context |
| DAST | Yes | External application behaviour | "Send requests to running app" | Limited internal code visibility |
| SCA | Not necessarily | Dependencies / components | "Which library/version is vulnerable?" | Does not test all custom application logic |
| IAST | Yes | Instrumented runtime + internal context | "Sensors observe app while tests run" | Only exercised paths are visible |
◻️ White Box, Black Box and Grey Box - Useful Mental Model But do not force every tool into an oversimplified label
The tester or tool has internal knowledge such as source code or architecture. SAST commonly fits this perspective.
The application is tested from the outside with little internal knowledge. DAST commonly fits this perspective.
The assessment combines runtime interaction with additional internal knowledge or instrumentation. IAST is often understood this way.
False Positives & False Negatives
The tool reports a vulnerability that investigation determines is not actually present or exploitable as reported.
Tool says YES - reality says NO.
A real vulnerability exists but the test or scanner fails to report it.
Tool says NO - reality says YES.
Fast Memory Aid
Why One Testing Technique Is Not Enough
| Question | Most Relevant View |
|---|---|
| Is there a suspicious code path? | SAST / Review |
| Does the running application expose exploitable behaviour? | DAST |
| Which third-party package is vulnerable? | SCA |
| Which internal runtime path produced the weakness? | IAST |
| Is the authorization workflow conceptually wrong? | Contextual Review / Manual Testing |
| Can the build pipeline itself be compromised? | Ecosystem / Pipeline Security |
Automated Testing vs Human Analysis
Fast, repeatable and scalable.
Better at context, design reasoning, chained attacks and business logic.
Security Gates
A security gate evaluates whether software should be allowed to move to the next stage.
Not every informational finding should automatically stop every release.
Material exploitable weaknesses may justify blocking promotion until resolved or formally treated.
Risk acceptance or temporary exceptions should be explicit, authorised, time-bounded where appropriate and traceable.
Improve rules and context so the gate produces useful signal rather than constant noise.
The Scanner Blocks Everything
A new security scanner is configured to fail the build for: every finding of every severity.
Developers receive hundreds of low-confidence findings and begin bypassing the scanner.
🕵️ Adjacent Useful Control - Secret Scanning Useful in the ecosystem, but not one of ISC2's four named AppSec testing examples
Repositories and pipelines can scan commits and files for patterns that appear to be:
🎲 Adjacent Useful Concept - Fuzz Testing Useful application-security testing, but not explicitly named in current 8.2 examples
Fuzzing supplies large volumes of malformed, unexpected or semi-random input and watches for crashes, hangs, memory errors or other abnormal behaviour.
Testing Environment Matters
Security tests can have side effects.
Avoid exposing sensitive production data unnecessarily during testing.
Some active tests can create load, errors or state changes.
Testing should occur within approved scope and rules of engagement.
Use representative non-production environments where appropriate for intrusive testing.
Some controls may still require carefully controlled production verification or monitoring because environments differ.
Remove test accounts, temporary credentials and debugging controls after testing.
AppSec Testing Memory Aid
Static code → Components → External runtime → Internal runtime
Where Different Tests Can Fit
| Development Point | Useful Security Activity |
|---|---|
| Developer / IDE | SAST rules, secure linting, secret detection |
| Pull Request | SAST, SCA, code review, policy checks |
| Build | SAST/SCA as appropriate, build integrity controls |
| Test Environment | DAST, IAST, integration security tests |
| Release Candidate | Risk-based security gate and evidence review |
| Operation | Monitor new component vulnerabilities and runtime risk |
🧠 45 CISSP Practice Scenarios Apply the ecosystem and AppSec-testing concepts
A development team wants to adopt a new programming language for an Internet-facing payment service.
Best security-first action?
Evaluate the language, supported versions, ecosystem, security characteristics and organisational ability to operate it safely before adoption.
A supported language version receives security fixes, but the application is still built using an obsolete unsupported version.
Primary concern?
The development ecosystem is relying on an unsupported component that may no longer receive security fixes.
A compiler can enable additional hardening and diagnostic options, but the build disables them to suppress warnings.
Better approach?
Use appropriate secure compiler and build settings, then investigate and resolve meaningful warnings rather than blindly suppressing them.
A developer adds a small library to simplify date handling. That library pulls in twelve additional packages.
What should security consider?
Transitive dependencies as well as the direct dependency.
A direct dependency is patched, but a vulnerable transitive dependency remains in the resolved dependency tree.
Which control is especially useful?
Software Composition Analysis - SCA.
A package name differs by one letter from a popular package and contains malicious code.
What type of ecosystem risk?
A malicious or deceptive dependency/package supply-chain risk, such as typosquatting.
Developers download libraries from random Internet locations because the official package repository is temporarily slow.
Primary security issue?
Uncontrolled dependency sourcing and weakened provenance/integrity assurance.
The source code is secure, but an attacker compromises the build tool and inserts malicious code into every release.
What does this demonstrate?
The development toolchain is part of the software security boundary.
An IDE extension has broad access to source code, terminals and developer credentials.
Security implication?
IDE plugins and extensions should be treated as privileged development tools and governed accordingly.
A developer stores a production API key in an IDE settings file that is later committed to source control.
Best lesson?
Protect secrets in both the developer environment and repositories; do not treat local development configuration as harmless.
An application is securely coded but runs on an unsupported application runtime with known vulnerabilities.
Which official 8.2 area?
Runtime security.
A web application process runs as an operating-system administrator even though it only needs access to one application directory.
Best principle?
Least privilege for the runtime identity.
A team patches application code but never updates the framework runtime or interpreter.
Primary problem?
Runtime and platform dependencies remain part of the attack surface and require maintenance.
A source-code repository allows password-only access for privileged maintainers.
Strongest general improvement?
Use stronger authentication and risk-appropriate access controls, such as MFA/SSO, for repository access.
Any developer can directly push to the protected production branch without review.
Which repository control is weak?
Branch protection and controlled change/review.
A CI service token has permanent administrator rights across every repository in the organisation.
Best improvement?
Reduce token scope and lifetime according to least privilege.
Nobody can determine which version of source code, configuration and dependencies produced a released binary.
Which 8.2 concept is weak?
Software configuration management and build traceability.
Two developers build the same release from different unrecorded configurations and get different results.
What is needed?
Controlled baselines and reproducible, traceable configuration management.
A CI/CD pipeline automatically builds, tests, packages and deploys each approved change.
What is the security focus?
Protect the pipeline, its identities, secrets, build environment, artifacts and security gates.
A pipeline stores deployment passwords directly in a readable YAML file.
Best control direction?
Use protected secret-management mechanisms rather than embedding secrets in pipeline code.
A self-hosted build runner used for untrusted pull requests also has credentials that can deploy to production.
Primary concern?
Excessive privilege and trust in the build runner; separate duties and credentials.
A build succeeds, but the artifact placed in the release repository is silently replaced before deployment.
Which property must be protected?
Artifact integrity and provenance.
Management wants evidence showing where a release came from and how it was built.
Useful concept?
Build provenance/attestation and traceability across the software supply chain.
A scanner reviews source code before the application is running.
Which testing approach?
SAST - Static Application Security Testing.
A team expects SAST alone to prove whether a runtime authentication flow can be bypassed.
Why is that weak?
SAST analyses code without observing the full running application and should be complemented by other testing.
A scanner sends requests to a running web application and evaluates the responses for exploitable behaviour.
Which testing approach?
DAST - Dynamic Application Security Testing.
The security team has no source code but can access a test deployment of the application.
Which automated technique may still be useful?
DAST.
The application is instrumented while automated tests exercise real functionality, and the tool observes code and data flow internally.
Which testing approach?
IAST - Interactive Application Security Testing.
A team wants runtime context plus visibility into internal code paths while tests execute.
Which technique best matches?
IAST.
A team wants to identify known vulnerable open-source packages and dependency versions.
Which testing approach?
SCA - Software Composition Analysis.
A scanner reports a vulnerable library but does not analyse the team's own authentication logic.
Which limitation?
SCA focuses on software components/dependencies; it does not replace testing of custom application code and behaviour.
A scanner repeatedly reports a vulnerability that investigation proves is not actually present.
What is this?
A false positive.
A real exploitable vulnerability exists but the scanner reports nothing.
What is this?
A false negative.
A pipeline blocks every build for any low-confidence informational finding.
What should management reconsider?
Risk-based gating, tuning and exception handling so controls remain effective and usable.
SAST reports nothing, but a manual reviewer spots a dangerous authorization assumption spanning several services.
Primary lesson?
Automated tools complement rather than eliminate skilled review and security engineering.
Developers routinely bypass the security scanner because it produces thousands of irrelevant findings.
Best response?
Tune the control, improve signal quality and governance, and fix the bypass path rather than merely demanding compliance.
A vulnerability scanner is marketed as a complete replacement for penetration testing.
CISSP view?
Automated AppSec testing and penetration testing provide different forms of assurance; one does not automatically replace the other.
A serious SAST finding appears minutes after code is committed instead of during a pre-release penetration test three months later.
Main benefit?
Earlier feedback and reduced cost/complexity of remediation.
A weakness appears only when the application is running with a particular server configuration.
Which family is more likely to observe it?
A runtime-aware approach such as DAST or IAST, depending on the testing setup.
An application passes SAST and SCA, but a user can transfer money from another customer's account by changing an identifier.
What does this show?
Passing automated scans does not prove business logic and authorization are secure; broader testing is still required.
Management asks whether security-testing metrics demonstrate that the software-security programme is working.
Which Domain 8 objective is closer?
8.3 - Assess the effectiveness of software security.
Developers ask which input-validation patterns and secure coding rules they should follow.
Which Domain 8 objective is closer?
8.5 - Define and apply secure coding guidelines and standards.
Which four AppSec testing examples are explicitly named by ISC2 in objective 8.2?
Answer?
SAST, DAST, Software Composition Analysis and IAST.
What is the main security lesson of the development ecosystem?
Best answer?
Source code is only one asset; languages, libraries, tools, IDEs, runtimes, repositories, configuration and pipelines can all affect software integrity and security.
Management asks for the central purpose of CISSP 8.2.
Best answer?
Identify and apply security controls across the software-development ecosystem and use complementary application-security testing techniques to reduce risk throughout software creation and delivery.
Recognise the Clue Words
Source Code / No Running App
Static analysis.
SASTRunning App / External Requests
Black-box style testing.
DASTDependencies / Packages / CVEs
Component analysis.
SCAInstrumented Running App
Runtime + internal context.
IASTDirect + Transitive Packages
Dependency tree.
Libraries / SCAIDE Extension / Plugin
Developer workstation risk.
IDE SecurityUnsupported Interpreter / Framework
Execution environment.
Runtime SecurityProtected Branch / Pull Request
Source-control governance.
Code RepositoryVersions / Baselines / Traceability
Controlled software state.
Configuration ManagementBuild → Test → Package → Deploy
Automated delivery flow.
CI/CDPipeline Token / Deployment Secret
Machine identity.
Least Privilege + SecretsArtifact Replaced After Build
Supply-chain tampering.
Integrity / ProvenanceScanner Finding That Is Not Real
Noise.
False PositiveReal Issue Scanner Misses
Coverage gap.
False NegativeScanner Causes Constant Bypass
Control usability.
Tune the ControlBusiness Logic Flaw
Workflow/authorization reasoning.
Manual / Contextual TestingProgramming Language Choice
Security properties and support.
Language RiskMalicious Package
Dependency supply-chain risk.
Library / Package ControlsDoes Testing Work?
Programme effectiveness.
8.3How Should Code Be Written?
Coding rules.
8.5⚠️ Common CISSP Mistakes Do not confuse the tool with the security outcome
SAST examines code or related static representations without requiring the application to be running. DAST evaluates a running application from the outside.
DAST can test a running application without understanding all internal code paths.
SCA focuses on third-party components and dependencies; SAST primarily analyses custom source or compiled code for suspicious patterns and weaknesses.
IAST observes a running application from inside through instrumentation while interactions occur; DAST primarily observes externally.
Different techniques see different parts of the problem space and all can miss vulnerabilities.
A clean scan may still contain false negatives or uncovered logic and design weaknesses.
Scanner output requires appropriate triage, context and risk analysis.
Too much noise can cause alert fatigue, delay delivery and encourage bypass.
Automation can accelerate insecure actions just as effectively as secure ones.
Credentials used by automation can provide powerful access and require strong protection.
A repository controls highly sensitive intellectual property, change history and often the path to production.
Protected branches can improve change control but do not prove that approved code is secure.
Strong authentication does not justify excessive permissions.
Dependencies and their vulnerabilities change over time.
Transitive dependencies can introduce risk even when developers never selected them directly.
An SBOM describes software components; it can support vulnerability management but does not itself prove components are safe.
A securely coded application can still be exposed by an insecure or unsupported runtime.
Extensions may execute code and access source, secrets and developer sessions.
Software CM is broader than a repository; it includes identifying, controlling, baselining and tracing software configuration items.
8.2 applies controls in the development ecosystem and performs AppSec testing. 8.3 evaluates whether software-security activities are effective.
8.2 secures the ecosystem and applies AppSec testing. 8.5 focuses on secure coding guidelines, standards and source-level weaknesses.
Quick Reference
| If you see... | Think... |
|---|---|
| Code examined before runtime | SAST |
| Running app tested externally | DAST |
| Known vulnerable dependencies | SCA |
| Instrumented application during execution | IAST |
| Developer language / compiler / interpreter | Programming Language Controls |
| Direct or transitive package | Library / Dependency Controls |
| Compiler, package manager, scanner, build system | Tool Set Security |
| Editor extension, local debugger, developer workstation | IDE Security |
| JVM, .NET runtime, Python runtime, application server | Runtime Security |
| Build → test → package → deploy | CI/CD |
| Version, baseline, configuration item, traceability | Software Configuration Management |
| Branch, pull request, commit, repository token | Code Repository Security |
| Pipeline credential | Secrets + Least Privilege |
| Release artifact tampering | Integrity / Provenance |
| Scanner reports nonexistent issue | False Positive |
| Scanner misses real issue | False Negative |
| Tool generates unusable noise | Tuning / Risk-Based Gating |
| Custom workflow or authorization abuse | Contextual / Manual Testing |
| Measure whether security programme works | 8.3 |
| Secure coding rules and standards | 8.5 |
8.2 Ecosystem Memory Aid
Protect what writes it, what builds it, what moves it, what runs it and what tests it.
Four Official AppSec Tests
SAST sees code. DAST sees behaviour. SCA sees dependencies. IAST sees runtime from inside.
The Secure Development Leader's 8.2 Questions
Key Takeaways
CISSP 8.2 is: Identify and apply security controls in software development ecosystems.
The current ISC2 outline explicitly includes programming languages, libraries, tool sets, Integrated Development Environments, runtimes, CI/CD, software configuration management, code repositories and application security testing.
The four application-security testing examples explicitly named by ISC2 are: SAST, DAST, Software Composition Analysis and IAST.
The central security principle is: the development ecosystem is part of the software's security boundary.
Source code can be correct while the final release is still compromised through an insecure dependency, malicious IDE extension, vulnerable runtime, compromised build server, over-privileged CI/CD token or tampered release artifact.
Programming-language choice affects security characteristics, but there is no universal language that makes software secure automatically.
Use supported language implementations, frameworks and runtimes, apply appropriate security settings and retire obsolete versions.
Libraries introduce both direct and transitive dependencies.
A dependency can create risk even when developers did not select it directly.
Dependency controls should consider approved sources, version management, integrity, provenance, maintenance, inventory and removal of unnecessary components.
SCA helps identify software components and known component risk.
But: SCA ≠ complete application-security testing.
SBOMs improve component visibility and can support vulnerability response.
But: SBOM ≠ proof that software is secure.
Development tools are trusted software.
Compilers, package managers, build systems, scanners, deployment tools and signing tools may have enough authority to alter software or production environments.
A compromised build tool can undermine otherwise secure reviewed source code.
IDEs and developer workstations can access source code, terminals, repository tokens, cloud credentials, local secrets and debugging interfaces.
IDE plugins and extensions should therefore be treated as software with meaningful privilege rather than harmless conveniences.
Runtime security matters because the application executes within a language runtime, framework, application server, container or other platform.
Secure application code does not compensate for an unsupported or over-privileged runtime.
Code repositories require strong authentication, least privilege, controlled administrative access, appropriate branch protection, review, auditability and protection of automation credentials.
Repository security is not only about confidentiality of source code.
It also protects: integrity of the software-change history and the path to production.
Software configuration management is broader than version control.
It helps identify configuration items, control versions, establish baselines, authorise changes, track status and verify that the intended software state was released.
CI/CD pipelines commonly transform source through build, test, package and deployment stages.
Pipeline identities and secrets can therefore be extremely powerful.
Apply least privilege to machine identities just as you would to human administrators.
Do not give untrusted code automatic access to production credentials.
Protect build runners and workers because they execute source and may handle credentials, dependencies and release artifacts.
Protect artifact integrity after testing.
A release that passed every scan can still become malicious if the final artifact is replaced before deployment.
Traceability and provenance help answer: which source, dependencies, build process and approvals produced this release?
SAST analyses source code or other static representations without requiring a running application.
It is useful for early feedback and can often identify the location of suspicious code.
But: SAST may lack full runtime, environmental and business-context visibility.
DAST tests the running application from the outside.
It can observe exploitable behaviour without requiring source-code access.
But: DAST may have limited visibility into the internal code path that caused the issue.
SCA focuses on third-party components and dependencies.
A reported vulnerable component is a reason to investigate and manage risk. It does not automatically prove that the vulnerable function is reachable or exploitable in the specific application.
IAST instruments a running application and observes internal behaviour while the application is exercised.
Its coverage therefore depends in part on which application paths are actually executed during testing.
False positives are findings that are reported but are not actually present as reported.
False negatives are real vulnerabilities that testing fails to detect.
Therefore: zero findings ≠ zero vulnerabilities.
Automated security testing is valuable because it is repeatable, scalable and can provide fast feedback.
But: automation ≠ complete security assurance.
Skilled human analysis remains important for architecture, complex authorization, business logic, chained attacks and risk interpretation.
Security gates should be risk-based and appropriately tuned.
A control that blocks every build for low-confidence noise may cause teams to bypass or distrust the control.
The mature response is to improve the signal, governance and exception process while preserving meaningful protection.
Remember the Domain 8 boundaries:
8.1 = integrate security through the lifecycle.
8.2 = secure the development ecosystem and apply AppSec testing.
8.3 = assess whether software-security activities are effective.
8.4 = assess the security impact of acquired software.
8.5 = define and apply secure coding guidelines and standards.
The central CISSP principle for 8.2 is:
protect the people, tools, components, repositories, automation and runtimes that create software, and use multiple complementary testing techniques because no single scanner or control can see every software-security risk.
📚 Sources & Further Reading Current software-development ecosystem and AppSec references
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-218 - Secure Software Development Framework (SSDF) Version 1.1
View NIST SSDF - NIST - Secure Software Development Framework Project
View current SSDF project guidance - NIST SP 800-204D - Software Supply Chain Security in DevSecOps CI/CD Pipelines
View NIST CI/CD software-supply-chain guidance - NIST - Software Bill of Materials (SBOM) Guidance
View NIST SBOM guidance - OWASP DevSecOps Guideline
View OWASP DevSecOps guidance - OWASP DevSecOps Guideline - Static Application Security Testing
View OWASP SAST guidance - OWASP DevSecOps Guideline - Dynamic Application Security Testing
View OWASP DAST guidance - OWASP DevSecOps Guideline - Interactive Application Security Testing
View OWASP IAST guidance - OWASP - Source Code Analysis Tools
View OWASP source-code analysis references