AI Security in CISSP Domain 8: Software Development Security

AI is transforming software development. Developers can now generate code, tests, documentation, configurations, and even complete application components in seconds.

But speed creates a dangerous illusion:

For CISSP Domain 8 — Software Development Security — candidates should think beyond using AI as a coding assistant. AI affects the entire Software Development Life Cycle (SDLC): requirements, architecture, development, testing, deployment, maintenance, supply-chain security, and change management.

The central CISSP question is:

The Domain 8 mindset is:

Define security early. Validate everything. Trust no generated code by default.

Why AI Security Matters in CISSP Domain 8

AI can now participate throughout software development:

• generating source code;

• suggesting fixes;

• reviewing code;

• creating test cases;

• finding vulnerabilities;

• generating infrastructure configurations;

• producing documentation;

• creating APIs;

• selecting libraries;

• analyzing dependencies;

• generating scripts; and

• assisting DevSecOps pipelines.

Organizations may also develop AI-enabled applications containing:

• foundation models;

• RAG systems;

• vector databases;

• AI agents;

• model APIs;

• plugins;

• training pipelines; and

• third-party AI components.

This creates two distinct security concerns:

Using AI to develop software securely

and

Developing AI-enabled software securely.

Both belong naturally in Domain 8.

1. Secure AI Begins in the SDLC

A common security failure is adding controls after development is complete.

AI does not change this.

Security requirements should be incorporated during:

Requirements → Design → Development → Testing → Deployment → Operations → Retirement

For an AI-enabled application, requirements might address:

• authentication;

• authorization;

• data protection;

• prompt handling;

• model access;

• logging;

• output validation;

• privacy;

• agent privileges;

• human approval;

• secure failure; and

• third-party dependencies.

CISSP Exam Thinking

Fixing security weaknesses earlier in the lifecycle is generally more efficient and less costly than correcting them after deployment.

2. AI-Generated Code Is Untrusted Until Validated

Generative AI can produce convincing source code extremely quickly.

That code may also contain:

• insecure functions;

• weak input validation;

• injection vulnerabilities;

• authentication flaws;

• authorization errors;

• exposed secrets;

• insecure cryptography;

• outdated dependencies;

• logic errors; or

• nonexistent libraries.

The fact that code compiles does not mean it is secure.

The fact that AI confidently explains the code does not mean it is correct.

CISSP Principle

AI-generated code should pass through the organization's normal software assurance processes.

3. Developers Remain Accountable for AI-Generated Code

An important misconception is:

“The AI wrote it, so the AI is responsible.”

It is not.

Organizations and authorized personnel remain responsible for software they deploy.

Developers using AI assistants should understand:

• what the generated code does;

• what dependencies it introduces;

• whether it meets security requirements;

• whether it exposes sensitive information; and

• whether it has been appropriately tested.

CISSP Insight

AI can generate code. It cannot accept organizational accountability for deploying insecure software.

4. Never Put Secrets Into Unapproved AI Coding Tools

Developers may unintentionally submit sensitive information while requesting help from generative AI.

Examples include:

• API keys;

• passwords;

• access tokens;

• private keys;

• source code;

• vulnerability details;

• customer information;

• internal architecture;

• proprietary algorithms; and

• confidential configuration.

This can create data exposure and third-party risk.

Organizations should define acceptable-use requirements for AI development tools.

Exam Thinking

Before asking whether an AI coding assistant is convenient, ask:

What information is being shared, what is its classification, and is the processing authorized?

5. AI Does Not Replace Secure Coding Practices

AI-generated software remains subject to traditional application-security risks.

Developers still need to address:

• input validation;

• output encoding;

• authentication;

• authorization;

• session management;

• error handling;

• memory safety;

• secure cryptography;

• secrets management;

• injection prevention; and

• least privilege.

AI may help implement these controls.

It can also implement them incorrectly.

CISSP Rule

6. Prompt Injection Is an Application Security Problem

Prompt injection is not only an AI-model problem.

It can become an application security vulnerability when untrusted input influences an AI-enabled application's behavior.

For example, malicious content might attempt to make an AI application:

• ignore system instructions;

• reveal protected information;

• retrieve unauthorized documents;

• invoke tools;

• execute workflows; or

• generate unsafe output.

Secure development should therefore treat external prompts and retrieved content as untrusted input.

Controls may include:

• input handling;

• privilege restrictions;

• trusted/untrusted context separation;

• output validation;

• tool restrictions;

• authorization enforcement; and

• monitoring.

CISSP Insight

Never assume that natural-language input is harmless simply because it is not traditional executable code.

7. AI Output Must Be Validated

Traditional applications validate user input.

AI-enabled applications may also need to validate model output.

Why?

Because an AI response might be:

• inaccurate;

• maliciously influenced;

• improperly formatted;

• unauthorized;

• sensitive;

