Advisors

Each report has additive violationDetails metadata:

While another scan is running, detail reads still refer to the previous completed snapshot; publishing its replacement changes the ID. Dismiss and restore change neither the ID nor the retained details. Retention completeness is not evidence coverage or score eligibility. truncated can also mean the source exposed only aggregate detail, as for Quarkus Security's QS-AUTHZ-004; BootUI never fabricates identities to fill that gap.

# Read only the cached report; this does not run a scan.
curl -s http://localhost:8080/bootui/api/architecture | jq '.violationDetails'
# Substitute the returned scanId, retaining the same value for every page.
curl -sG http://localhost:8080/bootui/api/architecture/rules/ARCH-SPRING-004/violations \
  --data-urlencode 'scanId=<returned-scan-id>' --data-urlencode 'offset=0' --data-urlencode 'limit=100'

bootui architecture violations ARCH-SPRING-004 --scan-id '<returned-scan-id>' --offset 0 --limit 100

{
  "name": "get_architecture_rule_violations",
  "arguments": {"id": "ARCH-SPRING-004", "scanId": "<returned-scan-id>", "offset": 0, "limit": 100}
}

The page contains scanId, ruleId, the full violationCount, retainedCount, truncated, sanitized violations, page: {total, matched, offset, limit, returned, hasMore}, and locations. page.total and page.matched count retained entries. To continue, set the next offset to page.offset + page.returned while page.hasMore is true, keeping the same scan ID, and still check truncated on the last page.

Invalid, blank, negative, fractional, or overflowing arguments are rejected. An MCP -32003 response-byte refusal is an error, not an empty page: retry the same scan ID and offset with a smaller limit. A missing or replaced snapshot returns 409; choose Refresh cached report (it never starts a scan), then View violations again. A rule id outside the advisor's catalogue answers Unknown advisor rule (REST 404, CLI-facade 400). Dismissed findings remain retrievable by ID. GraalVM/CRaC occurrences, Pentesting, and Vulnerabilities use different report models and are not covered.

• Architecture reads locations from ArchUnit's violating objects: the class, the member, and the line.
• REST API points at the handler method, exception handler, throwing endpoint, or controller class.
• Hibernate points at the entity class, the field or getter behind a mapped attribute, or a repository method. The JPA metamodel has no line numbers, so these stay at MEMBER or CLASS precision.

Source paths are resolved only during an explicit scan, through the Architecture advisor's bounded module and source-set lookup (see Generated application code). A class in a local Maven target/classes or Gradle build/classes directory maps to exactly one .java or .kt file. Classes read from an archive, other layouts, ambiguous matches, and an exhausted lookup budget keep a null path, and violationDetails.locationNotes says why. The lookup never follows symbolic links. Source paths describe the developer's own code, so they are not gated by the value-exposure policy.

A line is shown only when it belongs to the named member in the named file. Lines from Kotlin inlined code, past the end of the file, or from archive-read Kotlin classes drop to MEMBER precision rather than show a wrong one.

The backend's evidence object is the sole eligibility authority:

The browser never reconstructs applicability. MySQL and Oracle checks on a PostgreSQL-only application stay neutral skipped diagnostics. A SCANNED report with usable: false and coverageComplete: true has no score and reads Not applicable, for example an Architecture import that found no classes. Legacy reports without valid evidence stay unscored.

Known-severity dependency findings establish usability before dismissal. A fully assessed package does too when every retained advisory has a known severity, or the result is genuinely empty, and both assessment.queryComplete and assessment.detailAssessmentComplete are true. UNKNOWN findings stay visible with no penalty, and UNKNOWN-only evidence stays unscored unless independent usable evidence exists. Dismissed known findings remain evidence while their penalties are removed. Inventory, query, and detail gaps qualify a score rather than suppressing it. EPSS never decides eligibility.

The last accepted report stays visible during a new request and when transport fails. A newly received report replaces it.

