Web Vulnerabilities 101 (Part 4 — Final): From Knowing the Flaws to Running a Secure System

The first three parts were a catalogue: data mistaken for commands, broken authorization and configuration, insecure design and business logic. But knowing the name of an illness makes nobody healthier. The difference between two teams reading the same OWASP material is that one of them turned those principles into steps that repeat every sprint, while the other still treats security as a box to tick before go-live.

This final part is about process: where security belongs in the development lifecycle, which tools to run and at which step, who owns what, how fast you promise to patch, and what to do on the day an incident actually happens.

1. Security is a layer along the lifecycle, not a phase

The easiest way to make it stick is to attach each activity to a step you already have, rather than inventing a new process. During refinement, ask which data the feature touches and who is allowed to do what. During design, spend an hour threat modelling the sensitive flows. While coding, lean on proven libraries instead of home-made ones, and add a few security lines to the review checklist. At merge time, let machines do the repetitive scanning. Before release, verify configuration and secrets. After production, monitor and be ready to respond.

"Shift left" is good advice that is easily misread as "do it all up front and then stop". The other half is shift right: most serious vulnerabilities are discovered while the system is running, through logs, alerts, users, or a polite researcher sending you an email.

2. The toolbox: each scanner sees only part of the truth

Do not expect one tool to cover everything. Static analysis is good at spotting dangerous patterns such as concatenated queries, but it is noisy and prone to false positives. Dependency scanning is the first thing worth enabling, because it is cheap and catches the supply chain risk described in part two. Dynamic scanning attacks the running application and finds configuration issues and problems that only appear at runtime. Secret scanning keeps API keys out of the repository and must cover commit history, not just new changes. Infrastructure-as-code scanning catches a public bucket or a wide-open security group before it ever exists.

Designing gates that survive contact with a deadline

A gate that blocks everything gets disabled within two weeks. A more durable rule is to block merges only on critical and high findings that have a fix available, and to route the rest into a tracked backlog with an owner and a due date. Invest in tuning down false positives during the first month, because a long queue of wrong alerts teaches the whole team to ignore alerts. Most importantly, results must appear inside the pull request where developers already are, not in a dashboard someone opens once a quarter.

3. What QA can do without being a security specialist

Quite a lot. Next to the happy path, add abuse cases: log in with a low-privilege account and call a high-privilege API directly; change an identifier in the URL to someone else's record; send missing fields, extra fields and wrong types; put very long strings and odd characters into every input; click submit several times in rapid succession; navigate backwards through a multi-step flow; and inspect the raw API response instead of trusting the screen. Read the logs afterwards to confirm the system is not writing out passwords, tokens or personal data. None of this requires a certification — only the habit of asking what you would try on this screen if you were not a nice person.

4. Pentests, a disclosure channel, and bug bounty

A penetration test pays off once the basics are in place; otherwise you are paying an expert to find what a free scanner would have found. Good preparation means a clear scope, accounts covering every role, API documentation and an environment that resembles production. When the report arrives, fix the root cause rather than the exact path demonstrated, check how many other places share the same flaw, and then ask for a retest.

In parallel, publish a way for outsiders to report problems to you: an email address or a security.txt file on your domain, together with a promise to respond and not to pursue good-faith researchers. Plenty of organisations lose months simply because the person who found the flaw had nobody to send it to. A bug bounty is the next step, appropriate once your team can handle a steady flow of reports.

5. Vulnerability management: prioritise with data, patch to a promise

The list of findings will always be longer than the team's capacity, so the real question is what to fix first. A CVSS score describes theoretical severity, but it needs two companions: how likely the flaw is to be exploited in the wild, and how exposed your particular system is. A high-scoring issue inside a library used only by an internal tool matters less than a medium-scoring issue in an Internet-facing service with public exploit code.

Set explicit remediation deadlines per severity and wire them into the process rather than into goodwill: critical within days, high within weeks, medium on the next release train. To make those promises realistic, automate dependency updates into small, frequent pull requests, keep a test suite trustworthy enough that you dare to bump versions, and maintain an asset inventory with an SBOM so that when the next big vulnerability lands you can answer within the hour whether you use that library and where.

6. Monitoring and incident response

No team avoids incidents forever; what differs is whether you find out in five minutes or five months. The signals worth alerting on are mundane: a spike in authorization denials from one account, a successful login from an unusual location right after a burst of failures, unusual traffic to an export endpoint, or infrastructure spend jumping at midnight.

Write a short runbook for the bad day, concrete enough for whoever is on call at three in the morning: who coordinates, how to isolate the affected system or account, how to collect and preserve evidence before restarting anything, how to revoke every key and token that might be exposed, the criteria for declaring recovery, and who is responsible for notifying customers and regulators. That last point is not merely courteous: data protection law in many jurisdictions, Vietnam included, imposes specific reporting duties and deadlines, so clarify them with legal in advance instead of looking them up mid-fire.

Afterwards, run a blameless review. The goal is to find where the system and the process allowed the mistake, then turn every lesson into something concrete: a new test, a new alert, a safer default.

7. People and measurement

Nobody does security well under duress. The model that works in most companies is a security champion per team — usually an engineer who finds it interesting — who reminds people to threat model, triages scan results and connects with whoever owns security overall. Pair that with short, regular sessions based on real bugs from your own product; it beats a four-hour annual training by a wide margin.

Measure a handful of things that reflect real capability: mean time from discovery to fix, the share of sensitive endpoints covered by automated authorization tests, the number of secrets found in repositories per month, the share of services with an up-to-date SBOM, and the time from the start of an incident to the moment a human noticed. Those numbers can be improved; a raw count of alerts tells you nothing.

8. Small team, small budget: what to do first

• Enable multi-factor authentication on every admin, infrastructure and source control account.
• Move secrets out of the repository and configuration files into a secret manager.
• Turn on dependency and secret scanning in CI, blocking on critical findings.
• Review public access on cloud storage and on the admin interface.
• Write automated authorization tests for your most sensitive endpoints.
• Back up regularly and actually rehearse a restore at least once.
• Centralise logs and define three to five meaningful alerts with someone on call.
• Publish a channel for outsiders to report vulnerabilities.

The series in four sentences

Part one: keep data separate from commands. Part two: privileges and configuration are decided on the server, with deny-by-default as the rule. Part three: the most expensive flaws are created in the design meeting, not in the editor. Part four: none of it counts until it becomes repeatable, measurable and owned.

No system is perfectly secure, and that was never the goal. The goal is to make attacking cost more than the reward, and to make your team detect and contain an incident faster than the damage spreads. That is a habit repeated every sprint, not a certificate on the wall.

References

• OWASP Top 10:2025 — owasp.org/Top10/2025
• OWASP Application Security Verification Standard — owasp.org/www-project-application-security-verification-standard
• OWASP SAMM — owaspsamm.org
• NIST SP 800-61 Computer Security Incident Handling Guide — csrc.nist.gov
• FIRST EPSS — first.org/epss