• unsafe to execute; or

• inconsistent with business rules.

This becomes especially important when AI output is passed to:

• databases;

• APIs;

• operating systems;

• interpreters;

• automation tools; or

• other applications.

CISSP Principle

This is particularly critical for AI agents.

8. AI Agents Increase Application Risk

A chatbot typically produces information.

An AI agent may take action.

It may:

• modify files;

• query databases;

• call APIs;

• deploy software;

• execute code;

• send messages;

• create accounts; or

• change cloud resources.

This transforms model error into potential operational impact.

Secure development should restrict:

• agent permissions;

• available tools;

• accessible systems;

• API scopes;

• execution environments; and

• autonomous actions.

High-impact actions may require explicit approval.

CISSP Exam Thinking

9. RAG Applications Must Enforce Authorization

Retrieval-Augmented Generation connects AI systems with external information sources.

A typical application may operate as:

User → Application → Retrieval Layer → Vector Database → Model → Response

Developers must ensure the retrieval layer does not expose information outside the user's permissions.

Common risks include:

• excessive retrieval permissions;

• sensitive data leakage;

• malicious documents;

• cross-user data exposure;

• insecure vector databases; and

• authorization bypass.

CISSP Principle

The AI application must preserve the authorization rules of the underlying systems.

The model should never become a shortcut around access control.

10. AI Software Supply Chains Require Scrutiny

Modern AI development may rely on:

• pretrained models;

• open-source libraries;

• datasets;

• plugins;

• APIs;

• development frameworks;

• model repositories;

• container images; and

• cloud AI services.

Each dependency introduces potential risk.

A malicious or compromised component could affect the application even if the organization's own source code is secure.

Security teams should consider:

• provenance;

• trusted sources;

• dependency versions;

• known vulnerabilities;

• integrity;

• licensing;

• update processes; and

• supplier risk.

CISSP Insight

AI makes that supply chain larger—not less important.

11. AI Can Hallucinate Dependencies

An AI coding assistant may recommend a library or package that:

• does not exist;

• is obsolete;

• is insecure;

• has been abandoned; or

• comes from an untrusted source.

Attackers may exploit this behavior by creating malicious packages using names commonly hallucinated by AI systems.

Developers should therefore verify dependencies before installation.

CISSP Exam Thinking

Do not install a dependency merely because an AI system recommended it.

Verify:

source → authenticity → integrity → security → business need

12. SAST and DAST Still Matter

AI-assisted development does not eliminate established application-security testing.

Static Application Security Testing (SAST) analyzes source code or related representations without executing the application.

Dynamic Application Security Testing (DAST) evaluates a running application from an external or runtime perspective.

Both can identify different classes of weaknesses.

AI may enhance these tools, but the underlying distinction remains important for CISSP.

Exam Trap

Remember:

SAST → examine code without running the application

DAST → test the running application

Neither alone provides complete assurance.

13. Software Composition Analysis Matters More, Not Less

AI-generated code may rapidly introduce external libraries and dependencies.

Software Composition Analysis (SCA) helps organizations identify:

• third-party components;

• known vulnerabilities;

• dependency versions;

• licensing concerns; and

• software supply-chain exposure.

This becomes increasingly important when developers accept AI-generated suggestions without fully understanding every dependency.

CISSP Insight

Faster development increases the need for disciplined dependency management.

14. Code Review Remains Essential

AI can assist code review.

It should not necessarily be the only reviewer.

Human or independent review may identify:

• business-logic flaws;

• inappropriate assumptions;

• authorization weaknesses;

• architectural problems;

• privacy concerns;

• insecure dependencies; and

• risks that automated tools lack context to understand.

For critical applications, organizations may combine:

developer review + peer review + automated analysis + security testing

CISSP Principle

Defense in depth applies to software assurance too.

15. DevSecOps Controls Should Apply to AI-Generated Code

AI can dramatically increase development velocity.

Security controls must keep pace.

DevSecOps can integrate security activities into CI/CD pipelines, including:

• SAST;

• DAST;

• SCA;

• secret scanning;

• infrastructure-as-code scanning;

• container scanning;

• security testing;

• approval gates; and

• deployment controls.

The objective is not to slow development unnecessarily.

It is to ensure faster development does not mean faster deployment of vulnerabilities.

CISSP Takeaway

16. Separate Development, Test, and Production

AI developers may want production data to improve testing or model performance.

That can create serious security and privacy risks.

Development and testing environments should be appropriately separated from production.

Where possible, testing should use:

• synthetic data;

• masked data;

• anonymized data; or

• otherwise appropriately protected information.

Production credentials and sensitive production data should not casually migrate into AI development environments.

CISSP Principle

Environment separation limits the impact of development mistakes and unauthorized access.

17. Change Management Applies to AI

An AI-enabled application can change even when traditional application code does not.

Significant changes may include:

