How to prioritize website security findings

Give the team a decision for each finding

A vulnerability report can mix dependency alerts, configuration concerns, and problems in application behavior. The next step is to determine what applies to your system and what action each finding needs. Treat an alert as a starting point for investigation, then connect it to the affected workflow and information.

This sequence helps application owners organize that work. Review and testing need authorization and an agreed scope. Keep detailed reproduction steps and sensitive evidence in an appropriate private channel.

1. Confirm what the finding affects

Record the application, deployed version, environment, and component named in the report. Check whether the reported behavior is present and which users or requests can reach it. For a dependency alert, identify the version in use and whether the relevant functionality is part of the application’s execution path.

Classify the outcome clearly: confirmed, needs more evidence, or not applicable with a reason. A finding that cannot yet be reproduced should retain its evidence and an investigation owner.

2. Combine severity with application context

Use the report’s severity as one input, then consider who can trigger the issue, what permissions are required, what data or actions are exposed, and how widely the affected feature is used. Record any existing controls and why they do or do not reduce the risk.

For example, an authorization problem that lets a signed-in user access another account’s records needs attention to the server-side permission checks. Hiding a link in the interface does not establish that the underlying request is restricted.

3. Plan a fix for the cause

4. Assign the work and its verification

Each confirmed finding needs an owner, a proposed change, a release path, and a way to demonstrate the result. Identify work that depends on another team or provider. If immediate remediation is not possible, document any temporary measure, its limits, and the outstanding fix.

OWASP’s Application Security Verification Standard provides requirements for web application security verification. It can help define checks appropriate to the application rather than treating one scanner’s output as the entire review.

5. Verify the original issue and nearby workflows

Retest the original reported behavior after the change. For a permission issue, check both authorized and unauthorized users, including relevant roles and record ownership. Confirm that legitimate users can still complete the task. After deployment, verify the relevant configuration or behavior in the intended environment.

Record which version and environment were checked, the result, and any remaining gaps. Keep regression checks for the underlying failure where practical, so future changes can be assessed against the same expectation.

What a remediation record should contain

• The affected application, version, environment, and workflow.
• Evidence, impact, and conditions required to trigger the issue.
• A priority decision with its application context.
• An implementation owner and the planned change.
• Retest results, release details, and unresolved follow-up work.

How KBD can help

KBD can investigate findings from another review, examine the relevant code and environment, implement agreed changes, and retest affected workflows. Our contribution to Health Product Shortages Canada included security improvements alongside reporting, administration, usability, and mobile work.

• Website security reviews & remediation ↗
• Health Product Shortages Canada case study ↗

Further reading

The OWASP Application Security Verification Standard provides a basis for selecting and documenting application security verification requirements.