Turn a client review into a clear change list.

Start with a defined scope

A new client may have Dockerfiles, Kubernetes manifests, Terraform modules, and years of undocumented decisions. Start by agreeing which repositories, branches, and environments are in scope. Record an owner for the review and the deployment assumptions that a static scanner cannot know.

Connect an approved repository or upload selected configuration files. Keep each client’s access and review records within the appropriate organization, and check repository permissions before connecting. The security and data handling overview explains what the hosted workflow processes.

Use the same first pass across projects

Sentinel’s deterministic checks identify configuration findings with severity and file or resource context. That gives an engineer a consistent starting point for triage across supported stacks. Open a finding, inspect the affected configuration, and decide whether it represents a real risk in that client’s environment.

Prioritize by exposure, business impact, and the cost of a safe change. A high-severity finding in a public service may need a different response from the same pattern in an isolated test fixture. Treat the score as a summary of the analyzed configuration, alongside the underlying findings and scan scope.

• Confirm which environment and workload each finding affects.
• Separate changes that are ready to review from decisions that need a client owner.
• Capture accepted exceptions and their rationale in the client’s existing review process.

Make the handover a reviewable change

For supported findings, Sentinel can generate a remediation preview and create a pull request through the connected repository. Use the preview to check the exact diff and its assumptions. Findings without a supported patch still provide context for an engineer to make the change.

Keep a pull request focused enough for the client to review. Describe the finding, the intended behavior, and how the change was validated. Run the project’s tests and deployment checks before merge, then scan the updated configuration to verify the result. Optional AI explanations can help develop the discussion; the engineer owns the final recommendation.

Agree what “review complete” means

A useful delivery includes the repositories and revision reviewed, the findings you confirmed, links to proposed changes, and any remaining decisions. Scan history can support follow-up reviews, but comparing scores alone can hide changes in file coverage or workload scope.

Configuration analysis is one part of an engagement. Runtime access reviews, dependency and image vulnerability scans, recovery exercises, and penetration tests answer different questions. Define those deliverables with the client separately.

Start with one representative repository and evaluate the findings with the engineer who will own remediation. Compare available plans and limits, or contact Sentinel to discuss your organization’s requirements before expanding the workflow.

Build your review checklist

Use these practical guides to connect a finding to an engineering decision:

• Review Kubernetes workload permissions, resources, and probes.
• Review Dockerfile build inputs, secrets, and runtime behavior.
• Review Terraform change scope, state, and network exposure.