Advisors

BootUI's advisors run explicit, on-demand, rule-based scans and surface severity-ranked findings that feed the weighted score on the Overview dashboard. Each advisor is read-only and inspects a different facet of the application — compiled architecture, the REST layer, the live Spring context, persistence, JVM memory, and security. Once an advisor has run, its panel shows the same 0–100 score the Overview computes for it (100 minus the weighted finding penalty), so panel and dashboard always agree.

Single-flight scans

Expensive advisor actions are single-flight per scanner: a second tab, Overview card, REST caller, or MCP tool cannot start a scanner while it is active. Duplicate REST requests fail immediately with the shared 409 busy response, and MCP reports the same message as an in-band tool error. The panel keeps the last completed report and Overview score visible and shows the conflict as a warning. Different scanners remain independent.

Dismissing findings

Every advisor finding can be dismissed when it does not apply to your project. Each rule result carries a Dismiss button; dismissing moves the rule into a collapsed "Dismissed rules" list and excludes it from the panel's finding count, severity bars, advisor score, and the weighted Overview score. The panel's score recomputes immediately, and the Overview dashboard re-reads the advisor's score when you return to it, so a dismissal or restore shows in both places. Rules can be restored at any time from that list.

Kotlin applications

The bytecode-driven advisors — Architecture, REST API, and Hibernate — are Kotlin-aware. They read compiled classes, so they work on Kotlin without configuration, and BootUI recognizes Kotlin constructs by bytecode name only: no kotlin-stdlib dependency is added to your application, and the behaviour is identical on Spring MVC, Spring WebFlux, and Quarkus because it lives in the shared engine.

• Compiler-generated members and classes — $suspendImpl / $default bridges, componentN and copy accessors on data classes, Companion and DefaultImpls holders, WhenMappings tables, and top-level FooKt file facades — are filtered out, so they never appear as findings.
• Suspending functions are judged on their declared signature: the implicit kotlin.coroutines.Continuation parameter is hidden, the real result type is read from it, and kotlin.Unit counts as void.
• Properties are judged as properties. A lateinit var on an entity is not a public field finding: the compiler must leave its backing field public, but every access goes through the generated accessor pair. A @JvmField var, which has no accessors, is still reported.
• Nested types are read with their enclosing name. The variants of a sealed class exception hierarchy are not renaming findings, because ClaimException.AlreadyAssigned already says what it is.
• Suppressing the compiler's noise never suppresses your code. A call routed through a $default bridge is followed through to the function it dispatches to, and a self-invocation written inside a lambda stays reported even though the compiler hides the body in a synthetic method.
• Where an idiomatic Java fix does not translate, the recommendation offers the Kotlin equivalent — marking a class open or applying the kotlin-spring plugin instead of "remove final", and constructor val injection instead of an @Autowired lateinit var.

See Architecture checks, REST API checks, and Hibernate checks for the per-rule notes.

Architecture

The Architecture panel runs a curated, zero-config ArchUnit ruleset against the host application's own compiled classes at runtime. It detects the base package from the @SpringBootApplication configuration, imports the classes from that package, and evaluates a fixed set of universally-sensible hygiene rules: package cycles between slices, general coding practices (banned APIs, unsafe patterns, naming and immutability conventions), and Spring stereotype/proxy heuristics (no field injection, correct layering, no self-invocation, proxyable annotations). See ARCHITECTURE-CHECKS.md for the full catalogue and what each rule inspects.

When BootUI is installed through bootui-spring-boot-starter, ArchUnit is included transitively; the panel is available when a base package is resolvable, and the scan runs on demand and caches the last report. Generic rules are less powerful than project-authored ArchUnit tests, so the panel is a starting-point and review aid that complements — not replaces — a project-specific ArchUnit test suite. Each rule carries a stable identifier, category, severity, and recommendation; the results list shows only violating rules, sorted by severity and violation count.

Not available in GraalVM native images. The advisor scans compiled .class files via ArchUnit's ClassFileImporter, which is incompatible with a native executable; the panel is automatically hidden when the application is detected to be running as a native image.

REST API

