In a previous post, I covered what Secure Application is, why it matters, and how to enable it in Splunk Observability Cloud — including the Kubernetes/Helm workflow and a walkthrough of capabilities.
This post is the hands-on companion. If you already have a Java application instrumented with the standard Splunk OTel Java Agent and you want to add Application Security, this is the exact code-level walkthrough of what changes. I built a small demo application, made the upgrade, and captured every step — including the git diff.
The full source code is available on GitHub with two commits: one for the baseline instrumentation, and one for the Secure Application upgrade.
The starting point: a Java app with the standard Splunk Java Agent
The demo is a Spring Boot application — a Monty Hall "Door Game" — running in Docker with a Splunk OTel Collector forwarding traces and metrics to Splunk Observability Cloud. Standard APM setup. This configuration will work with both the Splunk Distribution of the OTel Collector or any standard recent distribution.
Here's the relevant part of the Dockerfile, where the standard agent gets downloaded and attached:
# Download the standard Splunk OTel Java Agent (APM only, no Application Security)
ARG AGENT_VERSION=2.25.1
RUN curl -L "https://repo1.maven.org/maven2/com/splunk/splunk-otel-javaagent/${AGENT_VERSION}/splunk-otel-javaagent-${AGENT_VERSION}.jar" \
-o /app/splunk-otel-javaagent.jar
ENTRYPOINT ["java", \
"-javaagent:/app/splunk-otel-javaagent.jar", \
"-jar", "/app/door-game.jar"]
The collector config routes traces and metrics to Splunk Observability Cloud:
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch, resourcedetection]
exporters: [otlphttp/traces, signalfx]
metrics:
receivers: [otlp]
processors: [memory_limiter, batch, resourcedetection]
exporters: [signalfx]
logs:
receivers: [otlp]
processors: [memory_limiter, batch, resourcedetection]
exporters: [debug]
At this point, traces and metrics flow into Splunk Observability Cloud. APM works. But there's no vulnerability detection — the standard agent doesn't scan libraries.
The upgrade: 2 changes, 0 code changes
Enabling Application Security is a two-line change across two files. No application code modified.
Change 1: Swap the agent JAR
In the Dockerfile, replace splunk-otel-javaagent with splunk-otel-javaagent-csa in the download URL:
That's it for the application side. Same file path, same -javaagent flag, same environment variables. The Secure Application agent is a drop-in replacement — it handles both APM and Application Security in a single JAR.
Both agents are published under com.splunk on Maven Central and share the same version numbers:
|
Agent |
Maven artifact |
|
Standard (APM only) |
com.splunk:splunk-otel-javaagent |
|
With Secure Application |
com.splunk:splunk-otel-javaagent-csa |
Change 2: Route security events through the collector
The Secure Application agent reports security data using the OpenTelemetry protocol. Under the hood, it uses the OTLP logs transport.
Note: this has nothing to do with Splunk Platform log ingestion or Log Observer. No log-related licensing or infrastructure is required.
The collector's signalfx exporter (the same one you already use for metrics) converts these security events and sends them to Splunk Observability Cloud. You just need to add it to the collector's logs pipeline:
If you're already using the signalfx exporter for metrics or traces (which most Splunk OTel Collector setups do), you don't need to define a new exporter — just reference the existing one in the logs pipeline.
Note: If you're deploying on Kubernetes with Helm, you can skip this manual collector change. The Helm chart flag splunkObservability.secureAppEnabled=true configures the collector pipeline automatically. See the general Secure Application setup post for the Helm walkthrough.
That's the whole diff
Here's the complete change as a unified diff:
Note: Secure Application is a paid add-on to Splunk APM. Contact your Splunk account team to enable the Secure Application license before deploying the Secure Application . If you do not have the Secure Application license, running the Secure Application agent will not cause any failures and APM will work as normal – the collector will just receive standard app logs without Secure Application events.
Rebuild and deploy
docker compose down
docker compose up -d --build
Then generate some traffic against your application.
Verifying the upgrade
Confirm security events are flowing
docker compose logs otel-collector | grep "secureapp"
You should see output like:
InstrumentationScope secureapp 1.59.0
SeverityText: Security
EventName: com.cisco.secureapp.report.v1
The secureapp instrumentation scope is the Secure Application agent's security engine reporting library data. These events contain compressed library inventory and vulnerability information that Splunk Observability Cloud processes on the backend.
Confirm no export errors
docker compose logs otel-collector | grep -iE "error|fail|drop" | grep -v health
If the upgrade is working correctly, this returns nothing.
Confirm in Splunk Observability Cloud
Your service should appear in APM > Services (it was already there thanks to the standard agent). The new part: navigate to Application Security > Vulnerabilities to see runtime vulnerabilities detected in your application's open-source libraries.
For a full walkthrough of the Application Security — including the Vulnerabilities, Libraries, and how to set up alert notifications — see the companion post.
What's actually different between the two agents
Both splunk-otel-javaagent and splunk-otel-javaagent-csa are built on the same Splunk Distribution of OpenTelemetry Java (version splunk-2.25.1-otel-2.25.0 at time of writing). The Secure Application variant bundles an additional security engine that:
- Scans loaded JARs at runtime to build a library inventory
- Reports library metadata to the collector using the OpenTelemetry protocol
- Continuously monitors for new libraries loaded during the application lifecycle
The scanning happens asynchronously — it doesn't add per-request latency. Library data is reported once at startup and periodically thereafter.
Source code
The full source code for this walkthrough is available on GitHub here. The repo has two commits:
- Add Door Game app instrumented with standard Splunk Java Agent — the baseline
- Upgrade Splunk Java Agent to enable Application Security — the upgrade
If you have a Secure Application license, you can clone the repo, add your Splunk Observability Cloud credentials to a .env file, and run docker compose up -d --build. The Door Game runs at http://localhost:8080.
git clone https://github.com/splunk/evangelism-public.git
cd secure-application
cp .env.example .env
# Edit .env with your SPLUNK_ACCESS_TOKEN and SPLUNK_REALM
docker compose up -d --build
Don't have a Secure Application license yet? Contact our Sales team to get started.
Resources
- How to Detect Runtime Vulnerabilities in Splunk Observability Cloud with Secure Application
- Splunk Observability Cloud Application Security documentation
- Instrument Java applications for Secure Application
- splunk-otel-javaagent-csa on Maven Central
Want updates like this sent straight to you? Learn how to subscribe to this blog (and follow Labels you care about) in our quick guide.
