One scan, one AWS account. Ten correlated diagnoses.

• Health score

  Summarizes the health signals found in the analysis to help set priorities, based on the available evidence.

• Score confidence

  Shows uncertainty, provisional information, and evidence gaps that affect how the health score should be interpreted.

• Technical inventory

  Summarizes the languages, runtimes, and codebase size identified in the repository.

• C4 container diagram

  Shows the main software units, their technologies, and their relationships. In C4, a container is an architectural unit, not necessarily a Docker container.

• Domain map

  Suggests domain contexts and boundaries from the code for review with people who understand the business.

• Dependency graph

  Reveals component relationships, cycles, and coupling that can increase the impact of a change.

• Integration map

  Identifies channels, endpoints, adapters, and gateways in the code and shows how components connect.

• Deployment and infrastructure view

  Maps services, data stores, and integrations from configuration and infrastructure as code. Without those files, it uses a component view; it does not inventory live cloud resources.

• Quality attributes

  Examines maintainability, security, and ease of change, including the risks and technical trade-offs found in the architecture.

• Remediation plan

  Organizes proposed actions into prioritized stages, considering effort, dependencies, and reversibility. It guides implementation; it does not apply the fixes.

SDD Kit. Can be generated as an additional step when included in your engagement, using the evidence and recommendations in this assessment.

• Health score

  Summarizes the health signals found in the analysis to help set priorities, based on the available evidence.

• Score confidence

  Shows uncertainty, provisional information, and evidence gaps that affect how the health score should be interpreted.

• Technical inventory

  Summarizes the languages, runtimes, and codebase size identified in the repository.

• Attack surface

  Maps entry and exit points, trust boundaries, and unsupported runtimes to guide threat analysis.

• Security findings

  Organizes security issues found by the analyses, including dependency risks, with evidence to support review and prioritization.

• Static security analysis

  Flags potentially unsafe code patterns and reports language coverage. Whether a finding can be exploited requires review.

• Severity map

  Shows how findings are distributed by severity to make security priorities easier to assess.

• API surface map

  Brings together HTTP routes, methods, resource groups, and versioning signals detected in the code.

• Integration map

  Identifies channels, endpoints, adapters, and gateways in the code and shows how components connect.

• Remediation plan

  Organizes proposed actions into prioritized stages, considering effort, dependencies, and reversibility. It guides implementation; it does not apply the fixes.

SDD Kit. Can be generated as an additional step when included in your engagement, using the evidence and recommendations in this assessment.

• Health score

  Summarizes the health signals found in the analysis to help set priorities, based on the available evidence.

• Score confidence

  Shows uncertainty, provisional information, and evidence gaps that affect how the health score should be interpreted.

• Technical inventory

  Summarizes the languages, runtimes, and codebase size identified in the repository.

• Data persistence map

  Identifies databases, storage systems, and ORMs, showing how data access is distributed across application layers.

• Database schema and migrations

  Reconstructs the schema from available files and flags destructive or hard-to-reverse migrations, within the supported parsers’ coverage.

• Table structure patterns

  Identifies table families split by number or date, structural similarities, and signs of inheritance or partitioning. It does not automatically generate or apply database changes.

• Indexes and data access

  Flags potentially missing or redundant indexes and access patterns that need review. Structural analysis does not measure actual query performance.

• Query risks

  Locates patterns such as queries inside loops, SELECT *, missing pagination, and SQL outside the intended layer, with code references.

• Sensitive data and lifecycle

  Identifies possible personal data categories from the schema and evidence of how they are handled. Inferences need validation; actual data values are not examined.

• Persistence security

  Reviews exposure and access control signals in code, schema, and infrastructure definitions, including raw SQL, permissions, and isolation.

• Continuity and recovery

  Checks declared backup, retention, encryption, and redundancy settings. Missing evidence is made explicit; this does not test restoration or recovery times.

• Tenant isolation

  Analyzes structural data separation and row-level policy coverage in multi-tenant tables. It does not, on its own, prove isolation throughout the running system.