The REST API panel runs a curated, zero-config ruleset against the host application's own web layer — @RestController / @Controller handler methods on Spring, or JAX-RS resources on Quarkus. Like the Architecture panel, it imports the compiled handlers from bounded base packages and derives a read-only model: HTTP method(s), path(s), parameters and annotations, return type, produces/consumes, validation flags, and declared throws. It then evaluates 56 REST best-practice rules across eight categories: routing and HTTP-method mapping, resource naming, status codes and responses, input validation and binding, DTO and payload contracts, pagination, versioning and content negotiation, and error handling and documentation. The RAPI-DOC-* rules only run when Swagger or MicroProfile OpenAPI annotations are on the host classpath.

The advisor deliberately avoids security concerns (CORS, authentication, authorization), which the Security panel owns. The scan runs on demand and caches the last report; each rule carries a stable identifier, category, severity, recommendation, and a learn-more link, and the results list shows only flagged rules, sorted by severity and finding count. The heuristics complement — not replace — an API design review or contract testing. See REST-API-CHECKS.md for the full catalogue and what each rule inspects.

Declared error contract

The panel also shows the application's declared error contract: every @ControllerAdvice / @RestControllerAdvice / @ExceptionHandler method on Spring MVC and WebFlux, and every Jakarta REST @Provider ExceptionMapper and Quarkus REST @ServerExceptionMapper on Quarkus. Each row names:

• the handled exception type;
• the declaring component and method;
• the scope (application-wide, narrowed, or controller-local);
• the resolved precedence;
• the declared HTTP status;
• the response-body category (RFC 9457 ProblemDetail, custom object, string, empty, or explicitly unresolved);
• the declared media types.

This is a pure declaration read: no handler is instantiated or invoked, no request is synthesized, and no exception is thrown to observe a response — so anything the declarations cannot prove is reported as unresolved rather than guessed. Only the application's own declarations are listed. The handlers the framework contributes (Spring Boot's BasicErrorController, Quarkus's built-in RESTEasy Reactive and Jackson mappers) are identical everywhere, so an application that declares nothing shows an empty catalogue on all three stacks. When a retained Exceptions-panel failure can be attributed to exactly one declared handler, that panel links straight to the declaration here; ambiguous and unmatched failures stay unlinked.

Not available in GraalVM native images. The advisor scans compiled .class files via ArchUnit's ClassFileImporter, which is incompatible with a native executable; the panel is automatically hidden when the application is detected to be running as a native image.

Spring

The Spring panel runs an explicit, read-only scan of the host application's running Spring application context and Environment. It takes a bounded snapshot of selected bean groups (Jackson ObjectMappers, TaskExecutors, DataSources) and feature flags, then evaluates a curated ruleset across bean wiring, configuration hygiene, profiles and environment, performance and concurrency (including virtual threads), web/HTTP settings, data and persistence, Actuator/management exposure, and reactive (WebFlux-only) checks. See SPRING-CHECKS.md for the full catalogue and remediation links.

Because it runs inside the already-started application, it focuses on "started but suboptimal" states rather than fatal startup conditions. It complements the Architecture panel — which statically analyzes compiled bytecode — by inspecting the live, wired runtime context instead. The report is a heuristic review prompt, not a verdict: it never mutates the context, intercepts live traffic, or surfaces secrets. The ruleset detects whether the host runs the servlet (Spring MVC) or reactive (Spring WebFlux) stack and adjusts a handful of rules accordingly.

This single framework-application advisor is relabelled per framework: Spring on the Spring Boot adapter, Quarkus on the Quarkus adapter — the same menu slot, /bootui/api/spring contract, and report shape. The Quarkus section below covers the Quarkus flavour.

Quarkus

On the Quarkus adapter the framework-application advisor above is relabelled Quarkus and runs a Quarkus-native idiom ruleset in place of the Spring rules. It takes the same explicit, read-only approach against the running application and its MicroProfile Config, but the rules target Quarkus idioms:

• CDI/Arc scopes and shared mutable state on @ApplicationScoped/@Singleton beans.
• Build-time type-safe configuration (@ConfigProperty vs @ConfigMapping).
• Reactive-versus-blocking endpoints and @Scheduled clustering.
• Production-profile hygiene (destructive Hibernate schema strategies, SQL logging).

It is the same panel and menu slot as the Spring advisor — the same /spring route, /bootui/api/spring endpoint, and report contract — so the shared UI simply renders the "Quarkus" label and copy. The report is a heuristic review prompt, not a verdict. See QUARKUS-ADVISOR-CHECKS.md for the full catalogue and remediation links.

