Java Application Security in CI/CD: SDLC, SAST, DAST, IAST, RASP & Spring Boot

Java remains the backbone of enterprise software in finance, insurance, healthcare, and the public sector. These are exactly the environments where a security failure is most expensive and where auditors, not just attackers, scrutinize how software is built and run. This article pulls together what it takes to secure a Java application across its full lifecycle: architecting a resilient SDLC, choosing between static and dynamic testing, adding runtime techniques such as IAST and RASP, hardening Spring Boot specifically, and wiring all of it into a CI/CD pipeline. It is written for architects, tech leads, and security engineers who own these decisions.

The context in 2025 has shifted structurally. The OWASP Top 10 2025 pivots from symptoms to root causes, introducing categories such as “Software Supply Chain Failures” and “Mishandling of Exceptional Conditions.” The platform itself has moved too: with JDK 24 and 25, the Security Manager is permanently disabled, forcing a migration to external isolation. Securing the SDLC now means a Zero Trust posture that integrates DevSecOps, strict CI/CD governance, and readiness for Post-Quantum Cryptography (PQC).

What makes regulated environments distinct is not only the technical threat but the burden of proof. A bank or an insurer does not just need controls that work; it needs to demonstrate to auditors that those controls exist, are enforced consistently, and produce evidence over time. That expectation shapes every decision below, from why artifacts are signed to why security gates and audit logs are treated as first-class outputs of the pipeline rather than afterthoughts. The sections that follow move from architecture, through the testing techniques that find vulnerabilities, to the runtime techniques and framework specifics that contain them, and finally to how the pieces are sequenced in CI/CD.

Architecting a Secure Java SDLC

In enterprise environments, security is no longer a runtime configuration you switch on late; it is a set of architectural decisions enforced consistently from design through deployment. Three shifts define modern Java architecture: the loss of in-process sandboxing, the move to identity-first access, and the treatment of the build pipeline as a primary attack surface. Each of these used to be someone else’s problem—the JVM’s, the network perimeter’s, or the release team’s—and each has now become an explicit design responsibility for the people building the application.

Secure Design in the Post-Security Manager Era

For decades, Java applications relied on the SecurityManager for in-process sandboxing. As detailed in JEP 486, this component is now permanently disabled and slated for removal, having been deemed ineffective for modern server-side development. The practical consequence is direct: the JVM is no longer a security boundary. Production environments must rely on infrastructure-level isolation instead.

• Containerization and virtualization: Use technologies like Docker, Podman, or hypervisors to restrict filesystem and network access.
• OS-level controls: Implement Linux seccomp filters or the macOS App Sandbox to limit system calls.
• Agent-based restrictions: For legacy requirements, such as blocking System.exit(), use Java agents for bytecode transformation at load time rather than runtime permission checks.

Identity-First Architecture

Modern design moves away from legacy session management toward stateless authentication. Jakarta EE 11 and Spring Security 6.4 have standardized this shift.

• Zero Trust APIs: Implement mutual TLS (mTLS) for service-to-service communication and OAuth2 with OpenID Connect (OIDC) for user authentication.
• JWT and statelessness: Use JSON Web Tokens (JWT) to carry identity and role claims. Keep tokens short-lived and validate them against strict audience (aud) and issuer (iss) claims to prevent “Broken Access Control” (A01:2025).
• Defense in depth: Combine JWTs with mTLS to verify both the user identity and the service identity, a critical pattern for fintech and SaaS platforms.

DevSecOps and the Software Supply Chain (A03:2025)

The OWASP Top 10 2025 ranks “Software Supply Chain Failures” (A03) as a top concern, expanding the previous “Vulnerable Components” category. Attacks now frequently target build infrastructure and dependencies rather than application code alone. A secure CI/CD pipeline is the primary defense against supply chain compromise.

1. SBOM generation: Every build should produce a Software Bill of Materials (SBOM) using tools like CycloneDX or Syft. This gives a machine-readable inventory of all direct and transitive dependencies, essential for rapid response during vulnerability disclosures.
2. Artifact signing: Use Sigstore (Cosign) to sign JARs and container images. This creates a tamper-evident seal, ensuring the artifact deployed is identical to the artifact built.
3. Provenance (SLSA): Generate SLSA (Supply-chain Levels for Software Artifacts) provenance attestations to verify where and how the software was built, preventing injection of malicious code during the build.

