Service

Overview

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.

There is also a Generate SBOM button that downloads a Software Bill of Materials (SBOM) in JSON format. E.g.,

Code 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.

Code 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.

Code 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:

  • Findings

  • Remediations

  • Remediated Findings

  • Code Findings

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 application. 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 track if a new API is created in a development deployment or if an urgent vulnerability is discovered within a production service.

Finding

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.

Remediations

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

Remediation

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

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

//# Upgrading Tomcat Embed Core from 9.0.68 to 9.0.106

This is primarily a maintenance upgrade within the same major version (9.0.x), so there are minimal breaking changes. Here are the key points to consider:

## Breaking Changes

1. **HTTP/2 Support Changes**: 
   - Several HTTP/2 related parameters were changed in 9.0.71
   - If you're using HTTP/2, review configuration settings related to maxConcurrentStreams, initialWindowSize, and maxHeaderSize

2. **CORS Filter Changes**:
   - In 9.0.84, CORS filter behavior was updated to match the specification more closely
   - The filter might be more strict about CORS requirements

3. **BIO Connector Removal**:
   - The legacy BIO connector was completely removed in 9.0.83
   - If you were still using it, you'll need to migrate to NIO or APR/native connectors

## Deprecations

1. **WebSocket Session maxIdleTimeout**:
   - The setter/getter methods for maxIdleTimeout were deprecated in favor of new naming
   - Use getMaxIdleTimeout/setMaxIdleTimeout instead of getIdleTimeout/setIdleTimeout

2. **JspFactory methods**:
   - Several methods in JspFactory were deprecated

3. **Certain I/O APIs**:
   - Some lower-level I/O APIs were deprecated in favor of newer alternatives

## Security Updates

- This upgrade includes numerous security fixes (dozens of CVEs addressed)
- Notably includes fixes for HTTP Request Smuggling vulnerabilities

Since this is an upgrade within the same major version, the changes are generally incremental rather than fundamental. Most applications should upgrade without issues if they're using standard APIs.

Remediated Findings

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

Code Findings

Code 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.

PreviousCatalogNextCode Repository

Last updated

Was this helpful?