If you need to address known code or configuration risks, you may need hardening with specified retesting. If you need to understand how sensitive controls are implemented, you may need focused code review. If you need organized adversarial testing of defenses, that is specialist work requiring appropriate capability and separate authorization. Grouping everything under “comprehensive security check” makes proposals difficult to compare and results difficult to accept.
This article concerns preventive procurement, not emergency response to an active compromise. Where an incident is suspected, the system owner should establish an appropriate response route with a qualified specialist rather than making arbitrary changes that could confuse evidence. LAB's published hardening scope should not be interpreted as an unverified penetration-testing or incident-response capability.
Compare the work, not the marketing label
A project may combine several activities, but it should distinguish what will be examined, what will be changed and what evidence will be produced. An automated scanner's output is not automatically a code review. Applying an update does not establish that every application path is secure. Ask for the included asset, version, examination method and verifiable outcome.
| Activity | Question it addresses | Boundary to disclose |
|---|---|---|
| Hardening | Which agreed changes address prioritized risks? | Does not establish absence of other risks |
| Focused code review | How do selected code paths implement required controls? | Does not imply review of the entire repository or every version |
| Control verification | Do specified requirements hold in agreed cases? | Limited by requirements, environment and evidence |
| Specialist penetration test | How do authorized assets withstand organized adversarial testing? | Requires suitable specialists, authorization and separate rules of engagement |
Performance & Security Hardening can focus on code and configuration review, approved fixes and retesting. Do not add the term “penetration test” simply because the work concerns security.
Use a precise reference without implying certification
OWASP ASVS provides a basis for security-verification requirements and recommends including the version when referencing a requirement identifier. The benefit is a shared understanding of what was examined, not a security certificate generated by mentioning the standard. Official OWASP ASVS site.
Request requirements appropriate to the risks rather than an unexplained promise to “follow OWASP.” Each included requirement needs a result, evidence and limitations. Excluded or unverifiable items must remain visible. If a specialized regulatory or contractual assessment is needed, have its authorized owner and qualified specialist define it rather than assuming a remediation report satisfies it.
Hypothetical example: a portal serving several business customers
Imagine a portal that makes each customer's documents available to that customer's authorized employees. Before a release, the owner divides preventive work into three parts: review selected access settings and dependencies, inspect specified document-reading code paths, and verify that authorized test accounts cannot cross the agreed permission boundaries.
This is a fictional defensive scenario, not a description of a real vulnerability. The scope excludes adversarial testing of hosting infrastructure and employee devices. It uses synthetic documents and permitted test identities with separate test customers. If the problem lies in application logic, its repair belongs in App Development, rather than being treated as merely a password change.
After remediation, the team repeats the relevant verification cases and checks a legitimate reading journey so the fix does not block the correct user. The report states that specified paths in a particular version passed the defined cases. It does not describe the portal as breach-proof or imply coverage of components outside the authorization.
If the owner later requests an independent penetration test, appropriate specialist capability, scope and authorization must be confirmed before committing to that work.
Treat authorization as a design input
Specify permitted assets, environments, accounts and time windows, prohibited methods and third-party boundaries. Control of the website's domain does not grant permission over every connected payment, messaging or hosting service. Identify who can stop the work, how sensitive evidence is protected and what happens if information outside the scope appears.
Cloud Architecture Design & Review can clarify unknown account and dependency boundaries. Begin with read access where sufficient, and require specific approval for production changes. Do not use real customer data or accounts when authorized synthetic examples can answer the question safely.
Authorization also needs to remain current when scope changes. A newly discovered integration is not automatically included because it is reachable from the original target. Record the dependency and seek the correct permission rather than expanding the activity silently.
Connect remediation with verification
A useful finding identifies the affected element, possible impact, observed evidence, proposed treatment, decision owner and remediation status. Keep sensitive implementation detail in a restricted handover rather than a public document. Difficulty reproducing a finding is a reason to state uncertainty, not conceal it.
Software Quality Assurance can support agreed verification and regression cases, with appropriate security expertise where needed. An access-control repair should not block legitimate work; a dependency update may require testing affected functions. Acceptance of residual risk belongs to an authorized owner, not to an implementer adding a sentence to close a ticket.
What should handover include?
- The asset and version inventory, with approved exclusions.
- The activity type and versioned requirements reference where used.
- Understandable results, access-controlled evidence and explicit confidence.
- A record of implemented changes and their authorization, not recommendations alone.
- Retesting of fixes and related legitimate-function cases.
- Remaining risks, follow-up owners and a clear distinction between untested and tested areas.
The report should allow a buyer to answer two separate questions: what changed, and what evidence now supports that change? Neither a long list of tool outputs nor a clean summary page answers those questions on its own.
Frequently asked questions
Does automated scanning replace specialist review?
Do not assume so. It can support a defined scope, but the question and risk determine the need for suitable human analysis.
Does a report with no findings mean the application is secure?
It means the specified work found no reported issues within its limits. It does not prove absence of vulnerabilities or guarantee protection against incidents.
Does hardening include compliance certification?
Certification or accreditation cannot be inferred from remediation work or a standards reference. Any such requirement needs its own scope and qualified assessing party.
What should we prepare for a clear proposal?
Provide the application description, assets you can authorize, the decision required and redacted previous reports. Confirm specialist capability and permissions before sharing sensitive detail or beginning tests.
Reference
OWASP Application Security Verification Standard, reviewed 26 October 2026. This guide provides neither exploitation instructions nor security certification.
