01
Find
COMPLY finds every instance in your middleware layer and identifies its product and version, so each is held to the right baseline and matched to the right CVEs.
COMPLY™ · AI-native middleware remediation
AI-native middleware remediation, end to end.
COMPLY checks every app server, web server, gateway and broker against its STIG or CIS baseline, tracks every CVE for its version and manages every patch. Its agents then carry each fix to verified closed, from the vendor case to the evidence.
- Products covered
- 18
- Checks
- 1,258
- Baselines
- DISA STIG · CIS · vendor
DISA STIG Apache Tomcat Application Server 9 V3R4
V-222931TCAT-AS-000060CAT I
Default password for keystore must be changed.
conf/server.xml
<Certificate type="RSA" certificateKeystorePassword="changeit" />- FoundAssessed against V3R4
- OpenTracked as CAT I
- Re-checkedAfter the fix
- Verified closedEvidence written
01The layer in between
Every server in that layer has its own baseline.
Between the operating system and your application sit the servers that carry the traffic: application servers, web servers, gateways and message brokers. Each has its own DISA STIG, CIS benchmark or vendor guidance, and each version has its own rules.
Someone has to check every instance against the right one, track every CVE that hits its version, plan the patches, chase the vendors, get the right teams in a room, re-check what's been fixed and write it up for the assessor.
COMPLY's agents carry all of it, end to end.
- Your applicationYour code and its dependencies
- Handled by COMPLYMiddlewareApplication servers · web servers · gateways · message brokers
- Operating systemLinux and Windows hosts
- InfrastructureCloud, network and storage
Three of those servers and their baselines
Apache Tomcat 9
- DISA STIGV3R479checks
- CISv1.2.0, Level 120checks
Oracle WebLogic Server 12c
- DISA STIGV2R273checks
Microsoft IIS 10.0
- DISA STIGServer V3R740checks
- DISA STIGSite V2R1544checks
- CISv1.2.1, Level 140checks
02Product
Three systems, one AI remediation loop.
A failed STIG rule, a new CVE and a missing patch all go into the same loop, and stay there until they're fixed and proven fixed.
STIG and CIS checks
Every app server, web server, gateway and broker, checked rule by rule against its DISA STIG, CIS benchmark or vendor baseline.
+ AI remediation loop
CVE live tracker
Every instance mapped to every CVE that hits its exact version, from NVD, CISA's KEV catalog and vendor advisories, and kept live as new ones land.
+ AI remediation loop
Patch management
What needs patching, which patch, in what order and by when, tracked until every patch is applied and verified.
+ AI remediation loop
The AI remediation loop
- Opens the case with the vendor
- Sets up the meetings
- Follows up until it moves
- Loops in your patch, middleware and cyber teams
- Closes it verified, with the evidence
Run it fully AI-native, or with AI in the loop and your people approving each change.
03How it works
From first scan to verified closed, in five steps.
| Instance | Product · Baseline |
|---|---|
| tc-prod-03 | Apache Tomcat 9DISA STIGCISExtension |
| wls-prod-01 | Oracle WebLogic Server 12cDISA STIG |
| iis-web-02 | Microsoft IIS 10.0DISA STIGCIS |
| edge-01 | NGINXCISExtensionDevSec |
| mq-01 | RabbitMQVendorExtension |
02
Assess
Each instance is checked rule by rule against its STIG, CIS benchmark or vendor guidance, and its version against NVD, CISA's KEV catalog and vendor advisories.
6 of 79 rules shown
- V-222931 · CAT IDefault password for keystore must be changed.Finding
- V-222935 · CAT IIConnectors must be secured.Pass
- V-222932 · CAT IICookies must have secure flag set.Pass
- V-222933 · CAT IICookies must have http-only flag set.Pass
- V-222956 · CAT IIAutodeploy must be disabled.Finding
- V-222951 · CAT IIThe shutdown port must be disabled.Pass
- Passed
- 4
- Findings
- 2
03
Plan
Every failed rule, CVE and missing patch lands in one plan: what changes, who owns it and when it's due, by severity, FedRAMP's timeframes or CISA's KEV dates.
Fix plan · 3 items, soonest due first
- CVE-2025-24813 · KEVApache Tomcat path equivalence
- Fix
- Upgrade to 9.0.99
- Due
- KEV due date
- Owner
- Patch team
- V-222931 · CAT IDefault password for keystore must be changed.
- Fix
- Change the keystore password
- Due
- CAT I deadline
- Owner
- Middleware team
- V-222956 · CAT IIAutodeploy must be disabled.
- Fix
- Set autoDeploy to false
- Due
- CAT II deadline
- Owner
- Middleware team
04
Coordinate
The agents open the tickets and the vendor case, set up the meetings, follow up, and bring your patch, middleware and cyber teams together until the change is approved.
CVE-2025-24813 · KEV
Apache Tomcat 9: Upgrade to 9.0.99
- Vendor
- Patch team
- Middleware team
- Cyber team
- Ticket openedIn Jira, for the patch team
- Vendor case openedAsked the app's vendor to confirm 9.0.99
- Meeting setVendor, patch, middleware and cyber teams
- Followed upVendor confirmed 9.0.99 in writing
- Change approvedBooked for Saturday's maintenance window
05
Verify
The fix goes in, applied by the agents or by your engineers. COMPLY re-scans to prove it took, then writes the evidence and closes the POA&M item.
- Instance
- tc-prod-03.example.com
- Problem
- CVE-2025-24813 · KEVApache Tomcat path equivalence
- Fix
- Upgraded Apache Tomcat 9.0.98 to 9.0.99
- Re-scan
- 9.0.99 confirmed; the CVE no longer applies
- Rollback
- 9.0.98 and its config kept with the change
- Filed to
- POA&M item closed
- Continuous monitoring report updated
- Status
- Verified closedRe-scanned after the fix
04Built in
The deadlines, the proof and the paperwork come with every fix.
Deadline clocks
Every fix gets its due date from its severity, FedRAMP's remediation timeframes or CISA's KEV due date, and the agents chase it before it lapses.
Proof after every fix
A re-scan shows each fix took, and every change carries its rollback note.
Tickets and change
Jira or ServiceNow tickets and change requests, opened and updated by the loop, with the maintenance window booked.
Exceptions, with evidence
Risk acceptances, false positives and vendor-blocked items, each tracked with its evidence until it's closed or renewed.
End-of-life watch
Versions nearing the end of vendor support, flagged early enough to plan the upgrade.
FedRAMP outputs
POA&M items and the monthly continuous monitoring report, kept current straight from the loop.
Connected to the systems you already run
- CMDB
- ServiceNow CMDB or your own: instances and owners read from it and kept in step
- Tickets and change
- Jira and ServiceNow: tickets, change requests and maintenance windows
- Chat
- Slack and Microsoft Teams: updates and approvals where your teams already talk
- Calendars
- Outlook and Google Calendar: meetings with vendors and teams, set up for you
- Vendor cases
- Each vendor's own support channel: cases opened and followed up
- Evidence
- Filed where your assessors and auditors look for it
05Governance
You decide how far the agents go.
Every loop runs either way, for every kind of fix: STIG and CIS findings, CVEs and patches alike.
Fully AI-native
- The agents apply each fix themselves, inside the scope you set
- Scoped by environment, kind of change and maintenance window
- Every change re-scanned, with its rollback note
AI in the loop
- The agents prepare the change, the ticket and the rollback note
- Nothing changes until a named approver signs off
- Your engineers or the agents apply it, as you choose
In both modes
- Written permissions for every agent
- Every agent action logged: what, when and on whose approval
- Approvals that follow your own change control
06Coverage
Coverage, counted from the checks themselves.
Every number here is read from COMPLY's control packs each time this page is built. Nothing is typed in by hand.
1,258checks across 18 products and 40 baselines
| Baseline | Checks | DISA severity |
|---|---|---|
| Apache Tomcat 9108 checks | ||
| DISA STIGV3R4 | 79 | CAT I 4, CAT II 54, CAT III 21 |
| CISv1.2.0, Level 1 | 20 | None listed |
| Extensionserver.xml, catalina.properties, connector and shutdown hardening9 checks across 3 controls | 9 | None listed |
| Oracle WebLogic Server 12c73 checks | ||
| DISA STIGV2R2 | 73 | CAT I 5, CAT II 49, CAT III 19 |
| Oracle WebLogic Server 14c73 checks | ||
| DISA STIG12c V2R2 rules, back-ported to 14c | 73 | None listed |
| IBM WebSphere Traditional 9.x77 checks | ||
| DISA STIGV2R1 | 77 | CAT I 9, CAT II 56, CAT III 12 |
| IBM WebSphere Liberty143 checks | ||
| DISA STIGV2R4 | 30 | CAT I 7, CAT II 23, CAT III 0 |
| CISv1.0.0, Level 1 | 105 | None listed |
| CISv1.0.0, Level 2 | 8 | None listed |
| Red Hat JBoss EAP 6.367 checks | ||
| DISA STIGV2R6 | 67 | CAT I 10, CAT II 56, CAT III 1 |
| Red Hat JBoss EAP 7.411 checks | ||
| VendorRed Hat security and configuration guides | 11 | None listed |
| Red Hat JBoss EAP 8.0 and 8.112 checks | ||
| VendorRed Hat security documentation | 12 | None listed |
| WildFly 26 and later28 checks | ||
| VendorWildFly Elytron security documentation | 12 | None listed |
| ExtensionServer hardening | 16 | None listed |
| Spring Boot27 checks | ||
| VendorSpring Boot and Spring Security reference | 24 | None listed |
| ExtensionActuator and TLS hardening | 3 | None listed |
| Baseline | Checks | DISA severity |
|---|---|---|
| Apache HTTP Server 2.4189 checks | ||
| CISControls mapped to the CIS Apache HTTP Server 2.4 Benchmark189 checks across 67 controls64 cite CIS and 4 cite a DISA STIG | 189 | None listed |
| IBM HTTP Server 8.5.511 checks | ||
| VendorIBM HTTP Server and mod_ibm_ssl documentation | 11 | None listed |
| IBM HTTP Server 9.0.548 checks | ||
| VendorIBM HTTP Server and mod_ibm_ssl documentation | 11 | None listed |
| ExtensionApache 2.4 hardening for IBM HTTP Server | 37 | None listed |
| Microsoft IIS 10.0124 checks | ||
| DISA STIGServer V3R7 | 40 | CAT I 4, CAT II 34, CAT III 2 |
| DISA STIGSite V2R15 | 44 | CAT I 2, CAT II 42, CAT III 0 |
| CISv1.2.1, Level 1 | 40 | None listed |
| NGINX81 checks | ||
| CISv2.1.0 | 58 | None listed |
| ExtensionHeader, TLS and timeout hardening | 9 | None listed |
| DevSecDevSec NGINX Baseline14 checks across 10 controls9 cite CIS | 14 | None listed |
| Baseline | Checks | DISA severity |
|---|---|---|
| HAProxy45 checks | ||
| VendorHAProxy configuration manual and TLS guidance | 36 | None listed |
| ExtensionTLS and privilege hardening | 9 | None listed |
| Kong Gateway10 checks | ||
| VendorKong secure Admin API guide | 8 | None listed |
| ExtensionAdmin API and TLS hardening | 2 | None listed |
| Traefik11 checks | ||
| VendorTraefik operations documentation | 9 | None listed |
| ExtensionAPI and TLS hardening | 2 | None listed |
| Baseline | Checks | DISA severity |
|---|---|---|
| Apache Kafka39 checks | ||
| VendorApache Kafka and Confluent security guides | 33 | None listed |
| ExtensionBroker security hardening | 6 | None listed |
| Apache ActiveMQ Classic11 checks | ||
| VendorActiveMQ security documentation | 9 | None listed |
| ExtensionAuthentication hardening | 2 | None listed |
| RabbitMQ32 checks | ||
| VendorRabbitMQ production checklist and security guides | 29 | None listed |
| ExtensionTLS and authentication hardening | 3 | None listed |
| Apache ZooKeeper38 checks | ||
| VendorZooKeeper administrator and SSL guides | 33 | None listed |
| ExtensionSecurity hardening | 5 | None listed |
- DISA STIG · CIS
- Rules from the published STIG or CIS benchmark, release by release.
- Vendor
- Checks drawn from the vendor's own security documentation.
- Extension
- Additional hardening checks COMPLY runs on top of the baseline.
- DevSec
- Checks drawn from the open-source DevSec Hardening Framework.
CAT I is DISA's most severe category, CAT III the least.
07Frameworks
Built around the baselines your framework names.
The service provider shall use the DoD STIGs1 to establish configuration settings; Center for Internet Security up to Level 2 (CIS Level 2)2 guidelines shall be used if STIGs are not available; Custom baselines3 shall be used if CIS is not available.
ISO/IEC 27001:2022
Annex A 8.9
Configuration management
PCI DSS v4.0.1
Requirement 2.2.1
Configuration standards
Also for teams running SOC 2 and HIPAA programs.
08FAQ
Questions, answered plainly.
The servers between the operating system and your application: application servers, web servers, gateways and proxies, and message brokers.
COMPLY covers Apache Tomcat, Oracle WebLogic Server, IBM WebSphere Traditional, IBM WebSphere Liberty, Red Hat JBoss EAP, WildFly, Spring Boot, Apache HTTP Server, IBM HTTP Server, Microsoft IIS, NGINX, HAProxy, Kong Gateway, Traefik, Apache Kafka, Apache ActiveMQ Classic, RabbitMQ and Apache ZooKeeper today. The coverage table shows every baseline for each.
Each product is assessed against the baselines listed for it in the coverage table: a DISA STIG, a CIS benchmark or the vendor's own security guidance.
For FedRAMP, CM-6(a) sets the order: DISA STIGs first, CIS up to Level 2 where STIGs are not available, and custom baselines where CIS is not available.
They can. Run fully AI-native, the agents apply each fix themselves, inside the scope you set, and re-scan to prove it took.
Run with AI in the loop, they prepare the change, the ticket and the rollback note, and nothing changes until a named approver signs off. Either way, every loop works the same: STIG and CIS findings, CVEs and patches.
The agents open the case with the vendor, set up the meetings and follow up until the fixed build or patch arrives, with your patch, middleware and cyber teams looped in at each step.
Until then the item is tracked as vendor-blocked, with its evidence, so the wait is on the record.
Every agent works under written permissions, and every action it takes is logged: what it did, when, and on whose approval. Approvals follow your own change control, so changes land through your tickets and change requests, in your maintenance windows.
No. FedRAMP names DISA STIGs outright; ISO/IEC 27001:2022 has Annex A 8.9, Configuration management, and PCI DSS v4.0.1 has Requirement 2.2.1 on configuration standards. COMPLY is also for teams running SOC 2 and HIPAA programs.
Fifteen minutes on a representative setup for your stack: COMPLY finds the instances, checks them against their baselines and CVEs, and carries one fix through the loop to verified closed, with the evidence.
Nothing to install beforehand, and no access to your environment needed.
What an assessor needs to follow the work: the baseline or CVE each item was held to, what was found, what changed, the re-scan that proved it and when it was verified closed.
For FedRAMP, the loop keeps the POA&M and the monthly continuous monitoring report current. The walkthrough shows a complete example.
09Walkthrough
See it on a setup like yours.
Fifteen minutes. A walkthrough of COMPLY on a representative setup for your stack.
- One fix carried from the first scan to verified closed
- Both modes: fully AI-native and AI in the loop
- Nothing to install beforehand
- No access to your environment needed
Rather book in a new tab? Open the booking page (opens in a new tab)