Database

The Database panel introspects the physical schema of every discovered application DataSource bean through plain JDBC DatabaseMetaData — tables, columns, primary keys, foreign keys, and indexes — and evaluates a fixed, on-demand ruleset of deterministic, low-false-positive structural checks. It never executes DDL and never queries application data. See DATABASE-ADVISOR-CHECKS.md for the full catalogue and remediation links.

It reuses the same proxy-aware datasource discovery as Database Connection Pools and SQL Trace, de-duplicating by the physical pool behind BootUI's own SQL Trace proxy so a wrapped datasource is never introspected twice. Spring's delegating and routing DataSource wrappers are resolved rather than ignored: one is skipped only when the pool it forwards to is a bean of its own, so the pool inside a LazyConnectionDataSourceProxy (what spring.datasource.connection-fetch=lazy installs) is still inspected, and a routing datasource is expanded into its resolved targets, named beanName[lookupKey].

Bounded, honest scans

Every scan runs under fixed bounds and reports exactly what it could not do:

• at most 300 tables, 300 columns and 100 indexes per table, 500 rows per catalog query;
• an overall 20-second budget and a 5-second timeout on every catalog statement.

A reached bound is detected deterministically by reading one row past it, and the connection's original read-only state is restored before it returns to the pool. A datasource that could not be read, a refused table, a catalog view a role cannot see, a truncated scan, and every skipped or errored rule are reported as per-datasource statuses and diagnostics — never as passing checks, and never counted as findings or against the score. Credentials in a JDBC URL or a driver error message are always redacted.

A catalog query blocked by restricted privileges makes its rule report SKIPPED with that reason instead of silently reporting no findings.

Dialect-specific augmentation

For PostgreSQL, MySQL, MariaDB and Oracle (19c+), dialect-specific catalog augmentation runs in addition to the generic checks.

Where the vendor catalog can answer, index semantics JDBC cannot express are folded into the shared model — validity, partial predicates, expression and prefix key parts, access method, visibility, and (Oracle) whether an index backs a constraint or is a specialized type. Every index rule can then ask "does this index actually support that lookup, or enforce that uniqueness?" instead of comparing bare column-name lists.

Hibernate cross-reference

When a Hibernate EntityManagerFactory/metamodel is also available for the same application, the panel additionally cross-references the physical schema against the mapped JPA entities, using the same shared metamodel reader the Hibernate panel uses. This half is skipped (with a clear reason, not silently dropped) when either a DataSource or a Hibernate metamodel is unavailable.

Hibernate

The Hibernate panel runs an explicit, read-only scan against the JPA EntityManagerFactory metamodel when Hibernate ORM is present. It reviews mapped entities, selected persistence configuration, and Spring Data repository metadata for common Hibernate/JPA performance and mapping risks such as eager fetching, problematic identifier generators, collection fetch pagination, unsafe cascades, cache misconfiguration, and risky ddl-auto values. The report is a review prompt, not a verdict: it never intercepts queries, invokes repositories, executes SQL, or modifies mappings. See HIBERNATE-CHECKS.md for the full catalogue and remediation links.

Memory

The Memory panel runs an explicit, read-only scan over the live JVM management beans — heap and memory pools, garbage collection, threads, loaded classes, and an optional class histogram. It turns them into severity-ranked findings such as heap pressure, metaspace saturation, native-footprint risk inside a container, lifetime GC overhead, thread deadlocks, and collection bloat. It complements the raw Live Memory and Threads panels by diagnosing the data they expose. The scan is on demand and caches the last report; new rules are added as small, focused classes in the memory package. See MEMORY-CHECKS.md for the full catalogue and remediation links.

Security

The Security panel runs an explicit, read-only scan of the host application's security configuration to flag common hardening gaps across authentication, authorization, CSRF, session management, transport/security headers, CORS, method security, actuator exposure, OAuth2 resource-server validation, and configuration hygiene. The report is a review prompt, not a verdict: it never intercepts live traffic, exposes credentials, keys, or session identifiers, or modifies the security configuration.

The advisor supports all three runtime security stacks from the same panel, menu slot, and /bootui/api/security report contract.

Spring Boot (Spring Security)