• switching models;

• changing system prompts;

• updating datasets;

• modifying RAG sources;

• fine-tuning a model;

• adding plugins;

• granting new agent capabilities;

• changing API permissions; or

• updating safety controls.

These changes can affect system behavior and security.

They should therefore receive appropriate:

• authorization;

• testing;

• documentation;

• version control;

• rollback planning; and

• post-change validation.

CISSP Insight

18. AI Models Need Version Control and Configuration Management

Organizations should know:

• which model is deployed;

• which version is approved;

• what configuration is active;

• which system prompt is in use;

• what tools are connected;

• which datasets support the system; and

• what changed between releases.

Without configuration management, troubleshooting and incident response become much harder.

CISSP Principle

You cannot reliably secure what you cannot identify and reproduce.

19. AI Security Testing Must Include Abuse Cases

Traditional functional testing asks:

Does the system perform the required function?

Security testing also asks:

How can the function be abused?

For AI applications, abuse cases may include:

• prompt injection;

• sensitive-data extraction;

• unauthorized retrieval;

• excessive tool use;

• privilege escalation;

• model manipulation;

• resource exhaustion; and

• malicious output chaining.

CISSP Exam Thinking

Testing only the expected path is insufficient.

Security testing must examine how an attacker might misuse the system.

20. Secure Failure Is Essential

What should happen if:

• the model becomes unavailable;

• authorization fails;

• output validation fails;

• a tool call is rejected;

• suspicious activity is detected; or

• confidence is insufficient?

The system should generally move toward a safe state, not silently reduce protection.

For example, an AI agent should not gain broader privileges because its normal authorization service is unavailable.

CISSP Principle

The CISSP AI Secure Development Mental Model

When an AI-related Domain 8 question appears, think:

Requirements → Secure Design → Controlled Development → Code Review → Security Testing → Deployment Controls → Monitoring → Change Management

For AI specifically, add:

Validate Input → Restrict Model/Agent → Validate Output → Verify Dependencies → Preserve Authorization

Then ask:

Was security defined before development?

Is AI-generated code being independently validated?

Are secrets protected?

Are dependencies trustworthy?

Can AI output trigger sensitive actions?

Does the application preserve access control?

Has the system been tested for abuse?

That is the Domain 8 mindset.

Example CISSP Question

A development team uses a generative AI coding assistant to accelerate a critical application. The AI produces a large amount of code that compiles successfully and passes basic functional tests.

What should the organization do NEXT?

A. Deploy the application because the generated code passed functional testingB. Trust the code because the AI model was trained on secure programming examplesC. Subject the generated code to the organization's normal code review and security-testing processesD. Disable all AI-assisted development

Best answer: C

Compilation and functional testing establish that the software can operate as expected under tested conditions.

They do not establish that the code is secure.

AI-generated code should therefore undergo the same appropriate:

review → analysis → security testing → approval

as other code.

Exam Thinking

CISSP does not require rejecting useful technology.

It requires managing the risk created by that technology.

The best answer is neither blind trust nor blanket prohibition.

It is controlled adoption within established secure-development processes.

High-Yield AI Security Rules for CISSP Domain 8

Remember these principles:

1. Integrate AI security requirements throughout the SDLC.

2. Treat AI-generated code as untrusted until appropriately reviewed and tested.

3. Developers and organizations remain accountable for code they deploy.

4. Do not submit secrets or sensitive information to unauthorized AI development tools.

5. AI does not replace secure coding practices.

6. Treat prompts and retrieved content as potentially untrusted input.

7. Validate AI output before using it in sensitive downstream operations.

8. Restrict AI-agent privileges and available tools.

9. RAG applications must preserve underlying authorization controls.

10. Verify AI models, libraries, datasets, APIs, and other supply-chain dependencies.

11. Never trust an AI-recommended dependency without verification.

12. Continue using SAST, DAST, SCA, code review, and other software-assurance techniques.

13. Integrate security controls into DevSecOps and CI/CD pipelines.

14. Separate development, test, and production environments.

15. Treat model, prompt, dataset, plugin, and agent changes as potentially security-relevant changes.

16. Maintain version and configuration control for AI systems.

17. Test abuse cases, not only expected functionality.

18. Design AI-enabled software to fail securely.

Final CISSP Takeaway

Domain 8 provides one of the clearest lessons in the entire AI security discussion:

Every AI-generated function, dependency, configuration, prompt, model integration, and automated action must still earn that trust through secure design, review, testing, controlled deployment, and monitoring.

When an AI development question appears on the CISSP exam, resist two extremes:

“AI generated it, so trust it.”

and

“AI introduces risk, so prohibit it.”

The CISSP answer is usually more mature:

Understand the business value. Identify the risk. Apply secure SDLC controls. Validate the result. Maintain accountability.

AI may write the code.

The organization still owns the security of the software it deploys.