Yes, but lighter. A VPN limits who can reach an app. It does not fix flaws inside it, and anyone with a stolen credential or a compromised laptop is already on the network. Run dependency scanning always, add dynamic or static checks based on the data the tool holds.
Why "internal" is a weak argument
Three things erode the wall.
- Credentials leak. A phished VPN login puts an attacker inside, where internal apps often have weaker authentication than public ones.
- Insiders exist. Employees and contractors can reach tools they should not read or change.
- Boundaries move. Today's internal tool becomes tomorrow's partner portal. If testing never happened, the first exposure is also the first test.
Internal does lower the odds of opportunistic attack. So the answer is a smaller baseline, not none.
A lightweight baseline
| What the tool holds | Baseline |
|---|---|
| Little sensitive data, small user group | Dependency scanning, lockfiles committed, patch on a schedule |
| Employee or customer records | Add static analysis on pull requests and an authenticated dynamic scan in a test environment |
| Admin functions, credentials, production access | Add manual review of access control and an independent test |
OWASP notes that static analysis can run repeatedly in continuous integration and highlights the problematic code location, and that dynamic scanners probe an application from the outside. Both ideas suit internal tools, because they cost little once set up.
What to check by hand
Scanners rarely judge these, so a short manual review pays off.
- Authentication: does the tool use single sign-on, or its own password table?
- Authorization: can a regular user open an admin URL by typing it?
- Audit trail: does it log who changed what?
- Offboarding: does a leaver lose access the same day?
- Data export: can any user download everything?
Steps to roll this out
- List internal apps and who owns each.
- Score each by data and privilege held, as in the table.
- Turn on dependency scanning everywhere first. It is the cheapest and finds known flaws in forgotten tools.
- Retire apps nobody owns. An orphaned tool is pure risk.
- Re-score when an app gains a new user group or an outside connection.
A worked example
Picture a staff expenses tool, reachable only on the corporate network. It holds names, bank details and approval chains. The data is sensitive, so it lands in the middle row of the table. The team turns on dependency scanning, adds an authenticated dynamic scan against a test copy, and checks by hand that an ordinary employee cannot open the finance approver screen by guessing the address.
None of that takes more than a few days. Compare it with the cost of explaining to staff why their bank details were readable by anyone who could log in.
Mistakes to avoid
- Treating the network boundary as the only control.
- Giving internal tools shared admin accounts because nobody outside will see them.
- Skipping patching since nobody outside can reach the app. Known flaws are most useful to an attacker who is already inside.
Where Safeguard fits
Safeguard's asset discovery helps surface forgotten internal repositories, and its SBOM and dependency scanning checks them for known vulnerable packages, with gates available for pull requests. Access control reviews and dynamic checks need other tools and people. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Is a VPN enough to skip testing?
No. It restricts network access but does nothing about flaws in the app, weak internal authentication or stolen credentials.
What is the cheapest useful check for an internal tool?
Dependency scanning, because it needs only the lockfile and finds known issues in packages nobody has updated for years.
Sources
Last reviewed: 19 October 2026.
