DEV Community: Sheer Safe

How to Prepare for Your First Penetration Test

Sheer Safe — Tue, 11 Aug 2026 11:55:48 +0000

A first penetration test goes well when three things happen before testing starts: you scope it tightly, you hand over the right access and documentation up front, and you go in planning to fix what's found, not just file the report. Get those three right and the test itself becomes the easy part.

Most of the friction in a first pentest doesn't come from the testing. It comes from teams discovering, mid-engagement, that nobody agreed on what's being tested, nobody has the login credentials ready, or nobody budgeted time to actually remediate anything. Here's how to avoid all three.

Scope it before you scope it out

Scoping is the single biggest driver of whether a pentest delivers value. A vague scope ("test our whole product") produces a vague, hard-to-action report. A tight scope produces a focused list of real risks you can fix.

Before you talk to any testing team, get clear internally on:

What's in scope. Specific applications, APIs, cloud environments, or network segments, not "everything we own."
What's explicitly out of scope. Third-party systems, production databases you can't risk touching, or anything still in heavy active development.
Test type. Application testing, infrastructure/network testing, cloud configuration review, or a combination — they require different access and skills.
Authenticated vs. unauthenticated testing. Do you want testers to try to break in from outside, act as a logged-in user, or both?

If you're not sure how to draw these lines, that's normal for a first test. A good testing partner will help you scope it rather than hand you a form and walk away. Our VAPT (Vulnerability Assessment and Penetration Testing) service starts with exactly this conversation, because a well-scoped test is worth more than a broad but shallow one.

Access and documentation to have ready

Nothing stalls a pentest faster than waiting three days for someone to provision a test account. Have these ready before the test starts:

Test accounts at each relevant permission level (admin, standard user, guest), not your personal login.
A current architecture overview. Even a rough diagram of how systems, services, and cloud accounts connect saves testers hours of discovery time that's better spent finding real issues.
A list of known issues. If you already know something's weak, say so. Testers can verify it and move on to what you don't know about.
Named internal contacts who can respond quickly if testers hit something unexpected: a locked account, a rate limit, or a system that behaves oddly under testing.
Change freeze awareness. Flag any planned deployments or maintenance windows that overlap with the test dates.

None of this needs to be polished. A messy but honest architecture note is more useful than a beautifully formatted diagram that's a year out of date.

Realistic timelines: what actually happens week by week

Timelines vary with scope, but the shape is usually similar:

Scoping and access setup. This is where most delays happen if it's not planned ahead. Get accounts and documentation ready before, not during, this window.
Active testing. Testers work through the agreed scope, manually probing for real exploitable weaknesses rather than just running automated scans.
Findings review and reporting. Results are written up with severity, evidence, and practical remediation steps, not just a list of tool output.
Remediation and re-test. The part most first-timers underestimate. Fixing what's found, then verifying the fix actually worked, is where the real security improvement happens. Build remediation time into your plan from the start. Without it, the test ends with a report that nobody acts on.

What "done" looks like: the fix cycle, not the file

A pentest report matters less than what happens after it: whether the findings actually get fixed. Treat the report as a prioritized to-do list, and "done" means each item on it has been addressed and re-checked, not that the PDF has been read and stored.

In one engagement with a venture-backed technology company that had no dedicated security hire, this approach surfaced over 900 findings across their AWS environment and more than 580 in GCP. Rather than leaving those as a static report, the findings were worked through and remediated, along with reaching full endpoint EDR (Endpoint Detection and Response) coverage and containing an active intrusion discovered along the way. You can read the details in our case study.

That's the standard worth aiming for: findings get fixed, fixes get verified, and the business comes out the other side measurably harder to attack, not just better documented.

If your team doesn't have capacity to close that loop internally, ongoing support through managed security or a virtual CISO (Chief Information Security Officer) can carry remediation through to completion rather than leaving it as next quarter's backlog.

For general guidance on structuring a security testing program, the U.S. National Institute of Standards and Technology (NIST) publishes freely available frameworks worth a look as background reading.

Get ready this week

If a first pentest is on your roadmap, the highest-leverage thing you can do this week is draft your scope and pull together whatever architecture notes and access lists you already have, even in rough form. That single step removes most of the friction before testing even begins.

If you'd rather talk it through first, our free security review is a low-friction way to get a senior read on where you stand and what a first test should focus on.

Originally published at sheersafe.com.

1,480+ cloud security findings in one startup: field notes

Sheer Safe — Thu, 06 Aug 2026 15:54:41 +0000

Research · 4 min read · Aug 4, 2026

