Web security testing,
every week, not once a year.

• TLS protocol, certificate expiry and chain, and HTTP to HTTPS redirect
• Security headers and version banners that disclose server software
• Cookie flags: Secure, HttpOnly and SameSite
• Risky HTTP methods: TRACE, PUT, DELETE and CONNECT
• Exposed sensitive paths such as /.git/HEAD, /.env, cloud credentials, database backups and admin panels
• OWASP ZAP baseline and Nuclei through the SDK, run in your own environment
• Findings filed against the controls they affect, with a status you retest and close

No. Automated web security testing checks a running application for known misconfigurations from the outside, using requests that do not change anything. A penetration test is a person trying to break in: chaining flaws, testing business logic and authentication, and exploiting what they find. You need both, and an auditor will ask for the penetration test report separately.

We say which parts of the OWASP Top 10 these checks cover and which they do not. The platform's own probes address cryptographic failures, security misconfiguration and some access-control and logging issues; injection, server-side request forgery and authentication flaws need ZAP, Nuclei or a human tester.

1. Add the apps you ownList the web applications and hosts to test. Scan only assets you own or are authorised to test; the platform does not verify ownership for you, so keep a record of that authorisation.
2. Outside-in checks run from the platformThe platform sends only HEAD, GET and OPTIONS requests and performs a TLS handshake. It reads the certificate, security headers, version banners, cookie flags and which HTTP methods are allowed, and requests six well-known sensitive paths to see whether they are exposed.
3. Active scanning runs in your environmentFor deeper testing, trytrustable dast runs the OWASP ZAP baseline scan and Nuclei from your own environment, if they are installed, and sends the results. Attack-shaped traffic never comes from our infrastructure.
4. Pentest findings come in through the APIFindings from your penetration test provider can be posted as JSON, so they sit beside the automated results with the same status and controls.
5. A person retests and closesEach finding has a status. A re-scan replaces open automated findings with what it finds now, and a person sets a finding to retested and fixed once they have confirmed the fix.

Active scanning such as ZAP and Nuclei sends attack-shaped traffic, which you only want against targets you own and from a network you control. So the SDK runs those tools inside your environment and sends the results; the platform's own outside-in checks use only read requests and a TLS handshake.

Test a web application automatically at least weekly and after every significant release, and have it penetration tested by a qualified tester at least once a year and after major changes. The annual test finds the deep flaws; the frequent checks catch the regressions that appear in the eleven months between tests.

Most real exposures are not clever. A certificate expires on a Sunday, a deploy ships a .env file, a new subdomain goes live without security headers. These are found by the first automated scanner an attacker points at you, which is why your own scan should find them first.

Frequent checks also give you the trend an auditor or a customer's security team asks about: not "were you secure on the day of the pentest?" but "how quickly do you notice and fix problems?"

DAST (dynamic application security testing) is an automated tool sending requests to a running application and looking for known weakness patterns in the responses. A penetration test is a person working out how to break in: chaining small flaws, abusing business logic, testing authorisation between users, and proving impact. DAST is broad and repeatable; a penetration test is deep and creative.

OWASP ZAP and Nuclei, which the SDK can run for you, are DAST tools. ZAP's baseline scan passively checks responses for common issues; Nuclei runs templates for known vulnerabilities and misconfigurations. Neither will find that one customer can read another's invoices by changing an ID, which is exactly what a human tester looks for.

Use both. Let automation carry the repetitive checks so the penetration test budget goes on the exploratory testing only a person can do.

Customers and auditors expect a penetration test report from the last twelve months, evidence that the findings were fixed and retested, and evidence of ongoing vulnerability detection between tests. SOC 2 CC4.1 and CC7.1 and ISO 27001 A.8.8 and A.8.29 are where these usually land.

Bring the findings together. When pentest findings, automated web checks and dependency findings sit in one place with one status model, the question "is the critical from March fixed?" has an answer with a date, and the retest is recorded against the finding rather than in an email.

In India, keep CERT-In in mind: exploitation of a vulnerability in an internet-facing application can be a reportable incident under the CERT-In Directions, with a six-hour clock. A known, unfixed finding is hard to explain after the fact.

• The latest penetration test report, its date, scope and the tester's qualifications
• Evidence that each pentest finding was fixed and retested
• Evidence of vulnerability detection between penetration tests
• TLS configuration and certificate management for internet-facing systems
• How new applications and subdomains are added to the testing scope
• How testing is authorised, so scanning is never pointed at someone else's system

• It is not a penetration test and does not replace one
• The platform's own checks do not test injection, SSRF, authentication or authorisation flaws
• It does not run ZAP or Nuclei from our infrastructure; they run in your environment, if installed
• It imports pentest findings as JSON only; Burp and Nessus file imports are not supported
• It does not mark a finding fixed on its own; a person sets the retest status

Every result here is a control result on the same graph as the rest of the platform, so it reaches each framework that asks for it without being gathered again. Coverage lists the regimes.

Related reading: attack surface monitoring, attack paths and vulnerability management.