On Spring Boot it analyses Spring Security when it is on the classpath: it introspects the registered SecurityFilterChain beans, simulates an anonymous authorization decision, and inspects security-relevant beans (PasswordEncoder, CorsConfigurationSource, JwtDecoder) and Environment properties. See SECURITY-CHECKS.md for the full catalogue and remediation links.

Spring WebFlux

On Spring Boot WebFlux it evaluates a dedicated 26-rule SEC-RXF-* catalogue over a framework-neutral observation of the application's SecurityWebFilterChain beans, reactive CORS/OAuth2 beans, and security-relevant configuration. The Spring adapter owns collection and excludes BootUI's own permit-all chain; the shared engine owns deterministic rule evaluation and never receives Spring types or secret values.

Pentesting

The Pentesting panel runs explicit, local-only OWASP Top 10 2025 hygiene checks against the host application, not BootUI's /bootui routes. On an explicit scan it combines bounded framework metadata with at most one GET and one OPTIONS request to literal 127.0.0.1 under the validated application context path; the two-second client never follows redirects or uses configured proxies. Checks cover missing or unsafe browser-document headers, CORS behavior, cookie flags, verbose error exposure, Spring Security wiring, actuator exposure, Quarkus CORS/OIDC/TLS configuration, and common Spring Boot hardening gaps.

It intentionally does not crawl discovered endpoints, send SQL/XSS/destructive payloads, contact external hosts, or include raw response bodies, cookie values, credentials, or full issuer URLs. Findings are heuristic review prompts, not proof of exploitability or a replacement for a full security assessment.

The 80 active checks each carry a stable identifier, OWASP 2025 category, evidence source, and recommendation. No-finding category coverage is informational rather than a pass. Failed or bounded-away evidence produces a PARTIAL scan, hides the advisor score, and marks affected coverage INDETERMINATE. See PENTEST-CHECKS.md for the full catalogue, limits, mappings, and retired IDs.

Per-stack coverage

• Spring MVC is the complete reference collector.
• Spring WebFlux still contributes Spring configuration and OAuth metadata, but explicitly reports MVC mapping and servlet-filter evidence unavailable; its reactive Security advisor owns SecurityWebFilterChain route policy.
• Quarkus runs the same shared scanner/report contract and supplies its live port, root path, CORS, OIDC, and direct-listener TLS configuration while explicitly marking Spring endpoint/security metadata unavailable.

The coverage matrix uses platform-specific wording, so neither adapter turns unsupported checks into a false clean result.

Vulnerabilities

The Vulnerabilities panel shows dependency inventory and local OSV vulnerability scan results, helping identify known-vulnerable dependencies from the running project's dependency set during the local development loop. Findings are ordered by severity first (dismissed findings sink to the bottom regardless of severity), with dependencies and advisories alphabetized within the same severity.

Severity scoring

Severity is derived from OSV.dev's severity[] entries, whose type says how the score must be interpreted. BootUI computes only CVSS_V3 entries carrying a CVSS v3.0/v3.1 vector; it never treats a bare number or another provider's scale as CVSS. CVSS 0.0 is reported as NONE, matching FIRST's qualitative scale. An advisory with neither a parseable CVSS v3 score nor a database_specific label renders as UNKNOWN rather than being silently dropped.

OSV querying and robustness

Advisories carrying a withdrawn timestamp are excluded. OSV omits withdrawn records from POST query responses but returns them from GET /v1/vulns/{id}, so the scanner keeps a defensive detail-stage check. Detail fetches run with a small bounded concurrency (up to 10 at a time), so a dependency tree with many advisories no longer risks a scan taking up to maxAdvisories times the request timeout on a bad network (OSV documents no rate limit for this endpoint). A single detail fetch that fails (network hiccup, rate limiting) no longer aborts the whole scan: it is counted, the scan degrades to PARTIAL, and every advisory that did fetch is kept.

EPSS enrichment

Each advisory whose own id or aliases includes a canonical CVE-* id is additionally enriched with EPSS (Exploit Prediction Scoring System) data from FIRST.org's free, unauthenticated API. EPSS reports the modeled probability that a CVE will be exploited in the wild in the next 30 days, plus the percentile that probability ranks against every other scored CVE — a likelihood-of-exploitation signal that complements, rather than replaces, CVSS's severity-if-exploited score. It renders as a secondary badge next to the severity/CVSS badge (for example "2.3% EPSS", with a tooltip spelling out the percentile).