What this is: an honest breakdown of a single real engagement, anonymized at the client's request. This is one company, not a survey, so treat the numbers as a detailed example rather than an industry average. We are sharing it because the shape of what we found is common, even when the exact counts are not.

The headline numbers

In one end-to-end review of a venture-backed technology company's cloud environment, we surfaced:

900+ findings in AWS
580+ findings in GCP
1 active intrusion, detected and contained during the work
100% of endpoints brought under endpoint detection and response (EDR) by the end

That is more than 1,480 cloud findings in a company that, by every outward measure, was doing fine: a fast-growing product, real customers, and a capable engineering team. What they did not have was a dedicated security hire. That is the point.

Why the numbers get this high

A count in the thousands sounds like negligence. It usually is not. It is drift.

As a cloud environment grows, small shortcuts pile up faster than anyone reviews them, and the same handful of categories show up again and again: over-permissioned access, storage that is more open than intended, services exposed to the internet, secrets sitting in code or config, and logging that was never fully switched on.

None of these is exotic. Together, across a real environment, they add up quickly.

The detail that was not a number

The most important thing we found was not on the list. During the review, we detected an intrusion that was already underway and contained it.

A scanner would have added a line to a report. Finding an active attacker, understanding what they were doing, and shutting it down took people. That gap, between a list of possible issues and an attacker already inside, is the whole reason manual review exists.

The number worth celebrating: 100%

By the end of the engagement, every endpoint was under endpoint detection and response. Endpoint coverage is one of the few security metrics with a clean finish line: you are either watching all of your machines or you are not.

Going from partial to full is a concrete, achievable win, and one of the highest-value moves a small team can make.

What a startup should take from this

A clean-looking company can still carry hundreds of exposures. The absence of an incident is not evidence of security.
Most of the risk sits in a few recurring categories, not clever attacks. Closing the common doors removes most of the exposure.
Tools find volume; people find the few things that matter. The contained intrusion here is the proof.
You do not need a full-time security team to close this gap. You need someone senior to look, prioritize, and fix.

How we counted

For transparency: one engagement, one company, anonymized at their request, with the sector withheld. We reviewed the AWS and GCP environments end to end, using automated tooling for coverage and manual review for prioritization and exploit paths.

A finding is an issue worth investigating, ranked by real risk. It is not the same as a breach. It is something worth looking at before someone else does.

The takeaway

The headline is not that this company was unusually exposed. It is that it looked completely normal and still had more than 1,480 things worth fixing, plus an attacker already inside.

If you are growing fast without a dedicated security hire, the honest assumption is that your environment looks similar. The good news is that most of it is closable, and you can find out where you stand in a single review.

Next step

Want to know what your own environment looks like? A free security review will show you where you stand today.

Originally published at sheersafe.com

Virtual CISO vs. Full-Time Hire: What Startups Really Need

Sheer Safe — Mon, 03 Aug 2026 15:52:39 +0000

For most startups and growing businesses, a virtual CISO (vCISO — a chief information security officer engaged on a fractional or contract basis rather than full-time) delivers better value than a full-time hire until the company reaches a specific size and complexity threshold. Below that threshold, you need senior judgment more than you need a full-time seat. Above it, you often need both.

This is the framework we walk clients through before they spend a dollar, because getting it wrong is expensive in both directions: an underused full-time hire, or a fractional leader stretched past what the business actually needs. It's also worth saying plainly: the vCISO model has its own limits, which we cover below rather than skip past.

Cost: the trade-offs beyond salary vs. retainer

The obvious comparison is salary versus retainer. That's the wrong comparison — the real cost of each model shows up elsewhere.

What a full-time hire actually costs you:

Recruiting time and a search that can stall for months if you're targeting a specific seniority.
Onboarding, benefits, and tooling on top of salary.
A ramp-up period before they're fully effective in your environment — the exact length varies by company, but it's rarely instant.
The risk of hiring the wrong seniority: too junior and they can't make judgment calls under pressure; too senior and you're overpaying for a role that doesn't yet need a full plate.

What a vCISO model actually costs you:

A retainer sized to scope, not to a five-day-a-week desk — you're paying for outcomes and decisions, not presence.
Less day-to-day availability, which has to be managed explicitly in the engagement (more on that below).
Some loss of institutional memory compared to someone who's been embedded for years.

For a company without a dedicated security hire, the vCISO route is usually the more efficient way to get board-ready reporting, a security roadmap, and vendor and tool decisions made by someone who's done it before — without the full overhead of a permanent seat.

Coverage: what each model actually gives you

