Begin with threats to this product
A list of common vulnerabilities is useful, but it does not say which risks matter most to a particular application. First map assets, users, important data flows and trust boundaries. Who signs in, who changes financial details, where do files arrive and how does an outside service behave? For each step consider misuse, accidental error and disclosure. The result is a short threat model that can set priorities for tests and safeguards.
The NIST Secure Software Development Framework recommends integrating security practices into ordinary development. A small team need not create a heavy new process. It needs an owner for risk, change review rules and a path from finding to repair. Update the threat model when a new permission, integration or data class appears. An unchanged checklist can create false confidence if the product has meanwhile moved its actual trust boundaries.
Identity and permission have business meaning
Authentication checks who a person is; authorisation decides what they may do. Many real mistakes occur in the second part. A user may legitimately enter a portal but must not see another organisation's order or give themselves a new role. Write a role matrix against actual operations and data. Every server request must enforce the rule, even when the interface hides the button. Visibility of a control is not a security boundary.
Administrative accounts need appropriate sign-in strength, limits on repeated attempts and a way to revoke sessions. Service accounts should hold narrow permissions and have a credential rotation path. When an employee changes role, access should end in caches, exports and other systems too. During design, ask how the organisation handles lost devices, departure and emergency access. The answers shape implementation more than the choice of a login library.
Turn requirements into testable controls
The statement “the application must be secure” cannot be verified. “A normal user cannot read another organisation's record” can be tested. OWASP ASVS supplies a structured catalogue of web application controls that can be selected by risk. Choose relevant areas such as sessions, input handling, access to data and configuration. Attach each chosen control to a concrete test, an owner and a result. This is more useful than claiming blanket compliance with a standard without evidence.
An automated scanner finds some known issues but may miss broken business rules. Add manual review of risky changes and tests across role boundaries. For an API, check duplicate requests, signatures and error behaviour. For uploads, check type, size and safe processing. Record what was tested and what was not. A control with an explicit limitation is more honest and actionable than a green label that hides missing scenarios.
Security tests belong in delivery
During development, automate checks for types, dependencies and common risky code patterns where they help. These tools also produce false alarms and never cover the complete application. Triage findings by impact and whether the vulnerable path is reachable. A critical authorisation mistake deserves more attention than a low-scoring library that is not executed in production. A finding needs a clear closure rule: repaired, mitigated with evidence or accepted by the right owner.
Before an important launch, test the scenarios in the threat model, including attempts to cross roles, upload unexpected files and exploit failure states. If an independent penetration test is required, define its scope, permission and supplier; do not describe internal review as an external audit. After a fix, repeat the original abuse scenario and verify that the legitimate user journey still works. A defence that breaks essential work needs a better design.
Code and dependencies have provenance
A product uses libraries, build tools, images and automated pipelines. Their origin and versions affect the delivered software. Lock dependencies, restrict CI permissions and separate secrets from ordinary jobs. Record which commit and configuration produced an artifact. SLSA describes incremental guarantees for software supply chains. A small team may not need the highest level, but it should know what it can actually prove about its build's origin.
When updating, consider more than the count of reported vulnerabilities. Ask whether the dependency runs in production, whether a fix exists and how safely it can be deployed. An old unsupported package may be a larger concern than a temporarily inconvenient upgrade. Record exceptions with a review date. The build environment itself needs access review, because a compromised release process can bypass safeguards in the application.
Logging can help and can cause harm
Event records help investigate unauthorised changes and operational faults. Select events that answer who acted, what happened, when and with what result. Role changes, administrator actions and repeated failed sign-ins are examples. Records should be structured and resist an untrusted input that inserts a fake line. Each log source needs an appropriate retention period and restricted access. An enormous stream of unreviewed data does not improve security.
OWASP advises against routinely recording passwords, session tokens, keys, sensitive personal information and full payment instructions. A correlation identifier and error type can support investigation without turning the log into another exposure. Check analytics, error reporting and log backups too. Removing a sensitive field from the main log is ineffective if another tool automatically copies it into an external service.
Plan response to findings and incidents
No test guarantees that a problem will never appear after launch. Establish a way to report a vulnerability, a response owner, an impact assessment and a repair plan. During an incident, distinguish containment, preservation of necessary evidence, service recovery and communication. The process should fit the data and contractual responsibilities involved. Legal notification obligations depend on the actual event and jurisdiction and need specific review.
After repair, ask why the issue passed through development: was a test missing, a role unclear or an integration changed without updating the threat model? Add a control where it will bring repeatable value. For a small application that might be one integration test and a better alert. A critical service may need an architectural change. The goal is the ability to learn and reduce risk, not the number of documents produced after an incident.
Define the security engagement
An initial brief should include the product type, data classes, user roles, outside integrations, environments and planned launch. Include previous tests, repository access and operating constraints. Then decide whether the first step should be a threat model, architecture review, secure development controls or independent assessment. These options produce different deliverables and should not be confused with one another.
This page explains an approach to safer software. It does not claim unverified EXCOIN certifications, audit authority or zero risk. If a formal audit or legal assessment is required, name a qualified provider and a clear scope. Engineers can prepare the evidence inventory and repair confirmed defects. Progress means risks have names, controls have owners and the important abuse scenarios have actually been tested.