A developer's
guide to SDLC
compliance
A developer's guide to SDLC compliance November 2025
Table of Contents
Introduction: A clearer view of compliance 03
Overview of compliance in the SDLC 04
The SDLC responsibility model: developer vs. business 05
The developer's part in SDLC compliance 06
What about AI? 07
List of major regulations: The decoder ring 08
How SonarQube helps to streamline SDLC compliance 10
Conclusion: Compliance as a part of the developers’ craft 13
[Link] 2/14
A developer's guide to SDLC compliance November 2025
Introduction:
A clearer view of compliance
Compliance often seems complex, overwhelming, and disconnected from the
day-to-day work of building software. It's easy to get lost in a landscape of
overlapping acronyms (GDPR, PCI, SOX, HIPAA) and rules that feel like they only
get in the way.
The purpose of this guide is to provide a simple, practical model that cuts
through the complexity of the compliance process. This isn't another 100-page
regulation to read. Instead, it's a map to guide developers on how to support the
business need of compliance excellence.
This map is built on a clear line between two distinct domains:
• What the developer is responsible for: the quality of their code, which includes
reliability, security, and maintainability; and the overall defensibility of the
codebase at any given moment.
• What the business is responsible for: the secure environment and formal
processes the company provides.
The goal is to provide a clear path, show exactly where developers should
focus their efforts, and help them understand how to meet their requirements
efficiently. This guide will show that achieving compliance doesn’t just take an
audit; it's a necessary mindset in service of building high-quality software.
[Link] 3/14
A developer's guide to SDLC compliance November 2025
Overview of compliance
in the SDLC
For a developer, compliance is the formal process of proving that software
is secure, reliable, and handles data responsibly. It's not a separate task to
be done at the end; it's a set of principles integrated into the entire software
development lifecycle (SDLC).
The "why" behind this comes from regulations, but the "how" comes down to
good engineering. In fact, compliance requirements are often just a formal name
for practices that developers already value.
Why code quality is a compliance enforcer
From a SDLC compliance perspective, a high-quality codebase is:
• Reliable: it functions as intended without failure, consistently performs
required functions, and has high test coverage to identify bugs early.
• Secure: It actively defends against attacks and doesn't contain common
vulnerabilities.
• Maintainable: It can be fixed and updated safely. Regulations like the EU's
Cyber Resilience Act (CRA) and PCI DSS mandate that critical vulnerabilities
are fixed quickly. Low-quality, "spaghetti" code makes this impossible.
• Defensible: It can prove it did the right thing. If an auditor asks, "How is
customer data protected?" the code and its logs are the primary evidence.
Technical debt is one of the arch-enemies of a compliant codebase. It isn't just
an engineering problem—it's a direct liability due to security shortcuts, clutter,
lack of test coverage and overall maintainability. Every time a developer writes
high-quality, testable, and maintainable code, they are directly supporting the
organization's ability to stay compliant.
[Link] 4/14
A developer's guide to SDLC compliance November 2025
The SDLC responsibility model:
developer vs. business
This is the core concept of the guide. The easiest way to navigate SDLC
compliance is to divide the landscape into two distinct domains: code-related
“what is built” and environment-related “the foundation it's built on.”
What is built: The developer's domain
This is the primary focus for a developer, covering all the controls a developer
implements within the application itself. This includes the principles of writing
secure code to prevent common vulnerabilities, like those referenced in the
OWASP Top 10. It also involves sensitive data handling, such as using encryption
and masking data in logs. Furthermore, it covers enforcing permissions by
ensuring access controls are in place, creating an audit trail by generating
meaningful log entries, and managing dependencies by tracking and patching
third-party libraries for known vulnerabilities (CVEs).
The foundation it’s built on: The business's domain
This is the secure foundation that the business provides. The code relies on this
environment to function securely and compliantly. The developer is a consumer
of this environment, not the builder.
This domain is itself split into two parts:
• Technical (the platform): This includes the secure infrastructure and set
of tools used every day. The business is responsible for configuring and
managing:
◦ Secure infrastructure: firewalls, hardened cloud configurations.
◦ Identity and access management: the central user directory (like Okta or Entra ID).
◦ Tools and pipelines: CI/CD pipeline, security scanners, centralized logging.
• Administrative (the process): This includes the set of rules, policies, and
procedures that developers are required to follow. The business is responsible
for creating and maintaining:
◦ Formal governance: official information security policy, risk assessments.
◦ Key procedures: formal change management process, incident response plan.
◦ Training and oversight: security awareness training, audits.
[Link] 5/14
A developer's guide to SDLC compliance November 2025
The developer's part in SDLC
compliance
Now that the model is clear, in this section we will focus on the developer's
domain. This is the practical, day-to-day playbook for the "code-related"
responsibilities defined in section 3. Here are the five key principles:
Resilient code design
This involves treating all data from external sources as untrusted through input
validation and ensuring data is always handled as data, never as executable code.
This approach helps prevent common issues like injection flaws (OWASP A03). It
also includes safely handling data before rendering it, known as output encoding,
to prevent attacks like cross-site scripting (XSS).
Sensitive data handling
This principle means ensuring secrets like API keys or passwords are never hard-
coded and are instead loaded from an environment-provided secrets manager.
It also involves preventing data exposure by never logging sensitive data in
plaintext–which is a common compliance concern, particularly for regulations like
PCI DSS and HIPAA. Finally, it means using approved, standard cryptographic
libraries to protect data in transit and at rest.
Permission enforcement
This involves correctly integrating with the environment-provided system for
authentication. It also requires per-request authorization, meaning the code
verifies that the authenticated user has the right to perform the requested action
on a specific resource, for every single request. This is a fundamental principle
for preventing issues like broken access control (OWASP A01).
Audit trail creation
This requires generating context-rich log entries that provide meaningful
business and security context (e.g., "File deleted," not just "Endpoint hit"). This
includes logging security-relevant events by creating a record of who, what, and
when for critical actions like logins, data access, or high-risk transactions.
Dependency management
This involves vetting open-source and other third-party code to ensure
dependencies are understood and come from trusted sources. It also includes
using environment-provided tools to continuously track known vulnerabilities
(CVEs). This leads to maintaining a consistent patching cadence to keep libraries
updated, which is an important part of modern regulations like the EU's Cyber
Resilience Act (CRA).
[Link] 6/14
A developer's guide to SDLC compliance November 2025
What about AI?
AI-generated code creates serious compliance challenges for developers.
First, it dramatically increases the sheer volume of code that must be reviewed,
overwhelming existing processes. Second, this code is often overly verbose and
unnecessarily complex, making it a nightmare to review, maintain, and audit.
Most importantly, AI models lack a real understanding of good practice and can
easily inject critical security vulnerabilities, such as hard-coding passwords
or API keys, directly into the codebase. This means every line of AI-generated
code must be reviewed with the same scrutiny as human-written code, creating
a significant bottleneck and requiring more resources to ensure the codebase
remains compliant.
The core principles would be the same:
• Resilient design: AI-generated code often trusts inputs. Verify it validates all
inputs and encodes all outputs to prevent security vulnerabilities.
• Sensitive data handling: AI models may hard-code or log secrets. The review
must hunt for hard-coded credentials and ensure sensitive data is never
logged.
• Permission enforcement: AI code frequently omits authorization. Ensure it
checks user permissions on every request, not just authentication.
• Audit trail creation: AI-generated logs are often just technical noise. Ensure
logs provide a meaningful "who, what, when" audit trail for security events.
• Dependency management: AI may suggest unvetted libraries. Any AI-
suggested dependency must be formally vetted for supply chain risks
and CVEs.
[Link] 7/14
A developer's guide to SDLC compliance November 2025
List of major regulations:
The decoder ring
This section is a decoder ring, a deciphering tool to help developers understand
why certain rules exist. It's the business's job to read these, perform a risk
assessment, and translate them into the specific, clear policies developers
follow.
The goal here is to see the pattern. Every single regulation maps to this two-level
model: they all either have requirements for the environment (the business's
policies, processes, and infrastructure), for the code (the security and integrity
of the application itself), or both.
General security standards that apply to most teams and industries
These are foundational frameworks and laws that apply to most modern
software teams.
• CRA (Cyber Resilience Act): An EU law that sets security-by-design and
vulnerability handling rules for any "product with digital elements."
• GDPR / CCPA: Privacy laws (EU / California). Their global reach makes them a
general concern. They mandate "privacy by design."
• NIST SSDF (SP 800-218): The "Secure Software Development Framework."
This is a US government guide on how to build a secure SDLC. It's the literal
playbook for this model.
• ISO 27001:2022: The global standard for an "information security management
system" (ISMS). It's a high-level environment framework, but it has specific
code controls (like Annex A.8.28 "secure coding").
• SOC 2: An audit framework for service organizations (common for B2B/SaaS).
It audits the environment (policies, procedures) to prove a service is secure
and available.
• OWASP Top 10: A list of the most critical web application security risks. This is
a core "code-related" checklist for all web developers.
• CWE / CVE: Lists of common weaknesses (CWE) and vulnerabilities (CVE).
These are the "what" developers look for in their code and dependencies.
[Link] 8/14
A developer's guide to SDLC compliance November 2025
Industry-specific regulations
These are mandatory rules that must be followed if a company operates in
these sectors.
Finance Healthcare & life sciences
• Payments: PCI DSS. • US health data: HIPAA.
◦ Code: Has explicit rules ◦ Code: Governed by "technical
(referencing OWASP). safeguards," e.g., access controls,
◦ Environment: Has explicit rules for § 164.312(a).
the entire platform. ◦ Environment: Governed by
"administrative safeguards," e.g.,
• US public companies: SOX.
risk analysis, § 164.308(a).
◦ Code: Governed by "application
controls," e.g., code ensuring data • Life sciences (biotech & pharma): GxP /
integrity. 21 CFR part 11.
◦ Environment: Governed by "IT ◦ Code: Requires "operational system
general controls," e.g., strict checks," e.g., authority checks, etc.
change management, separation of ◦ Environment: Requires "limiting
duties. system access" and "generation
of... audit trails."
• US financial data: GLBA.
Government & defense (US)
◦ Code: The "Safeguards Rule"
• US federal systems: FISMA / NIST 800-
mandates testing in-house apps.
53.
◦ Environment: Mandates a
comprehensive "information ◦ Code & environment: NIST 800-53
security program" and risk is the entire control catalog. "SA"
assessment. (system acquisition) controls apply
to code; "AC" (access control)
• EU financial resilience: DORA. controls apply to the environment.
◦ Code: Explicitly requires "security-
• US defense contractors: CMMC.
by-design" (art. 13).
◦ Environment: Requires a ◦ Code & environment: A maturity
model based on NIST controls. It
comprehensive "ICT risk
heavily audits the environment (the
management framework" (art. 5).
company's processes) to prove
Critical systems & automotive data protection.
• High-reliability systems: CERT / MISRA
C++* • US defense hardening guides: STIGs.
◦ Code: These are 99% code-related. ◦ Code: A specific "application
They are strict, literal rulebooks for security STIG" applies.
how code is written. ◦ Environment: The other 99%
◦ Environment: The business must of STIGs are for hardening the
provide the (policy) mandate and platform (servers, network).
the (technical) tools to enforce
them.
*MISRA and MISRA C are the registered trade marks of The MISRA Consortium Limited
[Link] 9/14
A developer's guide to SDLC compliance November 2025
How SonarQube helps to streamline
SDLC compliance
Understanding the "code vs. environment" model is the first step. The next is
automating the work. SDLC compliance isn't a separate phase—it's the result
of a consistent, high-quality development process that prioritizes compliance
from the very beginning. SonarQube is a code quality and security tool that
helps automate this process. It takes the guesswork out of SDLC compliance by
integrating quality and security checks directly into the existing development
workflow. It helps bridge the code-related and environment-related domains.
Automating code-related responsibilities
For the developer, SonarQube provides actionable guidance and automatic code
review within the workflow. This makes it a natural part of the development
process, not an extra step.
• In-workflow feedback: Analysis results are displayed directly in the IDE and in
every pull request. This provides instant, actionable guidance on what steps
need to be taken to close quality and security gaps, leading to streamlined
compliance.
• Centralized management: It ensures all developers are working with the same
set of compliance and quality rules directly in their SonarQube for IDE.
• AI Code Assurance: It provides a governance framework to manage the
emerging quality, security, and compliance risks of AI-generated code.
• Software composition analysis (SCA): Available with SonarQube Advanced
Security, this identifies vulnerabilities (CVEs) and license compliance risks
from open-source dependencies, helping to generate a software bill of
materials (SBOM).
[Link] 10/14
A developer's guide to SDLC compliance November 2025
7.2. Enforcing environment-related policies
For the business, SonarQube provides the environment-related tools for
enforcement and governance.
• Centralized criteria management: The business can define and enforce its
specific compliance and quality rules (as quality profiles) consistently for
every developer and every AI coding tool.
• Automatic enforcement: The quality gate is the core enforcement mechanism.
It's the administrative environment or policy made real in the technical
environment or CI/CD pipeline. It automatically blocks pull requests and
branches that don't meet the required quality, security, or test coverage
standards, preventing non-compliant code from being merged.
[Link] 11/14
A developer's guide to SDLC compliance November 2025
7.3. Generating the proof for auditors
A major part of SDLC compliance is providing evidence. SonarQube automates
the generation of this proof, providing a clear record of detection and
remediation.
• Automatic audit trail: The tool generates a detailed trail by delivering secure,
immutable, and detailed logs across SonarQube Server, SonarQube Cloud,
and SonarQube for IDE, capturing all critical actions, including user lifecycle
changes, configuration updates, and security events, to ensure full traceability,
regulatory compliance (with SOC 2, HIPAA, PCI DSS, GDPR, etc.), and
operational transparency.
• Streamlined reporting: Developers and managers can easily prove that code
contributions comply with regulatory standards. This includes built-in reports
for standards like the OWASP Top 10, CWE Top 25, and PCI DSS.
• Integrated environment: First- and third-party integrations with various
DevOps, project management, security, and compliance tools (such as JFrog,
Jira, Jellyfish, and Vanta) allow to further strengthen compliance readiness
and simplify the auditing process.
SonarQube helps ensure that streamlined compliance is the natural outcome of a
secure, well-managed development process.
[Link] 12/14
A developer's guide to SDLC compliance November 2025
Conclusion: Compliance as a part
of the developers’ craft
Compliance doesn't have to be a complex burden or an obstacle. The primary
role of the developer is to focus on what they build: high-quality, secure, and
defensible code. The business provides the secure environment and policies to
support this role.
By integrating automated checks directly into the workflow, SonarQube bridges
these two domains. It provides the in-workflow feedback to help developers
meet code-related responsibilities and the enforcement mechanisms, like the
quality gate, to uphold the environment-related policies.
This approach moves SDLC compliance from a final, stressful audit to a
consistent, everyday practice. It becomes the natural, verifiable outcome of a
professional, high-quality development process.
[Link] 13/14
Executive summary: Coding Personalities of Leading LLMs October 2025
©2025, SonarSource Sàrl
[Link]