• Regulatory requirements matrix

  Links technical issues to regulatory requirements and organizational questions to check. It supports specialist review; it is not legal advice or compliance certification.

• Remediation plan

  Organizes proposed actions into prioritized stages, considering effort, dependencies, and reversibility. It guides implementation; it does not apply the fixes.

SDD Kit. Can be generated as an additional step when included in your engagement, using the evidence and recommendations in this assessment.

• Health score

  Summarizes the health signals found in the analysis to help set priorities, based on the available evidence.

• Cloud security posture

  Checks the AWS account against CIS AWS Foundations Benchmark and AWS Security Hub FSBP controls — network, detection, secrets, and data — and summarizes compliance as N controls met out of M assessed.

• Cloud inventory, capacity and cost

  Lists the observed resources by service and region, with the capacity signal and estimated cost of the provisioned instances and a resize projection by instance class.

• Observed cloud topology

  Maps the real relations between snapshot resources and the exact correlations with repository identifiers, declaring what remained uncorrelated.

• Observability coverage

  Shows the coverage of metrics, alarms, logs, and tracing observed across resources, without carrying raw telemetry.

• Remediation plan

  Organizes proposed actions into prioritized stages, considering effort, dependencies, and reversibility. It guides implementation; it does not apply the fixes.

SDD Kit. Can be generated as an additional step when included in your engagement, using the evidence and recommendations in this assessment.

• Health score

  Summarizes the health signals found in the analysis to help set priorities, based on the available evidence.

• Score confidence

  Shows uncertainty, provisional information, and evidence gaps that affect how the health score should be interpreted.

• Technical inventory

  Summarizes the languages, runtimes, and codebase size identified in the repository.

• Technical debt hotspots

  Combines complexity with change frequency to highlight areas that need attention, when sufficient Git history is available.

• Health by dimension

  Breaks down the results by quality dimension to show what supports or weakens the system’s technical health.

• Dependency graph

  Reveals component relationships, cycles, and coupling that can increase the impact of a change.

• Refactoring boundaries

  Suggests where to isolate responsibilities and introduce tests to prepare legacy code for change.

• Remediation plan

  Organizes proposed actions into prioritized stages, considering effort, dependencies, and reversibility. It guides implementation; it does not apply the fixes.

SDD Kit. This assessment type does not support direct SDD Kit generation. To plan changes with a kit, explore the Evolvability assessment.

• Code clones and duplication

  Locates exact duplicates and repeated code across components, highlighting opportunities to consolidate implementations.

• Frequent changes in complex code

  Combines change volume, complexity, and authorship concentration to highlight unstable areas, when sufficient Git history is available.

• Suspicious dependencies

  Flags package names that resemble known dependencies for supply chain review. Similarity alone does not establish that a package is malicious.

• Secrets in source code

  Identifies signs of exposed credentials and keys, reporting their type and location without reproducing their values.

• Test structure and coverage

  Analyzes test structure, gaps, and test cases with no assertions. Actual line and branch coverage requires supplied coverage data, such as LCOV.

• Error handling

  Finds empty exception handlers and swallowed errors, relating them to the module’s context and the available change history.

• Inference efficiency

  Flags model calls that could request more concise responses for the team to review. This identifies optimization opportunities, without guaranteeing savings.

• Remediation plan

  Organizes proposed actions into prioritized stages, considering effort, dependencies, and reversibility. It guides implementation; it does not apply the fixes.

SDD Kit. Can be generated as an additional step when included in your engagement, using the evidence and recommendations in this assessment.

• Health score

  Summarizes the health signals found in the analysis to help set priorities, based on the available evidence.

• Score confidence

  Shows uncertainty, provisional information, and evidence gaps that affect how the health score should be interpreted.

• Technical inventory

  Summarizes the languages, runtimes, and codebase size identified in the repository.

• Architecture fitness checks

  Assesses technical guardrails and proposes executable checks for continuous integration, such as complexity limits, duplication, and circular dependencies.