Dismissals are persisted under the dismissedRules node of a local .bootui/boot-ui.yml file (next to the runtime overrides file), so they survive restarts and stay consistent between each panel and the Scorecard. The file is developer-local and intended to be git-ignored. Rule identifiers are globally unique across advisors. Pentesting scan reports are not persisted: findings and dismissal flags reappear after you explicitly run the first scan.

bootui.overrides-file moves both files together, which lets dismissals survive a container image rebuild. See Persisting console state across image rebuilds.

• Compiler-generated members and classes ($default bridges, data-class componentN/copy, Companion, DefaultImpls, WhenMappings, FooKt file facades) never appear as findings.
• Suspending functions are judged on their declared signature: the Continuation parameter is hidden and kotlin.Unit counts as void.
• A lateinit var on an entity is not a public-field finding; a @JvmField var still is.
• Variants of a sealed class exception hierarchy are not renaming findings.
• Suppressing compiler noise never suppresses your code: $default calls are followed through, and a self-invocation in a lambda stays reported.
• Recommendations offer the Kotlin equivalent, such as open or the kotlin-spring plugin and constructor val injection.

See Architecture checks, REST API checks, and Hibernate checks.

The panel runs the same ruleset and report contract. The java.util.logging check is skipped, standard-annotation field injection is reported at LOW, and Spring-only annotation rules find nothing. The Spring self-invocation rule is skipped because Arc supports intercepted self-invocation.

Quarkus has no @SpringBootApplication to read, so base packages are discovered at build time from the Jandex index. Discovery is single-module; the bootui.internal.base-packages key (comma-separated) overrides it.

• An advice that implements Ordered chooses its position at runtime, so its whole precedence group is ambiguous.
• A Spring handler without @ResponseBody renders a view, so its body category is unresolved.
• On Quarkus only @Provider-annotated ExceptionMappers are listed. :::

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 moves to the sidebar's Disabled / unavailable group and explains why.

Spring

The Spring panel runs an explicit, read-only scan of the running Spring application context and Environment. It takes a bounded snapshot of selected bean groups and feature flags, then evaluates a curated ruleset across bean wiring, configuration hygiene, profiles, performance and concurrency (including virtual threads), web settings, data and persistence, Actuator exposure, and reactive (WebFlux-only) checks. See SPRING-CHECKS.md.

It focuses on "started but suboptimal" states and complements the Architecture panel by inspecting the live, wired context. It never mutates the context, intercepts traffic, or surfaces secrets. On MVC, Open Session in View is reported as present, confirmed absent, or unknown from actual registration metadata. This advisor is relabelled per framework: Spring on Spring Boot, Quarkus on Quarkus, with the same menu slot and /bootui/api/spring contract.

Quarkus

On the Quarkus adapter the framework-application advisor is relabelled Quarkus and runs a Quarkus-native ruleset against the running application and its MicroProfile Config:

• Resolved CDI/Arc scopes: public fields on normal-scoped beans and public state on singleton beans and REST resources.
• Production configuration evidence: schema actions, SQL and bind-parameter logging, explicit in-memory storage.
• Managed REST-client timers, HTTP compression, and request-draining configuration.
• Conditional synchronized virtual-thread pinning on JDK 21-23.

Missing annotations or production overrides are not defects by themselves, and incomplete evidence is reported explicitly rather than treated as clean. See QUARKUS-ADVISOR-CHECKS.md.

Database

The Database panel introspects the physical schema of every discovered application DataSource through plain JDBC DatabaseMetaData (tables, columns, keys, indexes) and evaluates a fixed, on-demand ruleset of deterministic structural checks. It never executes DDL and never queries application data. See DATABASE-ADVISOR-CHECKS.md.

Each scan runs under fixed bounds (at most 300 tables, 300 columns and 100 indexes per table, a 20-second budget, a 5-second timeout per catalog statement) and reports what it could not do. Unreadable datasources, truncated scans, and skipped or errored rules appear as statuses and diagnostics, never as passing checks. Credentials in JDBC URLs and driver errors are redacted.

