What is a vulnerability scanner, and what can it detect?

What does a vulnerability scanner actually do?

A vulnerability scanner compares the evidence it can collect with rules, known advisories or other indicators of security weaknesses.

The input determines the result. A package version can match an advisory; a code pattern can suggest unsafe handling of input; a public response can reveal a missing browser protection. None of those observations alone tells you every way an attacker could affect your business.

OWASP's overview of web vulnerability scanners describes automated checks of running web applications. Some tools send attack payloads or support authenticated testing. Those capabilities vary by product; they should not be assumed from the word “scanner.”

How do code, dependency and website scans differ?

They inspect different evidence and answer different questions, so choose the input that matches what you need to investigate.

• Static application security testing (SAST) reads code without running the application. It can flag supported risky patterns, such as untrusted input used to build a SQL query. Read how SAST tools work.
• Software composition analysis (SCA) checks third-party components and versions against known vulnerability information. An advisory match needs review for the affected version, usage and available fix; it is not proof of a reachable exploit.
• Live website checks observe a deployed site's public responses and assets. SetRepo checks HTTPS, response headers and served JavaScript, with additional exposed-file and public-data checks gated on domain verification. Use the SetRepo website vulnerability scanner for the URL workflow and exact boundaries.

For example, a code scan may find a private credential in a server file that is never served to browsers. A URL scan may find an old credential in a deployed bundle even after the current repository has been fixed. Looking at both helps distinguish source state from deployment state.

Where does SetRepo fit among vulnerability scanners?

SetRepo combines source-code checks with optional live-site checks, rather than scanning every kind of system or network asset.

Quick code scans use deterministic checks for secrets, supported vulnerable dependencies, risky code patterns and configuration. Source analysis includes route-level access-control checks where the route inventory supports the framework. Paid Deep scans add AI review of selected source for object-level access and business logic; they do not execute the app.

Provide a GitHub repository or ZIP archive for code checks. Provide a deployed URL for public-site observations. A URL alone does not supply private server handlers, lockfiles or database policy files. The GitHub scanning guide explains setup and scan choices.

How should I interpret a finding or a clean report?

Treat a finding as evidence to verify and a clean report as a statement about the completed checks within their scope.

1. Confirm the scanned commit or deployment is the one you intended to review.
2. Read the affected file, line, response or asset and understand the reported condition.
3. Separate likely impact from confidence. A high-impact issue still needs confirmation; a missing header does not establish data theft.
4. Prioritize confirmed credential leaks and unintended private-data access. Rotate leaked credentials and verify the permissions affected by the fix.
5. Review skipped checks and unsupported areas, fix confirmed issues, and rescan the changed source or deployment.

If a dependency check did not run, the absence of dependency findings says nothing about vulnerable packages. If a route requires login, that alone does not establish that it checks ownership of a requested record. The IDOR explanation shows why these are different questions.

How is scanning different from a full penetration test?

A penetration test is a scoped assessment that can use human investigation and controlled exploitation to validate and combine weaknesses; an automated scan runs predefined checks against the evidence it receives.

A tester may work through password recovery, use accounts with different roles, or combine a weak permission check with another flaw. Agree on authorization, scope and allowed actions before such testing. The OWASP Web Security Testing Guide provides a reference for planning a broader web assessment.

SetRepo does not sign in, exercise workflows as different users or demonstrate an exploit. It does not provide malware detection or certify a system as secure. Static analysis can miss unsupported patterns, and AI review can misunderstand intent. See SetRepo's coverage and limitations when deciding which manual checks remain.

Which scan should I start with?

Start with the evidence you have, then add the checks needed for your application's sensitive actions and data.

For a deployed site without source access, check common website security issues. For code you maintain, choose a repository scan. Combine the results with manual authorization checks, and arrange a penetration test when your risk and review requirements call for one.