Dependency management follows the same discipline. Enterprise environments cannot rely on “latest” versions:

• Lock and pin: Use lock files (for example, gradle.lockfile) to freeze dependency versions. Avoid dynamic version ranges so malicious package updates cannot enter the build automatically.
• Repository hygiene: Configure Maven and Gradle with safe defaults. Never commit credentials to build.gradle or settings.xml; inject repository tokens through environment variables or secret managers.
• SCA tools: Integrate Software Composition Analysis (SCA) tools such as OWASP Dependency-Check or Snyk to block builds containing known vulnerabilities (CVEs).

Secure Coding: Data and Exceptions

Implementation flaws remain a significant risk, particularly with the new category A10:2025 – Mishandling of Exceptional Conditions. Despite mature frameworks, SQL Injection (A05:2025) persists, especially within ORMs like Hibernate and JPA. Catching these early is a core benefit of integrating SAST into Java CI/CD pipelines.

• ORM pitfalls: Avoid dynamic HQL/JPQL construction. String concatenation in entityManager.createQuery(), for example, is vulnerable. Use parameterized queries or the Criteria API.
• Sanitization: For file uploads, strictly validate MIME types and file extensions using allow-lists, and sanitize filenames to prevent path traversal.
• Fail closed: Applications should default to a secure state on failure. Keep transaction rollbacks atomic to prevent state corruption.
• Contextual logging: Use Mapped Diagnostic Context (MDC) to include user IDs and request correlation IDs in logs without exposing PII (A09), and keep logs tamper-evident. Inadequate logging prevents detection, while overly verbose error messages leak intelligence to attackers.

Cryptographic Agility (A04:2025)

The “harvest now, decrypt later” threat model is driving adoption of Post-Quantum Cryptography (PQC). The JDK has begun to catch up:

• PQC algorithms: Java now supports PQC algorithms via the JCE, including ML-KEM (Module-Lattice-Based Key-Encapsulation) and ML-DSA (Digital Signatures).
• Key encapsulation: Use the new KEM API for key exchange rather than traditional Diffie-Hellman when high security is required.
• Secret management: Never store secrets in code. Use the KDF (Key Derivation Function) API introduced in JDK 24 for robust key generation.

Vulnerability Management and Resilience

In 2025, attackers often weaponize vulnerabilities within 24 hours of disclosure, so the SDLC must assume fast-moving exposure. Enterprise organizations must track critical advisories such as the Oracle Critical Patch Updates (CPU); the July 2025 CPU, for instance, addressed high-severity JDK vulnerabilities (for example CVE-2025-50106) that allowed unauthenticated network attacks. Be wary, too, of “vibe coding”—the uncritical acceptance of AI-generated code, which can introduce vulnerabilities and requires rigorous human review and static analysis.

Availability is a security attribute (X01). Implement rate limiting and resource quotas to prevent Denial of Service (DoS), apply the bulkhead pattern to isolate failures and prevent cascading crashes, and consider computational proof-of-work challenges on public-facing endpoints to deter bot-driven resource exhaustion.

Testing Techniques Compared: SAST vs DAST for Java

Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST) are the two foundational approaches to application security testing. Both aim to find vulnerabilities, but they operate at different stages of the lifecycle and provide complementary perspectives. Understanding the difference is essential to designing an effective and sustainable strategy for enterprise Java.

SAST analyzes Java source code, bytecode, or compiled artifacts to identify potential vulnerabilities without executing the application. It provides early feedback during development and integrates naturally into CI/CD pipelines. Because it operates without runtime context, it can detect certain classes of vulnerabilities very early, but may generate false positives that require careful triage.

DAST analyzes a running Java application by interacting with it externally, typically over HTTP or other exposed interfaces. It identifies vulnerabilities from application behavior rather than code structure, and excels at runtime configuration, authentication flows, and deployment-specific weaknesses. Because it requires a deployed and accessible application, it runs later in the pipeline than SAST.

Aspect	SAST	DAST
Analysis Method	Static code analysis	Runtime behavior analysis
SDLC Stage	Development / Build	Test / Pre-production
Java Framework Visibility	High	Indirect
False Positives	Common without tuning	Generally lower
Runtime Context	No	Yes
CI/CD Integration	Early pipeline stages	Later pipeline stages
Coverage	Code-level vulnerabilities	Configuration & runtime issues