• Delivery indicators

  Estimates release frequency and elapsed time from a change to its release, using commit and tag history. These are proxies for two metrics, not a complete DORA assessment.

• Health by dimension

  Breaks down the results by quality dimension to show what supports or weakens the system’s technical health.

• Technical debt hotspots

  Combines complexity with change frequency to highlight areas that need attention, when sufficient Git history is available.

• Dependency graph

  Reveals component relationships, cycles, and coupling that can increase the impact of a change.

• Remediation plan

  Organizes proposed actions into prioritized stages, considering effort, dependencies, and reversibility. It guides implementation; it does not apply the fixes.

SDD Kit. Can be generated as an additional step when included in your engagement, using the evidence and recommendations in this assessment.

• Health score

  Summarizes the health signals found in the analysis to help set priorities, based on the available evidence.

• Score confidence

  Shows uncertainty, provisional information, and evidence gaps that affect how the health score should be interpreted.

• Technical inventory

  Summarizes the languages, runtimes, and codebase size identified in the repository.

• Migration assessment

  Suggests refactoring, replatforming, retiring, or retaining components based on the code. Rehosting or buying replacement software requires further assessment.

• Refactoring boundaries

  Suggests where to isolate responsibilities and introduce tests to prepare legacy code for change.

• Dependency graph

  Reveals component relationships, cycles, and coupling that can increase the impact of a change.

• Integration map

  Identifies channels, endpoints, adapters, and gateways in the code and shows how components connect.

• Technical debt hotspots

  Combines complexity with change frequency to highlight areas that need attention, when sufficient Git history is available.

• Remediation plan

  Organizes proposed actions into prioritized stages, considering effort, dependencies, and reversibility. It guides implementation; it does not apply the fixes.

SDD Kit. Can be generated as an additional step when included in your engagement, using the evidence and recommendations in this assessment.

• Health score

  Summarizes the health signals found in the analysis to help set priorities, based on the available evidence.

• Score confidence

  Shows uncertainty, provisional information, and evidence gaps that affect how the health score should be interpreted.

• Technical inventory

  Summarizes the languages, runtimes, and codebase size identified in the repository.

• Domain map

  Suggests domain contexts and boundaries from the code for review with people who understand the business.

• Dependency graph

  Reveals component relationships, cycles, and coupling that can increase the impact of a change.

• Integration map

  Identifies channels, endpoints, adapters, and gateways in the code and shows how components connect.

• Resilience map

  Checks for timeouts, retries, circuit breakers, and failure handling in integrations identified in the code.

• API surface map

  Brings together HTTP routes, methods, resource groups, and versioning signals detected in the code.

• Remediation plan

  Organizes proposed actions into prioritized stages, considering effort, dependencies, and reversibility. It guides implementation; it does not apply the fixes.

SDD Kit. Can be generated as an additional step when included in your engagement, using the evidence and recommendations in this assessment.

• Health score

  Summarizes the health signals found in the analysis to help set priorities, based on the available evidence.

• Score confidence

  Shows uncertainty, provisional information, and evidence gaps that affect how the health score should be interpreted.

• Technical inventory

  Summarizes the languages, runtimes, and codebase size identified in the repository.

• Contribution concentration

  Identifies components whose contributions are concentrated among a few people, when Git history is available. This supports review; it does not measure the team’s knowledge.

• Teams and components

  Relates authorship patterns to component boundaries to reveal dependencies between contributor groups. It does not replace the actual organizational chart.

• Delivery indicators

  Estimates release frequency and elapsed time from a change to its release, using commit and tag history. These are proxies for two metrics, not a complete DORA assessment.

• Technical debt hotspots

  Combines complexity with change frequency to highlight areas that need attention, when sufficient Git history is available.

• Remediation plan

  Organizes proposed actions into prioritized stages, considering effort, dependencies, and reversibility. It guides implementation; it does not apply the fixes.

SDD Kit. This assessment type does not support direct SDD Kit generation. To plan changes with a kit, explore the Evolvability assessment.