Fix availability

Each advisory carries a derived fixAvailable boolean, computed by comparing the dependency's currently-resolved version against the advisory's Maven fixed-version candidates with ComparableVersion qualifier ordering (including alpha/beta/milestone/RC/SNAPSHOT/release/service-pack semantics). Git commit hashes from GIT ranges are not presented as Maven upgrades, and candidates are de-duplicated and sorted using Maven semantics. The UI renders a newer candidate as "fixed in x.y.z"; if every reported candidate is at or below the installed version, it says only that OSV reported no newer fixed version, never that the installed dependency is fixed. When OSV reports no fixed event, the UI says only "No fixed version reported by OSV": under the OSV schema a range may instead close with a mutually exclusive last_affected event, which names the final vulnerable version without naming the first non-vulnerable one, so absence of fixedVersions is not proof that no fix exists.

Dismissing a vulnerability

Like every other advisor, a vulnerability can be dismissed when it does not apply (already patched downstream, accepted risk, or a fix not yet available upstream) — see the shared dismiss/restore explanation at the top of this page. The one difference is the dismissal key's shape. Because a vulnerability is scoped to one dependency, it is keyed by <vulnerability id>::<package name> (for example GHSA-xxxx-xxxx-xxxx::org.example:sample) rather than a bare rule id. So dismissing a finding for one dependency never hides the same advisory id reported against a different dependency, and a dismissal survives a patch-version bump of the still-vulnerable dependency. Dismissed vulnerabilities stay visible (dimmed, with a Restore button), are excluded from the per-dependency and panel-level vulnerable counts, and trigger a fresh deterministic ordering from the recomputed active severity. Dismiss/restore controls are disabled when the panel is read-only.

Coverage

A coordinate-based inventory can only scan what it can name, so the panel also reports what it couldn't. Alongside the inventory, BootUI takes a census of the application's real archives — the BOOT-INF/lib//WEB-INF/lib/ entries of a repackaged JAR or WAR, or the classpath JARs when running exploded — and attributes each to a resolved coordinate. The result is one of three honest states:

When coverage is incomplete the panel shows an "Unidentified JARs" metric and a warning naming the gap ("139 of 325 JARs could not be identified and were not scanned"), with a collapsible list of the archive names and a pointer to adding the CycloneDX plugin to the build. Unidentified archives deliberately stay out of the scannable dependency table — they have no coordinates to show. Only the archives' central directories and manifests are read; nothing is decompressed or extracted.

The scan status reports the same kind of gap for the bootui.vulnerabilities.max-packages bound: packages beyond it are counted in scan.packagesSkipped and surfaced as a warning, instead of letting packagesScanned present a truncated scan as a complete one. The default bound is 500, sized to cover a typical Spring Boot application's full JAR set.

Known limitations

Three limitations are documented honestly rather than hidden — and, where a gap remains, it is reported through coverage rather than left silent:

• Without an SBOM, some JARs cannot be identified. No JAR manifest header carries a groupId (Implementation-Title is a display name as often as an artifact id, and Implementation-Vendor-Id is not a group id), so an application built without a CycloneDX SBOM cannot resolve coordinates for artifacts published with no Maven descriptor — Spring Framework, Spring Boot, Spring Security, tomcat-embed-*, hibernate-core, kotlin-stdlib, the PostgreSQL driver, and the opentelemetry-*/micrometer-* families among them. Those archives are reported as unidentified rather than dropped. Resolving them by SHA-1 lookup against Maven Central would work but adds a new outbound service and configuration surface, so it is deliberately not done.
• Shaded/uber JARs are invisible. The inventory on both adapters is coordinate-based (one resolved JAR = one Maven groupId:artifactId:version), so a vulnerable library relocated or repackaged inside a shaded/uber JAR carries no pom.properties/build-time coordinate of its own and is invisible — the same reduced-fidelity honesty precedent applied to other panels (for example Cache, Beans).
• No direct-vs-transitive provenance yet. "Introduced through" is not tracked on either adapter. Quarkus could source it from its build-time application dependency graph, but Spring's classpath-based inventory has no equivalent graph today (adding one would need POM/Maven-plugin integration, a much larger change), so this is deferred rather than shipped as a Quarkus-only asymmetry.