The differences are not academic; they drive tool selection and pipeline design. SAST gives high visibility into Java framework internals and code-level flaws but has no runtime context, so it cannot tell whether a flagged path is actually reachable in production—hence the false positives that demand tuning and triage. DAST inverts the trade-off: it sees real deployed behavior, including misconfiguration and broken authentication flows, but it treats the application as a black box and cannot point to the offending line of code. Neither, on its own, gives a complete picture.

In mature environments the two are therefore complementary controls, not competitors. SAST sits early in the pipeline for fast feedback on code changes; DAST runs against deployed test environments, either as scheduled scans or dedicated pipeline stages. This layered approach improves coverage while minimizing disruption to delivery. In enterprise settings, both are typically defined within a broader CI/CD security framework that governs access management, secrets handling, artifact integrity, and auditability, and framework-specific concerns such as those in Spring Boot often shape how each is applied.

From a governance perspective, organizations must show that testing is comprehensive and continuous. Relying on either approach alone leaves coverage gaps; combining them provides stronger operational traceability and demonstrates defense in depth. The common pitfalls are predictable: treating DAST and SAST as interchangeable, enforcing overly strict security gates without context, and failing to feed findings into remediation workflows. Effective programs define the role of each approach clearly and ensure results are actionable and properly governed.

Runtime Techniques: IAST and RASP

SAST and DAST provide valuable insight, but neither fully captures how a Java application behaves at runtime. Interactive Application Security Testing (IAST) and Runtime Application Self-Protection (RASP) close that gap by operating inside the running application.

IAST combines aspects of static and dynamic analysis by instrumenting a running Java application during functional or integration testing. By observing behavior from inside the runtime, it correlates code-level context with actual execution paths, identifying vulnerabilities with greater accuracy than traditional DAST while significantly reducing false positives compared to static analysis alone.

RASP also operates within a running application, but its purpose is protection rather than testing. It monitors and can block malicious behavior in real time, intercepting calls and execution flows to detect and mitigate attacks such as injection attempts or exploitation of vulnerable components as they occur, in pre-production or production.

The distinction matters: IAST focuses on vulnerability detection during testing phases, whereas RASP focuses on runtime protection in deployed environments. Neither replaces SAST or DAST; they fill visibility gaps that static and dynamic testing leave open. A layered strategy typically combines SAST for early detection, DAST for runtime behavior testing, IAST for accurate vulnerability correlation, and RASP for runtime protection. The value of IAST in particular comes from placing itself between the two older techniques: because it observes execution from inside the JVM while the application is being exercised, it inherits DAST’s grounding in real behavior and SAST’s ability to name the vulnerable code, which is why its findings tend to be both more accurate and easier to act on.

Integrating IAST usually happens during automated integration or end-to-end testing stages. Because it relies on execution, it needs realistic test coverage to be effective, and in enterprise pipelines it is often run asynchronously or in dedicated stages to limit its impact on delivery speed. RASP deployment demands more care around performance, stability, and operational impact, since it adds complexity to the running system. It is typically deployed selectively on high-risk applications or exposed interfaces rather than as a blanket control—especially relevant when securing Spring Boot applications that handle sensitive data or face external traffic.

From a compliance standpoint, IAST and RASP strengthen evidence of defense in depth and continuous monitoring, but they must be governed to avoid introducing unmanaged risk; auditability, configuration control, and clear ownership are essential. The recurring pitfalls are deploying RASP without adequate monitoring, relying on IAST without sufficient test coverage, and treating runtime tools as substitutes for secure development practices.

Framework Hardening: Spring Boot

Spring Boot is one of the most widely used frameworks for enterprise Java, which makes it a useful place to see the whole stack of controls land in one codebase. Its flexibility and rapid development make it attractive to large organizations, including those in regulated sectors such as finance, insurance, and the public sector—which also makes its applications high-value targets. The same conveniences that speed delivery, such as auto-configuration and sensible defaults, can quietly widen the attack surface if they are left unexamined. Deploying Spring Boot securely therefore takes more than enabling framework-level features; it requires deliberate architecture, disciplined configuration, and tight CI/CD integration.

Enterprise environments impose strict requirements on access control, data protection, auditability, and change management. Spring Boot applications frequently touch sensitive data and critical business processes, and the common challenges are managing configuration securely, enforcing authentication and authorization consistently, and maintaining traceability across the lifecycle. Sound architecture is the starting point: clear separation of concerns, defense in depth, and a minimized attack surface, with support for auditability and segregation of duties so controls are enforceable and verifiable throughout the SDLC.

