Vulnerability Management & Penetration Testing

New vulnerabilities appear all the time — in our code, our dependencies, and our configuration. Security is not a state you reach once. It is a process of finding weaknesses and fixing them before someone exploits them. That means scanning automatically, testing like an attacker, patching to a schedule, and giving outsiders a safe way to tell us what they have found.

Vulnerability management means knowing your weaknesses and closing them on a timeline that matches their risk. It covers automated scanning (in the pipeline and in production), regular penetration testing by people who attack the system the way a real attacker would, prompt patching, and a clear channel for responsible disclosure. It works alongside Threat Modelling (finding flaws in design) and Dependency & Supply-Chain Security (flaws in what we import).

For a regulated platform seeking certification, this is not optional. Independent penetration testing and a managed vulnerability process are explicit requirements (see Marketplace & Certification Readiness). The Finperiti audit, with its unauthenticated endpoint and forgeable webhooks, is the kind of finding that a regular pen test and continuous scanning surface long before an attacker does.

Find weaknesses continuously

• AlwaysRun automated security scanning in the pipeline — SAST, dependency/vulnerability scanning, secret scanning, and IaC/config checks — and fail the build on serious findings (see CI/CD & Deployment).
• DoScan running systems too — container images, deployed infrastructure, and exposed surface — not just source code at build time.
• DoOrder independent penetration tests on a regular schedule and after significant changes, and add the findings to the backlog as tracked work.
• ConsiderA bug-bounty or coordinated vulnerability disclosure programme as the system matures, to get more people looking at it.
• ConsiderTracking your own findings the way you would want a regulator to see them: severity, owner, due date, and status.

Fix on a clock, and let people tell you

• DoTriage and fix vulnerabilities to time-bound SLAs by severity — critical issues in days, not someday — and check that the fix actually closes the issue.
• DoPatch promptly and regularly. Most exploited vulnerabilities had a fix available that simply was not applied (see Dependency & Supply-Chain Security).
• DoPublish a security contact and responsible-disclosure policy, so researchers and customers have a safe, known way to report issues to us.
• DoTreat a credible report of an exploited or exposed vulnerability as an incident (see Incident Readiness), including any duty to notify of a breach.
• AvoidAccepting the risk of a serious vulnerability forever. If you cannot fix it now, record the decision, the compensating control, and a firm review date. Do not let it drift silently.
• NeverKnowingly ship or leave a known serious vulnerability in production without a documented, time-bound remediation plan and an owner.

Self-review checklist

• AskIf a critical vulnerability in our code or a dependency were disclosed today, would automated scanning catch it, and how fast would we fix it?
• AskWhen was this surface last penetration-tested, and were the findings actually closed?
• AskIs there a known, safe way for an outsider to report a vulnerability to us?
• AskAre any open serious findings drifting along without an owner and a due date?