Service

Heeler’s Service View gives you a unified lens into how a service is built, deployed, and secured across your environment. Each view connects code, infrastructure, and runtime behavior to deliver deep visibility and actionable insights—helping you manage risk, drive secure development, and accelerate remediation.

You can explore each Service through five views:

Model Understand how the Service is structured and connected to other services in your application ecosystem.

Deployments View each deployment of the service across environments and regions linked back to changeset the deployment is running.

Infrastructure View the underlying infrastructure—such as compute, networking, and storage—that supports the Service in runtime.

Code Analyze the Service's code-level composition at each deployment, including dependencies, API endpoints, and connections to other services.

Security Get a contextual analysis of the Service’s security posture, including vulnerability reachability, exploitability, and fixability across different deployments.

Model

The Model view presents a graph-based representation of your service. It visualizes:

• Cloud resources that compose the service

• Service to Service connections with directionality

• Data flows between resources

• Identity relationships between resources

• Internet accessibility including CDNs

• Workload boundaries and configuration sources

This model helps teams quickly understand how the service operates in context—crucial for both architecture and threat modeling tasks.

Deployments

A Deployment is a running instance of a service in a specific environment (e.g., dev, staging, production). Each deployment is independently analyzed to show:

• Linked changeset and version

• Environment boundary

• Security posture

• Internet accessibility

• Runtime SBOM (CycloneDX format)

This allows teams to isolate issues by environment, verify safe promotion between stages, and detect security drift across deployments

Infrastructure

The Infrastructure view inventories the cloud resources powering the service, grouped by type (e.g., compute, identity, storage). For each resource, you can access:

• Properties and relationships

• Attachments to other infrastructure

• Configuration warnings or annotations (e.g., misconfigurations, compliance risks)

• Raw resource JSON

This enables infrastructure and security teams to validate service posture, investigate exposure paths, and surface misconfigurations that could lead to compromise.

Code

The Code view reveals how the service is constructed and interacts with its environment. It includes:

• Dependencies

• Endpoints

• Connections

This view bridges the gap between static code and runtime behavior, helping security and engineering teams prioritize what matters.

Dependencies

Dependencies lists the individual Service dependencies with aggregated information including Findings (Urgent/Plan/Defer), whether the dependency is visible during runtime, the number of affected deployments, and when it was first seen.

Endpoints

Endpoints lists the path and method of individual Service endpoints with additional information like endpoint file location, link to its location in the repository, the number of affected deployments, and when it was first seen.

Connections

Connections maps the service to service connections, providing the ability to inspect related services. Connected services are determined through a combination of code and cloud analysis that utilizes networking configuration and identity permissions.

Security

Under Security, there are different views available:

• Dependency Remediations

• Active Findings

• Fixed Findings

• Deployed Findings

• Source Findings

Dependency Remediations

If there are known Dependency Remediations, they are listed here in table format. The Dependency Remediations can be sorted by Fixability, SLO, Priority, Assignee, etc.

Dependency Remediation (individual)

For each Remediation, there are details such as a listing of related vulnerabilities, affected deployments, and other details. As in the Dependency Remediations listing, there is also a Push to Jira capability that creates a Jira ticket populated with remediation details, ownership, and SLO information.

In addition, there is a View Upgrade Guidance feature, so you can see the proposed solution, which is also the upgrade guidance pushed to Jira.

Based on analysis, the upgrade from org.springframework:spring-webmvc 5.3.23 to 6.2.10 is a major breaking change that will significantly impact the application and requires substantial code modifications.

Critical Breaking Changes:

1. Java Version Requirement

• Breaking: Minimum Java version increased from Java 8 to Java 17

• All code must be compiled and run on Java 17 or higher

2. Jakarta EE Migration

• Breaking: Complete migration from Java EE to Jakarta EE

• All javax.* imports must be changed to jakarta.*:

  • javax.servlet.* → jakarta.servlet.*

  • javax.validation.* → jakarta.validation.*

  • javax.persistence.* → jakarta.persistence.*

  • And all other javax packages

3. Spring Framework 6.x Architecture Changes

• Breaking: Native compilation support may affect reflection-heavy code

• Breaking: Some internal APIs have been removed or restructured

• Breaking: Enhanced type safety may cause compilation issues with generic types

4. Web MVC Specific Changes

• Breaking: Some controller method signatures may need adjustment

• Breaking: Path matching behavior changes in certain edge cases

• Breaking: Default content negotiation strategy updates

• Deprecation: Some legacy @RequestMapping patterns deprecated

5. Dependency Management

• Breaking: Requires compatible versions of all Spring modules (Security, Data, etc.)

• Breaking: Third-party libraries must support Jakarta EE

• Breaking: Application servers must support Jakarta EE 9+

6. Configuration Changes

• Breaking: Some configuration properties renamed or removed

• Breaking: Bean definition changes for certain auto-configurations

Required Actions:

1. Upgrade to Java 17+

2. Replace all javax.* imports with jakarta.*

3. Update all dependent Spring modules to 6.x versions

4. Update application server to Jakarta EE compatible version

5. Review and test all custom configurations

6. Update third-party dependencies to Jakarta EE compatible versions

This upgrade requires significant planning and testing due to the fundamental platform changes.

Active Findings

Findings includes application findings (e.g., API endpoints) and security findings (e.g., OSS vulnerabilities). They are linked directly to service deployments, enabling precise tracking of changes within each Service. Tracking findings at both the deployment and changeset levels allows for accurate identification of where security issues are detected or need remediation. For instance, Heeler can clarify whether an active Finding is due to a new API created in a development deployment or if an urgent vulnerability is discovered within a production service.

Finding (individual)

For each Finding, if there is a known Remediation, it is called out along with its impact information. I.e., how many Findings can be remediated by implementing and deploying the provided Remediation.

There are also details related to:

• Priority: How important is it to remediate the Finding based upon business and technical factors?

• Lifecycle: What is the remediation status of the Finding, if any?

• Evidence: Resource and information model representing whether the Finding is reachable

• Additional details: Information related to the Finding, external references, etc.

In addition, there are Deployment details for each Finding that include links to code changesets and deployment status.

Fixed Findings

If there are Fixed Findings, they are listed here in table format with details on discovery date, remediation date, and adherence to SLO.

Deployed Findings

If there are Deployed Findings, they are listed here in table format with details on when the Finding was introduced, when it was fixed, and when it was rolled out.

Source Findings

Source Findings includes the results from Static Application Security Testing and Software Composition Analysis of your Service's code with details on the Finding source, severity, and number of instances of the Finding.

For each Finding, there is a drill down available to the actual files and file line numbers where the Finding is located with a link to go to the location in your code repository.

Assignment & Generate SBOM

At the top of the screen, there are two other features: Assignment & Generate SBOM.

Assignment provides useful information about points of contact for the service, where work is performed/tracked and by whom, and the location of relevant collaboration.

The Generate SBOM button downloads a Software Bill of Materials (SBOM) in JSON format. E.g.,