• Authentication and authorization: Spring Security provides a robust foundation. In enterprise environments, authentication is often delegated to centralized identity providers. Authorization decisions should be explicit, well-documented, and aligned with business roles—overly permissive access controls are a common source of security-review findings.
• Configuration and secrets: Credentials and tokens must never be embedded in source code or configuration files. In production, secrets are managed through centralized solutions and injected securely at runtime, which supports both security and operational traceability. See secrets management in CI/CD pipelines.
• Dependency and supply chain security: Spring Boot relies heavily on third-party dependencies, so monitor dependency vulnerabilities, manage updates, and ensure artifact integrity throughout the CI/CD pipeline. Static analysis remains a foundational control for catching these issues early.
• Runtime security and monitoring: Even with strong preventive controls, logging, monitoring, and alerting are needed to detect suspicious behavior and support incident response, balanced carefully against performance and operational stability.

Finally, Spring Boot applications in enterprise environments must support security reviews with evidence of secure design, controlled changes, and effective monitoring. Documentation, configuration management, and consistent enforcement of security policies are what demonstrate operational maturity over time.

Putting It Together in CI/CD

The techniques above only deliver value when they are sequenced into the pipeline so each runs where it is most effective and least disruptive. A representative flow for an enterprise Java application looks like this:

1. Commit and build: Run SAST and SCA on every change for fast, code-level feedback. Generate an SBOM and pin dependencies via lock files so the build is reproducible and inventoried.
2. Package and sign: Sign JARs and container images with Sigstore (Cosign) and attach SLSA provenance, so downstream stages can verify integrity before deployment.
3. Deploy to test and exercise: Run DAST against the deployed environment and enable IAST during integration and end-to-end tests, ideally asynchronously to protect delivery speed.
4. Production: Apply RASP selectively on high-risk or externally exposed services, backed by runtime monitoring, rate limiting, and rapid patching against advisories such as the Oracle CPU.

The ordering reflects a deliberate balance between speed and thoroughness. Fast, cheap checks—SAST and SCA—run on every commit because their feedback loop is short and their cost to delivery is low. Slower, environment-dependent checks—DAST and IAST—run later, against realistic deployments, and are often executed asynchronously so a long-running scan does not block a release. Protective controls—RASP, monitoring, patching—live in production, where the goal shifts from finding vulnerabilities to containing the ones that slip through. Trying to force every control to the left of the pipeline degrades delivery velocity without improving coverage; pushing everything right leaves preventable defects in production. The point is to place each control where its trade-off is favorable.

Across all of these stages, security gates prevent insecure code or configuration from progressing, and audit logs provide the operational traceability that governance requires. These controls are typically formalized and enforced through an enterprise CI/CD security framework that defines access controls, secrets management, artifact integrity, and auditability in one place.

Recommendations

If the preceding sections come down to a handful of decisions worth making explicit for any Java application headed into a regulated environment, they are these:

• Treat isolation as infrastructure, not JVM configuration. With the Security Manager gone, rely on containers, seccomp, and Java agents for boundaries.
• Adopt identity-first defaults. mTLS between services, OAuth2/OIDC for users, and short-lived, strictly validated JWTs.
• Secure the supply chain by default. SBOMs, signed artifacts, SLSA provenance, pinned dependencies, and SCA gates on every build.
• Layer your testing. SAST for early detection, DAST for runtime behavior, IAST for accurate correlation, RASP for selective runtime protection—not one in place of another.
• Plan for cryptographic agility. Begin evaluating ML-KEM and ML-DSA and the JDK 24 KEM and KDF APIs against the “harvest now, decrypt later” threat.
• Govern everything. Clear ownership, auditability, and configuration control turn these tools into evidence of defense in depth rather than unmanaged risk.

Securing Java in 2025 requires a holistic view that spans the entire SDLC. The deprecation of the Security Manager makes the underlying point concrete: security is no longer just a runtime configuration but an architectural imperative, enforced consistently from design through build, test, and production. Organizations that adopt Jakarta EE 11 and Spring Security defaults, rigorously enforce supply chain integrity, and layer static, dynamic, and runtime controls into a governed CI/CD pipeline can withstand a threat landscape that now moves in hours, not months.

---