For PostgreSQL, MySQL, MariaDB, and Oracle (19c+), dialect-specific catalog checks run in addition to the generic ones. Every other database (H2, SQL Server, and so on) still runs the full generic ruleset. When a Hibernate metamodel is available, the panel also cross-references the physical schema against mapped JPA entities, and skips that half with a stated reason otherwise.

• An explicit association without a matching physical foreign-key constraint, excluding NO_CONSTRAINT.
• An explicit declared table or column name not observed in the scoped metadata.
• Supported nondefault nullability mismatches, not guessed Java-to-JDBC type mappings.
• A declared @Column(length=...) longer than a bounded physical string column.
• A positive @Column(precision=..., scale=...) wider than a bounded physical DECIMAL/NUMERIC column.
• A mapped unique constraint with no physical index that enforces it.
• An explicitly named @Id with GenerationType.IDENTITY whose PostgreSQL/MySQL/MariaDB column reports no auto-increment, identity, default, or generated value.

Only entities with an explicit @Table(name = ...) are cross-referenced. These are declaration-versus-observation reviews, not validation of the effective runtime mapping, since the advisor reads only the standard JPA metamodel and does not resolve the physical naming strategy. A mapped name matching tables in several datasources is treated as ambiguous. The panel proposes no query-based optimizations, execution-plan analysis, or index suggestions from usage.

The panel is identical, over the same report contract. DataSource beans are discovered through @Any Instance<DataSource> and de-duplicated by the physical pool behind BootUI's SQL Trace wrapper. Datasource names come from the Agroal @DataSource("...") qualifier, read reflectively so no io.agroal type is linked; otherwise they fall back to positional names (default, datasource-2). The Hibernate cross-reference needs quarkus-hibernate-orm.

The panel runs the same 72-rule registry when quarkus-hibernate-orm is present, discovering entities from the live EntityManagerFactory across all persistence units. Spring Data query rules skip when repository metadata is unavailable. Differences:

• Effective factory settings are unit-scoped. Named units do not inherit the first factory's values.
• Bytecode enhancement is always enabled, so known-absent-enhancement findings do not fire.
• Panache active-record entities are handled specially (see below).

(*) In Quarkus 3.33.3.1, an explicitly configured deprecated quarkus.hibernate-orm.database.generation takes precedence. Quarkus/Jakarta create is create-only, while Hibernate hbm2ddl.auto=create is destructive; the advisor preserves that difference.

With verified Panache transformation, the public-persistent-field finding does not fire, and the id field of Panache's base entity is ignored by the @GeneratedValue check.

On Quarkus it runs a Quarkus-native ruleset over the HTTP permission policies, MicroProfile Config, and annotated endpoints: Elytron/OIDC authentication, quarkus.http.auth.permission.* authorization, TLS and transport policy, forwarded-header proxy trust, CORS (including the wildcard-origin-with-credentials trap), response headers, and @RolesAllowed, @PermissionsAllowed, and @AuthorizationPolicy. The UI relabels metrics ("Permission policies" in place of "Filter chains"). See QUARKUS-CHECKS.md.

• Spring MVC is the complete reference collector.
• Spring WebFlux contributes Spring configuration and OAuth metadata, but reports MVC mapping and servlet-filter evidence unavailable. Its reactive Security advisor owns SecurityWebFilterChain route policy.
• Quarkus runs the same scanner and supplies its port, root path, CORS, OIDC, and HTTP-listener TLS configuration, while marking Spring endpoint metadata unavailable. Local HTTP does not assess proxy-edge HTTPS.

Unsupported checks never become a false clean result.

BootUI matches the exact Maven ecosystem and groupId:artifact, and evaluates the installed version against explicit versions and supported Maven ECOSYSTEM ranges. Applicability is matched, not matched, or unresolved; unsupported or malformed evidence never becomes an unaffected verdict. A positive OSV query keeps the finding as PARTIAL even when detail association is unsupported or contradictory.

