Building Secure Government and Compliance Software in the Age of AI
It Doesn't Matter Who Wrote the Code — It Still Has to Be Secure
A whitepaper on why AI-powered development demands the same (and often more) security rigor as traditional software engineering — and how to get it right for CMMC, SOC 2, and beyond.
The Problem
We are living in an unprecedented moment in software development. AI coding tools — from GitHub Copilot to Claude Code to Cursor — have fundamentally changed what a single developer or small team can build. Applications that once required months of engineering from a ten-person team can now be prototyped in days, sometimes hours. The barrier to entry for building functional software has never been lower.
And that is exactly the problem.
The rise of what Andrej Karpathy famously called "vibe coding" — fully trusting AI to handle implementation while you focus on the idea — has created a dangerous gap between what people can build and what they understand about what they have built. Developers are shipping code they have never read. Non-technical founders are launching SaaS platforms built entirely by AI without a single line reviewed by a human. Applications handling user data, financial transactions, and even government-regulated information are going live with security postures that would not survive a weekend on the open internet.
Recent research from Veracode found that 45% of AI-generated code contains known security vulnerabilities. That number has remained essentially unchanged even as the models themselves have gotten dramatically better at producing syntactically correct, functional code. The models compile. They run. They look right. But nearly half the time, they are introducing SQL injection vulnerabilities, cross-site scripting flaws, hardcoded secrets, insecure deserialization, and other issues from the OWASP Top 10 — the same classes of vulnerabilities that have been plaguing software for decades.
A study by Wiz found that 20% of vibe-coded applications had serious vulnerabilities or configuration errors. Real-world examples are already piling up: the startup Enrichlead, whose founder publicly boasted that 100% of the platform's code was written by Cursor AI with "zero hand-written code," was found to be riddled with basic security flaws just days after launch. Anyone could access paid features or alter data. The project was shut down.
For developers building general consumer applications, these risks are serious. For anyone building software that touches government data, handles Controlled Unclassified Information (CUI), or needs to meet compliance frameworks like CMMC or SOC 2, they are disqualifying.
The Solution
The solution is not to stop using AI. These tools are genuinely powerful, and they are not going away. The solution is to recognize a fundamental truth that applies regardless of who — or what — writes the code:
The software still has to be secure.
This means treating AI-generated code with the same scrutiny you would apply to code from an unknown junior developer. It means integrating static analysis, dynamic testing, and dependency scanning into every pipeline. It means designing your architecture for security from day one — not bolting it on after the fact. And for government and compliance work, it means understanding the specific frameworks, controls, and certification requirements that your software must satisfy before it ever touches production data.
This whitepaper walks through how to do all of that. It covers the security landscape of AI-generated code, the specific requirements of CMMC 2.0 and SOC 2 compliance, the architectural principles that must be baked into your design from the beginning, and the tools and processes that bridge the gap between AI-powered velocity and production-grade security.
Why AI-Generated Code Creates Unique Security Challenges
AI coding assistants are trained on publicly available code from repositories like GitHub. That training data includes millions of examples of insecure code, deprecated libraries, and outdated patterns. When the model generates code, it is synthesizing from everything it has seen — the good, the bad, and the vulnerable.
This creates several distinct risk categories that developers need to understand.
Inherited vulnerabilities from training data. The models reproduce patterns they have seen, including insecure ones. Lack of input validation, missing sanitization of user input, and other basic errors lead directly to classic vulnerabilities like cross-site scripting and SQL injection. The model does not inherently know that a pattern is insecure — it knows that the pattern is common.
Package hallucination and dependency risks. AI models sometimes reference packages that do not exist. Attackers have begun registering these hallucinated package names and filling them with malicious code, creating a novel supply chain attack vector. Even when the packages are real, the model may pull in deprecated or vulnerable versions of libraries without any awareness of their security status.
Over-reliance and false confidence. A Snyk survey revealed that nearly 80% of developers believe AI-generated code is more secure than human-written code. This is demonstrably false and creates a dangerous dynamic where code reviews are skipped, security testing is deferred, and vulnerabilities ship to production unchecked. The speed of AI-assisted development can actually make this worse — when you are shipping in hours instead of weeks, the pressure to skip security steps intensifies.
Lack of contextual understanding. AI models generate code based on prompts, not based on a deep understanding of your application's security requirements, threat model, or regulatory obligations. If you do not explicitly instruct the model to implement input validation, it probably will not. If you do not specify that you need FIPS 140-3 validated encryption for data at rest, you will get whatever default the model thinks is reasonable. The model does not know your compliance requirements, your data classification, or your threat landscape.
Configuration and infrastructure drift. Applications created through vibe coding are often built by users who either do not configure the runtime environment at all or configure it based on AI suggestions that prioritize functionality over security. Databases get created with overly broad external access permissions. Internal applications are left publicly accessible without authentication. Services run with elevated privileges they do not need. These infrastructure misconfigurations are often more dangerous than the code-level vulnerabilities themselves.
Static Analysis and Security Tooling: Your Non-Negotiable Safety Net
If there is one point this whitepaper needs to drive home, it is this: static analysis tools and security testing are not optional when building with AI. They are more important than ever.
The question is never "who wrote the code?" The question is always "is the code secure?" And the only way to answer that question with confidence is to run the code through the same rigorous analysis you would apply to any production software.
Static Application Security Testing (SAST)
SAST tools analyze source code, bytecode, or binaries to detect security vulnerabilities during development — before the code ever runs. For AI-generated code, SAST is your first line of defense.
OpenText Fortify (formerly Micro Focus Fortify), a Gartner Magic Quadrant Leader for Application Security Testing for 11 consecutive years, detects over 1,700 categories of vulnerabilities across 33+ programming languages. It covers more than one million individual APIs and supports 350+ frameworks. Fortify includes Aviator, an AI-powered feature that provides automated code fix suggestions for detected vulnerabilities — meaning you can use AI to fix what AI broke. It also supports infrastructure-as-code scanning for Terraform, Docker, Kubernetes, and serverless configurations, which is critical when your entire deployment stack may have been AI-generated.
Other enterprise-grade SAST options include Veracode, Checkmarx, and SonarQube. For teams looking for lighter-weight or open-source alternatives, Semgrep and CodeQL provide fast, developer-friendly static analysis that integrates directly into CI/CD pipelines.
The key is integration. SAST should not be something you run once before a release. It should be embedded in your development workflow — scanning code on every commit, flagging issues in pull requests, and blocking merges when critical vulnerabilities are detected.
Dynamic Application Security Testing (DAST)
While SAST examines code at rest, DAST evaluates running applications by simulating attacks against them. This is particularly important for AI-generated applications because DAST can catch runtime vulnerabilities that static analysis might miss: authentication bypasses, authorization failures, server misconfigurations, and exposed endpoints.
DAST is especially critical for vibe-coded applications where features may be created and abandoned rapidly, leaving behind active API endpoints that the developer (or the AI) has forgotten about but that an attacker can still reach.
Software Composition Analysis (SCA)
SCA tools track third-party libraries and dependencies — something that deserves special attention when AI is generating your code. AI tools frequently introduce libraries without explaining why they were chosen, and they may pull in vulnerable or deprecated dependencies. SCA tools monitor these dependencies for known vulnerabilities, validate licensing compliance, and can block the introduction of risky packages before they enter your codebase.
The Security Pipeline for AI-Generated Code
A mature security pipeline for AI-generated code should include all three layers working in concert. SAST catches code-level vulnerabilities before deployment. DAST validates runtime behavior in staging and production. SCA monitors the supply chain continuously. Together, they create a defense-in-depth approach that compensates for the security gaps AI models inevitably introduce.
CMMC 2.0: What You Need to Know for AI-Built Government Software
The Cybersecurity Maturity Model Certification (CMMC) 2.0 is the Department of Defense's framework for ensuring that defense contractors and subcontractors have the required safeguards in place to protect Controlled Unclassified Information (CUI) and Federal Contract Information (FCI). If you are building software that will be used in the defense industrial base, CMMC compliance is not optional — it is a gate for contract eligibility.
The Current Landscape
The final CMMC 2.0 program rule went into effect in late 2024, with the phased rollout beginning in November 2025. Phase 1 requires self-assessments and Supplier Performance Risk System (SPRS) score submissions as a pre-award condition. By November 2026, Phase 2 will require Certified Third-Party Assessor Organization (C3PAO) certification for all new contracts involving CUI. By 2027, full implementation across the defense industrial base is expected.
CMMC 2.0 operates with three tiered levels. Level 1 covers organizations handling Federal Contract Information and requires 15 basic security practices. Level 2, which applies to the vast majority of contractors handling CUI, aligns directly with all 110 security controls from NIST SP 800-171 and requires third-party assessment. Level 3 adds enhanced requirements from NIST SP 800-172 for organizations handling CUI associated with critical programs.
CMMC and AI: A New Regulatory Layer
In a significant development, the National Defense Authorization Act (NDAA) now directs the DoD to develop a cybersecurity framework specifically for AI and machine learning technologies used by contractors. This framework will be implemented as an extension of existing cybersecurity frameworks, including CMMC. The framework will apply to "covered" AI/ML, defined as AI/ML acquired by the DoD and all associated components, including source code, model weights, and the methods, algorithms, data, and software used to develop the AI/ML.
This means that if you are building AI-powered software for the defense sector — or using AI to build software for the defense sector — you will face additional security requirements beyond the standard CMMC controls. These requirements will focus on highly capable AI systems that may be of highest interest to cyber threat actors, applying stringent security requirements aligned with protections for national security systems.
The 14 Control Families
NIST SP 800-171, which forms the foundation of CMMC Level 2, organizes its 110 controls across 14 families. Every one of these must be addressed in your system architecture, and if you are using AI to build your software, you need to verify that the AI has actually implemented them correctly. The families are: Access Control, Awareness and Training, Audit and Accountability, Configuration Management, Identification and Authentication, Incident Response, Maintenance, Media Protection, Personnel Security, Physical Protection, Risk Assessment, Security Assessment, System and Communications Protection, and System and Information Integrity.
For AI-built software, several of these families deserve particular attention.
Access Control requires limiting system access to authorized users, enforcing role-based access control, limiting access to the types of transactions and functions that authorized users are permitted to execute, and controlling the flow of CUI in accordance with approved authorizations. AI-generated code frequently gets access control wrong — implementing it inconsistently, leaving endpoints unprotected, or creating authorization logic that is vulnerable to bypass.
Audit and Accountability requires creating and retaining system audit logs to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized activity. AI tools rarely implement comprehensive audit logging unless explicitly instructed to do so.
Configuration Management requires establishing and enforcing security configuration settings for IT products used in organizational systems and tracking, reviewing, approving, and auditing changes. When AI is generating and modifying your code rapidly, configuration management becomes exponentially more difficult.
System and Communications Protection requires monitoring and protecting communications at system boundaries, employing architectural designs and software development techniques that promote effective information security, and encrypting CUI at rest and in transit. NIST SP 800-171 specifically calls out the need to "employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems."
SOC 2 Compliance: Trust Services in the AI Era
SOC 2 is the auditing framework developed by the American Institute of Certified Public Accountants (AICPA) that evaluates an organization's controls related to five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. For B2B software companies — and increasingly for AI platforms — SOC 2 compliance has become the baseline security expectation.
Why SOC 2 Matters More When Building with AI
In 2025, SOC 2 auditors are increasingly asking about AI-specific risks that did not exist even two years ago. If you are building software with AI tools, or if your product incorporates AI features, auditors will want to understand how you manage several new risk categories.
Model governance and data handling. If you train or fine-tune models on customer data, auditors want to know how you prevent data leakage. They want to understand what data goes into your models, how it is protected, and whether customer data could surface in outputs to other customers.
AI-specific attack surfaces. SOC 2 auditors now evaluate risks like prompt injection, data poisoning, adversarial examples, and model theft. These are unique to AI systems and require controls that traditional security frameworks did not anticipate.
Continuous monitoring requirements. SOC 2 in 2025 is no longer a periodic checkpoint. It demands continuous, intelligent risk monitoring. The framework now expects always-on compliance, with evidence gathering and control testing happening continuously rather than annually.
Incorporating AI Controls into SOC 2
The most efficient approach for organizations using AI is to incorporate AI-specific risks and controls into an existing SOC 2 Type 2 report rather than pursuing a separate AI certification. This demonstrates to customers that your AI controls have been vetted by a third party for design and operating effectiveness while reducing the compliance burden of maintaining a separate certification like ISO 42001.
Key controls to implement include logical access controls to AI systems (particularly where prompts are handled), protection of training data from unauthorized access and manipulation, vendor management for third-party LLM providers, change management procedures for AI model updates, and incident response procedures specific to AI-related security events.
Security by Design: Architectural Principles That Must Be There from Day One
The most critical message for anyone building government or compliance software — especially with AI assistance — is this: security cannot be retrofitted. It must be in the architecture from the beginning.
This is not about adding a security layer on top of your application after it is built. It is about making security a foundational design constraint that shapes every architectural decision from the first commit.
Role-Based Access Control (RBAC) as Foundation
Role-Based Access Control is not just a feature — it is an architectural pattern that must permeate your entire application. NIST has formally recognized RBAC as the predominant model for advanced access control since its formalization in 1992, and it remains central to NIST SP 800-171, CMMC, and SOC 2 compliance.
Implementing RBAC correctly means designing your system so that every user is assigned to one or more roles, every role has a defined set of permissions, and every resource access request is evaluated against the user's role permissions before being granted. For government and compliance software, this extends further into the principle of least privilege (users get only the minimum access necessary), separation of duties (no single user should have enough access to compromise the entire system), and need-to-know restrictions (access to CUI is limited to personnel who require it for their assigned duties).
When AI is generating your code, you cannot assume it will implement RBAC correctly — or at all. AI models frequently create endpoints without authorization checks, implement inconsistent permission models across different parts of the application, or create admin-level access paths that bypass normal authorization flows. Every endpoint, every data access path, and every API call must be verified for proper role-based authorization.
Secure Workspace Isolation
For applications handling CUI or other regulated data, workspace isolation is a critical architectural requirement. This means designing your system with clear boundaries between different security domains, ensuring that data cannot flow between workspaces without explicit authorization, and implementing network segmentation that limits the blast radius of any potential breach.
NIST SP 800-171 specifically addresses this: organizations can limit the scope of security requirements by isolating designated system components in a separate CUI security domain, using architectural and design concepts such as implementing subnetworks with firewalls or other boundary protection devices and using information flow control mechanisms.
Encryption Architecture
Encryption must be designed into your data model from the start, not added as an afterthought. For CMMC Level 2 compliance, this means FIPS 140-3 validated encryption for CUI at rest, TLS 1.3 for all data in transit, proper cryptographic key management, and encrypted backup and recovery systems.
AI tools will typically implement encryption, but they often use default configurations that may not meet federal requirements. The difference between "encrypted" and "encrypted to FIPS 140-3 standards with proper key management" is the difference between passing and failing a CMMC assessment.
Comprehensive Audit Logging
Every action in a compliant system must be logged, and those logs must be immutable, timestamped, and retained according to your compliance framework's requirements. This includes user authentication events, data access and modification records, administrative actions, failed access attempts, system configuration changes, and data export or sharing events.
Design your logging architecture to capture who did what, when, where (from what system/IP), and to what resource. Integrate with a Security Information and Event Management (SIEM) system for real-time monitoring and alerting. This is not something to add later — the data model for audit logging, the storage architecture for log retention, and the integration points for monitoring all need to be in the foundation.
Zero Trust Architecture
The principles of Zero Trust — "never trust, always verify" — are becoming a core expectation for both CMMC and SOC 2 compliance. This means verifying every access request regardless of where it originates, implementing micro-segmentation to limit lateral movement, requiring multi-factor authentication for all users, continuously monitoring and validating security posture, and assuming breach as a design principle.
For AI-built applications, Zero Trust is especially important because AI tools tend to create applications that assume a trusted internal network — exactly the assumption that Zero Trust architecture exists to eliminate.
A Practical Framework: From AI-Generated Code to Production-Ready Compliance
Here is a step-by-step framework for teams using AI tools to build government and compliance software. This is not theoretical — this is what it takes to ship secure, compliant software in the current regulatory environment.
Phase 1: Architecture and Design
Before any code is generated — by AI or by hand — establish your security architecture. Define your compliance requirements (CMMC level, SOC 2 Trust Services Criteria, FedRAMP requirements, etc.), create your threat model, design your RBAC hierarchy, map out your data classification and CUI boundaries, define your encryption strategy, design your audit logging architecture, and document everything in a System Security Plan (SSP).
AI can help with this phase — use it to draft architecture documents, generate threat models, and outline control implementations. But the decisions must be made by humans who understand the regulatory requirements.
Phase 2: Secure Development
When using AI to generate code, follow these principles. Treat every AI-generated code block as unreviewed code from an unknown developer. Never deploy AI-generated code without running it through SAST. Write explicit, security-focused prompts — specify input validation requirements, encryption standards, authentication mechanisms, and authorization checks. Use AI to generate security tests, not just functional code. Implement dependency scanning on every build to catch vulnerable libraries the AI may introduce.
Phase 3: Continuous Security Validation
Embed security into your CI/CD pipeline with automated gates. SAST scans on every pull request with no merges allowed when critical vulnerabilities are detected. SCA scans on every build with alerts for vulnerable dependencies. DAST scans in staging environments before every deployment. Infrastructure-as-code scans for Terraform, Kubernetes, and Docker configurations. Secret scanning to catch hardcoded API keys, tokens, and credentials.
Phase 4: Compliance Documentation and Evidence
Compliance is not just about having the right controls — it is about proving you have them. Maintain your System Security Plan with current architecture documentation. Develop and maintain your Plan of Action and Milestones (POA&M) for any outstanding gaps. Collect evidence continuously, not just before audits. Keep detailed records of security testing results, remediation actions, and control assessments.
Phase 5: Continuous Monitoring and Improvement
Compliance is never one-and-done. Implement continuous monitoring for security control effectiveness. Conduct regular gap assessments against your compliance framework. Review and update access controls when roles change. Monitor for new vulnerabilities in your dependencies. Stay current with framework updates — CMMC, SOC 2, and NIST standards evolve, and your security program must evolve with them.
The Bottom Line
AI is transforming software development. It is making it possible to build better software, faster, with smaller teams. That is genuinely exciting, and if you are a developer or a business owner, you should absolutely be leveraging these tools.
But the fundamental rules of software security have not changed. Software that handles sensitive data must protect that data. Software that processes government information must meet government security standards. Software that stores user credentials, financial records, or health information must be built on a foundation of proper access control, encryption, audit logging, and continuous monitoring.
AI does not know your compliance requirements. It does not understand your threat model. It does not read your contracts with the Department of Defense. It generates code based on patterns it has seen, and nearly half the time, those patterns include known security vulnerabilities.
The developers and organizations that will thrive in this new landscape are the ones who use AI as a force multiplier for their existing security expertise — not as a replacement for it. They are the ones who run Fortify on every build, who design for RBAC from the first commit, who maintain their SSP as a living document, and who treat compliance not as a checkbox but as a competitive advantage.
The tools are only as smart as the people using them. Be smarter than the tools.
Published by Make Money From Coding (makemoneyfromcoding.com) For development services, consulting, and security-focused application architecture, visit makemoneyfromcoding.com.