A full-time hire gives you presence: someone embedded in daily operations, in every planning meeting, building institutional knowledge over years. That's valuable once security touches every part of the business.

A vCISO gives you breadth. Because the role is fractional and often serves multiple clients, a good vCISO has usually been exposed to a wider range of environments and incident types than a single in-house hire will see in the same stretch of time. That's our view based on how the model works, not a claim we can quantify — but it's the reasoning behind why a vCISO is often useful for a startup making its first real security decisions: which framework to adopt, what to prioritize on a limited budget, how to answer an enterprise customer's security questionnaire without over-promising.

On availability specifically: it's fair to ask how a fractional leader can also handle something as urgent as an active intrusion. In one engagement with a venture-backed technology company that had no dedicated security hire, a vCISO led the security program end-to-end — directing a cloud security review that surfaced 900+ AWS findings and remediated 580+ GCP findings, coordinating penetration testing, bringing endpoint EDR (endpoint detection and response) coverage to 100%, and containing one active intrusion during the engagement. That was possible because the engagement had a defined escalation path and incident response scope agreed upfront, not because a vCISO is available around the clock.

The honest version of the availability trade-off is: it's real, and it's manageable if the engagement's escalation terms are clear before you need them, not after. You can read more in our case study on that engagement and our incident response service.

Where a vCISO model has real limits

We're a vCISO provider, so this section matters — the model isn't a strictly better version of a full-time hire, and it's worth naming where it can fall short:

Multi-client conflicts of interest. A fractional leader serving several clients has finite attention. If two clients need urgent judgment calls at the same time, something waits — that's a structural feature of the model, not a hypothetical.
Diluted accountability. Without a single full-time person "on the hook" day to day, decision rights and escalation authority need to be spelled out explicitly in the engagement. Left vague, this is where fractional arrangements quietly underperform.
Insurance and contractual requirements. Some cyber insurance policies, enterprise customer contracts, or regulatory regimes require a named, employed security officer — not a fractional or vendor-supplied one. It's worth checking your policy and key contracts before assuming a vCISO satisfies that requirement.

None of this means the model doesn't work. It means the decision should account for these limits rather than assume them away.

Maturity stage: match the model to where you are

The right choice depends less on headcount and more on how much decision-making security requires day to day.

Pre-seed to Series A: You need someone to set direction, not manage a team. A vCISO fits well here: building a lightweight roadmap, getting basic controls in place, and being ready to answer customer security questionnaires.

Series B to C, scaling fast: Security decisions start touching product, infrastructure, and compliance at the same time. A vCISO working alongside a small internal security or IT function, often supported by managed security for day-to-day monitoring, can cover this stage well — provided the conflicts and accountability points above are addressed in the contract.

Post-Series C or high-compliance sectors: Regulatory obligations, customer contracts, and internal headcount start requiring daily presence and a dedicated, named budget owner. This is where a full-time hire, sometimes supported by a vCISO for specialist advisory, becomes the better structure.

The Cybersecurity and Infrastructure Security Agency's (CISA) Cross-Sector Cybersecurity Performance Goals make a related point for organizations of any size: build controls proportionate to your risk and resources, and scale leadership as the risk profile grows, not before.

Signs you've outgrown a vCISO

A vCISO model has a natural ceiling. Watch for these signals:

Security decisions are needed daily, not weekly, and the fractional cadence can't keep up.
You've hired a security or IT team that needs full-time, in-person leadership and mentoring.
A contract, insurance policy, or regulation now requires a named, full-time accountable owner.

Want this looked at for real? Get a free security review and we'll show you where you actually stand.

Critical RCE in Widely-Used VPN Appliances: What CISOs Should Do Now

Sheer Safe — Sun, 02 Aug 2026 17:03:30 +0000

A newly disclosed unauthenticated remote code execution (RCE) flaw affects several widely deployed VPN appliances. Because these devices sit at the network edge, exploitation gives an attacker a foothold before any internal control is in play.

What we know

The vulnerability is pre-authentication and network-reachable.
Proof-of-concept exploit code is already circulating.
Edge appliances are rarely patched on the same cadence as endpoints.

The primary weakness

The flaw stems from improper input validation in the appliance's web management interface, allowing a crafted request to execute code as root.

Remediation

Apply the vendor patch immediately; if you cannot, restrict management interface exposure to a trusted management network only.
Rotate credentials and inspect for signs of prior compromise.
Enable and review logging on the appliance and upstream firewall.

Bottom line

Treat edge appliances as tier-0 assets. A single unpatched VPN box can undo an otherwise mature security program.