It takes the highest valid v4 score across applicable package assessments, and only when none is valid the highest valid v3 Base score. Top-level severity is a fallback only when no applicable package severity is supplied. A recognized database_specific.severity label remains a compatibility fallback, otherwise UNKNOWN. MODERATE maps to MEDIUM.

v3.0/v3.1 vectors follow the FIRST CVSS v3.1 specification (Base metrics only). v4.0 vectors are scored with a port of FIRST's reference calculator; a supplied Threat metric such as E:U yields the CVSS-BT score, and supplemental metrics never change the score. Invalid segments, unknown metrics, and duplicates are rejected. CVSS v2 is not calculated.

The scanner follows OSV's next_page_token on /v1/querybatch, bounded by 20 page rounds per chunk (degrading to PARTIAL at the bound). The package list, already bounded by bootui.vulnerabilities.max-packages, is split into batches of at most 1,000 queries, OSV's hard limit. Detail fetches run with bounded concurrency (up to 10) and a configured advisory-detail cap. Request timeouts are not a whole-scan deadline.

Responses are validated, and malformed results fail visibly instead of reading as a clean scan. A later failure preserves earlier pages as PARTIAL; failure before any valid page is ERROR, with the local inventory retained.

The Spring adapter resolves coordinates from three sources, in decreasing authority:

1. The embedded CycloneDX SBOM (META-INF/sbom/application.cdx.json or META-INF/sbom/bom.json). Maven PURLs carry the groupId no manifest header carries. A component declared not shipped (scope: "excluded", or the cdx:maven:package:test=true property) is left out unless the archive census finds its JAR.
2. META-INF/maven/*/*/pom.properties descriptors on the classpath, including inside a repackaged archive's nested JARs.
3. java.class.path entries, read through the Maven repository layout or an adjacent POM. A group id is derived from a path only when a literal repository directory makes it unambiguous. Inside a repackaged fat JAR this source is dead.

Unreadable resources, a malformed SBOM, and unreadable archives are logged and skipped rather than failing the inventory.

The agent keeps, per jar, a bounded set of class-name hashes (8,192 per jar, 65,536 in all; past that, a class the advisory names reads as unknown, never as not loaded), for JDK types only, so no class loader is pinned. Dependencies are matched to jars as the Code Inventory panel matches them. Names come from the advisory's structured OSV fields, else from fully qualified class names in its summary and details, marked from the advisory text; text names are looked for only in the dependency's own jar, so their absence says nothing.

Two kinds of archive are never in an SBOM yet are not a coverage gap, so Spring MVC and WebFlux inspect an unidentified archive (manifest and entry names only) before reporting it:

• First-party module JARs. An archive with at least one class, all of them in the application's base packages, is counted in coverage.archivesFirstParty and named in coverage.firstPartyArchives (at most 200). It is not scanned. The check fails closed: a single class outside the base packages, a resource-only archive, META-INF/maven/ descriptors, a bundled .jar/.war/.zip, or no detectable base package keeps it unidentified. When the Spring Boot layers.idx defines an application layer, only archives in that layer can be first-party.
• spring-boot-jarmode-tools. Added by Spring Boot's build plugins at packaging time, so it is absent from the SBOM. When its file name, manifest title and version agree and every class is under org/springframework/boot/jarmode/tools/, it is identified as org.springframework.boot:spring-boot-jarmode-tools and scanned.

With both, a multi-module application built with an SBOM reports COMPLETE coverage.

The panel is identical and uses the same report contract and workflows. The one difference is dependency discovery: the inventory is captured at build time from the resolved runtime dependency model and needs no SBOM. Coverage is COMPLETE only when that model was captured and decoded whole; a missing or blank model, a malformed entry, or an unencodable coordinate reports UNAVAILABLE, keeping every readable dependency.