DEV Community: Sheer Safe

Artifactory Token Forgery: Why Your Build Tool Needs Prod-Level Scrutiny

Sheer Safe — Thu, 03 Sep 2026 17:36:41 +0000

Artifactory Token Forgery: Why Your Build Tool Needs Prod-Level Scrutiny

Advisory · 6 min read

The short answer

If an attacker can forge or steal a token for your artifact repository, they don't need to touch production at all. They can poison the builds that become production instead.

Token forgery flaws in tools like Artifactory are a reminder that artifact stores aren't back-office plumbing. They're a privileged system, and they deserve the same access control, monitoring, and testing rigor you already apply to production.

Why your artifact store deserves production-grade scrutiny

Security researchers have repeatedly found authentication and token-handling flaws in popular artifact repository platforms — the kind of software that stores your build outputs, container images, and dependency caches. A forged or misused token in one of these systems can let an attacker impersonate a legitimate service account, pull signing keys, download proprietary code, or push a tampered artifact that your pipeline then deploys as if it were legitimate.

That's the uncomfortable part. Most teams put real effort into locking down who can touch production servers, databases, and cloud consoles. Far fewer apply the same discipline to the artifact store sitting upstream of all of it. But if that store trusts a forged token, it hands over exactly what an attacker needs to walk straight into your deployment path — often with less logging and fewer alerts than production itself.

The practical takeaway: your CI/CD (continuous integration/continuous delivery) artifact repository is not a convenience tool. It's an identity and access boundary, and it should be treated as one.

A checklist to run this week

You don't need a major project to start closing gaps. Work through this list against your actual artifact repository (Artifactory, Nexus, GitHub Packages, or equivalent):

Inventory every token and service account with write access. If you can't produce this list in under ten minutes, that's your first finding, not a footnote.
Apply the "if you can't remember, rotate it" rule. If nobody can say when the admin or CI token was last rotated, rotate it now and put rotation on a recurring calendar item.
Separate read from write. Most humans and pipelines only need to pull artifacts. If a broad group of accounts can push or promote artifacts, tighten that to the smallest set that actually needs it.
Turn on artifact signing and verification if your tooling supports it. If your pipeline can't distinguish a signed artifact from an unsigned one, an attacker doesn't need to forge a token — they just need to slip in a lookalike package.
Check where your artifact store logs go. If access and download events aren't flowing into the same monitoring you use for production, treat that as a gap to close, not a someday item.

Most of this doesn't require new tooling. It requires spending an hour treating the artifact store like the privileged system it is.

The obvious objection: "We don't have the resources to review this ourselves"

Fair pushback, especially for teams without a dedicated security hire. Two realistic paths from here:

If your team already runs a DevSecOps practice, fold artifact repository review into the pipeline hardening work you're doing anyway. Token hygiene and access review fit naturally alongside dependency scanning and build integrity checks. Our DevSecOps work is built around this kind of pipeline-level scrutiny.

If you don't have that capacity in-house, a focused penetration test that covers your CI/CD and artifact infrastructure — not just your web app — will surface these gaps concretely instead of leaving them as an assumption. That's the scope we cover in our VAPT (vulnerability assessment and penetration testing) engagements.

In one engagement with a venture-backed technology company that had no dedicated security hire, our review of their cloud and infrastructure surfaced hundreds of findings across their AWS and GCP environments and led to the discovery of a contained active intrusion. It's a useful illustration of how much sits undiscovered in infrastructure teams assume is "just tooling."

What you shouldn't do is wait for a vendor patch and call the job done. Patching a specific flaw closes one door. It doesn't fix the underlying habit of treating artifact stores as lower-trust than production. Even after a patch ships, the access-control and monitoring gaps above will still be there unless someone actually reviews them.

Make it part of an ongoing program, not a one-time fix

Artifact repository security isn't a project you finish. It's a posture you maintain, the same way you maintain production access reviews. New service accounts get created, tokens get issued for one-off automation and never revoked, and permissions creep outward over time. A single audit fixes today's problem. A recurring review catches next quarter's.

For general guidance on securing software supply chains and build infrastructure, CISA's (Cybersecurity and Infrastructure Security Agency) resources are a solid public reference point.

If you want a second set of senior eyes on where your build pipeline and artifact store actually stand today, start with our free security review. It's a quick way to find out whether your build tool has quietly become the most trusted admin account in your environment.

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

Originally published at sheersafe.com

MFA Fatigue: Why Employees Approve the Push That Isn't Theirs

Sheer Safe — Tue, 01 Sep 2026 01:03:02 +0000

Employees approve pushes that aren't theirs because tapping "Approve" has become a reflex, not a decision. Push-bombing (also called MFA fatigue) exploits that habit: attackers already have a valid password and just need one tired, distracted, or annoyed employee to make the prompts stop.

A stronger MFA (multi-factor authentication) app won't fix this. What works is a written rule employees actually follow, backed by settings that make the reflex harder to trigger.

What Push-Bombing Actually Does

This attack doesn't break your MFA. The attacker just needs a username and password already in hand, from a breach dump, a phishing kit, or credential stuffing. From there:

The attacker logs in with the stolen credentials, which triggers a legitimate MFA push to the real employee's phone.
Denied once, they try again, sometimes dozens of times, often late at night or during a known busy stretch.
Eventually the employee, mid-meeting, half-asleep, or just done with the buzzing, taps Approve to make it stop.
The attacker now has a fully authenticated session, indistinguishable from a normal login.

Nothing about your encryption, your password policy, or your MFA vendor failed here. A person made a split-second decision under annoyance, and the system did exactly what it was built to do: let an approved push through.

Why Habit Beats Technology Here

MFA approval is trained behavior. Employees see the prompt dozens of times a week for legitimate reasons: a VPN reconnect, an app token refresh, a new device login. Approving on sight becomes automatic, the same way people click through cookie banners without reading them.

Attackers know this. They're not trying to fool a security control; they're trying to trigger a conditioned response. That's why MFA strength alone can't close this gap. The weak point is the moment of habit, not the cryptography behind the prompt.

The Fix Is Procedural First, Technical Second

Two layers matter, and most businesses only build one:

Technical layer: where your identity provider supports it, move to number-matching push approval (the user types a code shown on-screen instead of tapping a single button) or phishing-resistant options like passkeys/FIDO2. Also enable any built-in alerting or lockout after repeated failed or denied prompts. Most modern platforms offer this, but it's rarely turned on by default.

Procedural layer: a written, one-line rule every employee can apply without thinking: if you get an MFA prompt you didn't just trigger by logging in yourself, deny it and report it immediately. Don't just dismiss it.

The reporting part is the piece most policies skip. An employee who quietly denies five pushes in a row and moves on has just watched an active attack and told no one. A denied-and-reported push is a signal your team can act on. A denied-and-ignored push is a near-miss nobody learns from.

A Decision Rule Employees Can Actually Use

Skip the long security-awareness deck. Give people this instead:

Did you just try to log in yourself, right now?

If yes, approve.
If no, or if you're not sure, deny it.
If you get more than one unexpected prompt in a short window, treat it as an active attack: deny all of them and report immediately, don't wait to see if they stop.

This is deliberately simple. Simple rules survive 2am and Monday-morning chaos; nuanced ones don't.

What To Do If You See a Burst of Denied Pushes Right Now

If your logs show repeated MFA denials for one account in a short window, don't wait for a definitive answer on whether it was "just noise." Force a password reset for that account, revoke active sessions and tokens, and check recent login activity for that user across your key systems. Treat it as a likely compromised credential first, and downgrade it later if it turns out to be nothing.

Waiting for certainty is how a contained incident becomes a real one.

If it does turn into something bigger, this is exactly the scenario our incident response service is built for. The goal is containing access fast, not documenting it after the fact. In one engagement with a venture-backed technology company, our team contained an active intrusion during the assessment, a reminder that the gap between "a credential looked odd" and "an attacker has real access" can close very quickly.

If You Don't Have a SOC Watching This

Most small and mid-size businesses don't have someone watching authentication logs at 2am, and that's a fair objection to all of the above. None of it matters if nobody sees the burst of denied pushes.

Two things help without requiring a full security team:

The policy and decision rule above cost nothing and work regardless of tooling. Put it in writing, tell people once, and reinforce it when someone reports a denied push (praise the report, don't scold the trigger).

For the monitoring gap, you don't need to build a SOC (security operations center). You need someone checking the right signal at the right time. A managed security setup or ongoing virtual CISO support can configure alerting so a burst of MFA denials reaches a person, not a log file nobody opens.

For general background on phishing-resistant authentication, CISA (Cybersecurity and Infrastructure Security Agency) publishes practical guidance worth a read.

Start With a Free Review

If you're not sure whether your MFA setup, alerting, and employee policy actually close this gap, that's worth a look before an attacker finds out for you.

Sheer Safe offers a free security review to help you see where the real gaps are. No pressure, no long sales process.

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

PaperCut Zero-Day: Why 'Boring' Internal Apps Get Hit First

Sheer Safe — Fri, 28 Aug 2026 01:20:07 +0000

Attackers hit tools like PaperCut first because those tools are trusted, internet-facing more often than IT realizes, and almost never on anyone's patching priority list. The fix isn't a bigger firewall. It's knowing which "boring" internal apps you're running and treating them like the front door they actually are.

What happened with PaperCut, in plain terms

PaperCut is print management software used by thousands of organizations to control who can print what, and how much it costs. It's the definition of unglamorous IT plumbing. That's exactly why it became a headline: serious vulnerabilities in PaperCut's server software were exploited by ransomware operators to gain an initial foothold inside networks, then move laterally to more valuable systems. Government advisories, including from CISA (the Cybersecurity and Infrastructure Security Agency), flagged active exploitation and urged organizations to patch immediately.

Nothing about PaperCut itself is unusual. Print servers, license managers, backup consoles, VPN (Virtual Private Network) appliances, internal wikis: these are the tools nobody demos to the board, nobody threat-models, and nobody remembers exists until something breaks. That's the pattern worth paying attention to, not the specific product name.

Why "boring" internal apps get hit first

Attackers aren't picking targets based on how exciting the software is. They're picking based on three things:

Trust level. Internal apps often run with elevated privileges. A print server frequently has domain-level access to talk to every printer and print queue on the network.

Exposure you forgot about. Many of these tools were set up years ago by an admin who's since left, sometimes with remote or web-based admin consoles left reachable from outside the network "temporarily."

Low monitoring, low patching. Nobody watches a print server's logs. Nobody schedules its updates. It sits there, working fine, until a vulnerability is found. Then it sits there, still working fine, but now compromised.

Put together: a vulnerability in a system nobody's watching, with more access than it needs, that nobody patched. That's not bad luck. That's the profile attackers scan for.

A one-week checklist: find your own PaperCut

You don't need a full audit to make real progress. Set aside a few hours this week and work through this:

List every internal-facing app with an admin web console. Print management, backup software, network monitoring tools, license servers, old intranet portals. If it has a login page, it's on the list.
Check what's reachable from outside your network. For each item, confirm whether it's actually restricted to internal access or accidentally exposed. Anything with a public IP and a login page is a priority.
Ask "who owns this?" If nobody can answer in under a minute, that's a red flag. Unowned systems don't get patched.
Check the vendor's advisory page for each tool, once. Most vendors publish security bulletins. A ten-minute check now beats finding out from a ransomware note later.
Apply this decision rule: if a system is both internet-reachable and running with elevated network permissions, patch it within days of any vendor advisory, not on your normal quarterly cycle.

This kind of inventory-and-triage work is exactly what a structured vulnerability assessment and penetration test is designed to surface, instead of relying on someone remembering to check.

The objection: "We can't patch everything immediately"

Fair. Most IT teams are short-staffed, and patching production systems carries its own risk of breaking something. Two realistic fallbacks if immediate patching isn't possible:

Restrict exposure first, patch second. If you can't patch a vulnerable admin console today, you can usually take it off the public internet today: put it behind a VPN or restrict it to internal IP ranges. That single step closes off the most common exploitation path while you plan the patch.

Segment the blast radius. If a print server or similar tool doesn't need domain admin-level access to do its job, it shouldn't have it. Reducing its permissions won't stop an intrusion, but it limits what an attacker can do once they're in.

If your team doesn't have the bandwidth to track vendor advisories and triage this kind of risk on an ongoing basis, that's a program gap, not a one-time task. That's the problem managed security and virtual CISO support exist to close.

Treat "boring" as a category, not a one-off fix

The lesson from PaperCut isn't "patch PaperCut." It's that any internal tool can become the entry point, and the ones most likely to be missed are exactly the ones that feel too unimportant to review.

The fix is a habit: inventory internal apps, check exposure, confirm ownership, and treat vendor advisories for infrastructure tools with the same urgency as advisories for your core business software.

If you'd like a second set of eyes on what's quietly exposed in your environment, our free security review is a low-friction way to start. No pressure, just a clear picture of where you stand.

Originally published at sheersafe.com

The First Five Logs Worth Turning On With No Security Team

Sheer Safe — Mon, 24 Aug 2026 12:53:19 +0000

No SOC, no budget for tools yet? Turn on these five logs first — identity, admin actions, cloud API, endpoint, and network egress.

Before you buy a single security tool, turn on logging for five things: identity and authentication events, admin actions, cloud API activity, endpoint activity, and network egress. Most of the breaches a small IT team actually has to deal with leave a trail in one of these five places, and most cloud platforms give you the raw logs for free.

The gap usually isn't budget. Most of the time, nobody flipped the switch.

None of this requires a security operations center. It just means that if something goes wrong, you have evidence to work with instead of guesses.

Log 1: Identity and authentication events

Your identity provider (Microsoft Entra ID, Okta, Google Workspace) already logs every sign-in attempt. Most SMBs never turn on the audit or sign-in log export, or they turn it on and never look at it.

Decision rule: if you see a successful login from an unfamiliar country or an "impossible travel" pattern (same account, two locations, minutes apart) followed by a password reset or new device registration, treat it as a compromised account until proven otherwise. Lock it down first, investigate second.

This week: confirm sign-in logging is enabled and set a retention period long enough to look back at least a month. That's the minimum window most incidents take to surface.

Log 2: Admin actions

Authentication logs tell you who got in. Admin action logs tell you what they did with that access. Every major platform — your identity provider, your cloud console, your firewall — has an audit trail for privileged changes: new admin accounts created, MFA disabled, permissions escalated, firewall rules changed.

Decision rule: any MFA disablement, new admin or owner account, or permission escalation that happens outside a known change window is worth a five-minute check, every time. These are rare events in a healthy environment, which is exactly why they're cheap to monitor and expensive to ignore.

Log 3: Cloud API activity

If your infrastructure runs on AWS, GCP, or Azure, the platform is already recording every API call: who called it, from where, and what it changed. AWS CloudTrail, GCP Cloud Audit Logs, and Azure Activity Log are on by default in most accounts, but often not routed anywhere useful or retained long enough to matter.

This log category tends to reveal the most, and the fastest. In one engagement with a venture-backed technology company that had no dedicated security hire, a cloud security review across AWS and GCP surfaced more than 900 AWS findings and over 580 GCP findings once the logs and configurations were actually examined. Most of it was invisible until someone looked. Read more in the case study.

Decision rule: if you can't answer "who created or deleted this resource and when" within a few minutes, your cloud API logging isn't usable yet. Fix that before buying a cloud security tool on top of it. See our cloud security service for what a proper review looks like.

Log 4: Endpoint activity

You don't need a full EDR (Endpoint Detection and Response) platform to start. Windows Defender, macOS's built-in logging, and most modern OSes already capture process execution, new persistence mechanisms, and security tool tampering. You just need it centralized somewhere, even a simple log collector, instead of trapped on each individual machine.

Decision rule: treat any of the following as an automatic escalation, not a "look at it later" item: antivirus or EDR disabled without a ticket, a new scheduled task or startup item you didn't create, or an Office document spawning a command shell. These three patterns show up in a disproportionate number of real intrusions.

Log 5: Network egress

Inbound traffic gets all the attention. Outbound traffic, what's leaving your network, is where data theft and command-and-control activity actually show up. Firewall logs, VPC (Virtual Private Cloud) flow logs, and DNS (Domain Name System) query logs will tell you this if they're turned on and someone's watching for the obvious patterns.

Decision rule: flag large or unusual outbound transfers to destinations you don't recognize, and DNS lookups to newly registered or oddly-named domains. You don't need to catch every anomaly. You need to catch the two or three patterns that account for most real exfiltration attempts.

"We don't have anyone to actually watch these logs"

This is the honest objection, and it's fair. Turning on five logs doesn't help if nobody ever reads them. There are three realistic paths:

Set narrow, high-confidence alert rules (the ones described above) so you're only interrupted for things that genuinely matter, not every anomaly.
Do a scheduled weekly review instead of real-time monitoring. Slower, but far better than nothing, and manageable for a lean IT team.
Hand ongoing monitoring to a partner built for this. Our managed security service exists for exactly this gap — teams with real infrastructure and no bandwidth to watch it around the clock. If something does slip through, our incident response service picks up from there.

Whichever path you choose, the logs need to exist first. You can outsource watching them. You can't outsource having them.

Where to start this week

Confirm sign-in and admin audit logs are enabled in your identity provider, with at least a month of retention.
Turn on CloudTrail, Cloud Audit Logs, or Activity Log in every cloud account you run production in, and check they're not just enabled but actually routed and retained.
Centralize endpoint logs from every machine, even into a basic collector, rather than leaving them local.
Enable firewall and DNS logging for outbound traffic, and write down the two or three patterns you'd escalate on immediately.

None of this requires a big budget or a security hire. It requires someone to spend an afternoon flipping the right switches.

If you want a second pair of eyes on what's already on, what's missing, and what's worth fixing first, start with a free security review: no pressure, just a clear picture of where you stand.

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

Why Legacy Auth Fuels Mass Password Spraying

Sheer Safe — Thu, 20 Aug 2026 11:28:49 +0000

Legacy IMAP, POP3, and basic-auth sign-in paths let attackers skip multi-factor authentication (MFA) entirely, because those protocols predate MFA and many mail and identity systems still accept them by default. If any of these paths are open on your tenant, disable them this week. They're one of the most common ways a mass password-spraying campaign turns a handful of leaked passwords into a real breach.

Why legacy protocols skip MFA entirely

Modern sign-in flows (OAuth, modern authentication) can enforce a second factor and conditional access checks before granting access. IMAP, POP3, and basic auth were designed to send a username and password in one shot. There's no step where a challenge, push notification, or one-time code fits in.

So if legacy auth is still enabled anywhere on your tenant, an attacker who has your password doesn't need to defeat your MFA. They just walk in through a door that was never built to ask for it.

How mass password spraying scales through this gap

Attackers spraying passwords aren't guessing one account at a time. They take huge credential lists, usually assembled from unrelated breaches, and try a small number of common or reused passwords across thousands of accounts and domains.

They favour legacy auth endpoints for two reasons:

In many environments, these endpoints receive less rate-limiting and less monitoring than modern sign-in flows, since security tooling and alerting have typically been built around OAuth and conditional access, not older protocols.
A successful hit produces no MFA prompt, no push notification, no OTP request, so the account owner usually has no idea anything happened.

That gap means a spray campaign can succeed quietly against a slice of your organization's mailboxes without a single "approve this sign-in" alert ever firing.

Check this week: are you exposed right now?

Don't assume. Verify. Pulling and reviewing the right logs is a quick, well-scoped task for most IT teams, not a major project:

Microsoft 365 / Entra ID: pull sign-in logs and filter by client app. Look for IMAP4, POP3, Authenticated SMTP, or "Other clients." Any hits mean legacy auth is live.
Conditional access / Security Defaults: confirm a policy actually blocks legacy authentication. Having MFA enabled is not the same as blocking these protocols.
Google Workspace: check whether any organizational unit still allows "less secure app access" or basic-auth IMAP/POP.
On-prem Exchange or hybrid setups: legacy auth risk doesn't disappear just because you're not fully cloud-hosted. Check IIS/Exchange logs for IMAP4, POP3, and basic-auth SMTP AUTH entries, and confirm your hybrid connector isn't silently passing basic auth through to Exchange Online.
Other mail or identity providers: if you're not on Microsoft 365 or Google Workspace, ask your provider directly whether IMAP/POP/basic-auth sign-in is enabled by default and how to view a log of it. The exposure exists across most mail platforms; the audit trail just looks different.

No full admin log access? A lightweight check: try connecting to your own mailbox with an old-style email client using just a username and password. If it connects without any second-factor prompt, legacy auth is open on that account.

Decision rule: if legacy auth sign-ins show up anywhere in the last month of logs, treat it as active exposure, not a theoretical risk. Someone or something is using that door right now.

How to disable it without breaking the business

Legacy auth usually survives because IT teams worry about breaking an old scanner, a mail-merge tool, or a script nobody remembers writing. The phased rollout below avoids that problem, and most organizations can move through it in a matter of weeks rather than months:

Inventory first (days, not weeks). Use your sign-in logs to identify which accounts and apps are actually using legacy auth today.
Migrate what you can (roughly one to a few weeks). Move real users and supported apps to modern auth; for line-of-business tools, check for an updated connector or app-password option.
Block in phases (staggered over the following weeks). Start with a conditional access policy that blocks legacy auth for standard users, then extend it to service and shared accounts once you've confirmed nothing breaks.

Decision rule: if you can't identify a legitimate business reason for a legacy-auth connection within a short investigation, block it. Re-enable only if something breaks and you can name the owner and the reason. The cost of a forgotten integration is far lower than the cost of leaving a standing MFA bypass open.

What if you can't fully disable it yet

Sometimes a vendor is slow, or a piece of hardware (an old scanner, a legacy CRM sync) genuinely can't speak modern auth yet. That's a real constraint, not an excuse to leave it wide open. If you're stuck:

Restrict the legacy connection to a known IP range or location via conditional access, instead of leaving it open to the internet.
Put it on a dedicated service account with a long, unique password, and monitor its sign-ins specifically.
Set a hard retirement date. A temporary exception should have an end date attached to it, or it becomes permanent by default.

If you already suspect a spray has succeeded — unexplained sign-ins, forwarding rules you didn't set, mailbox rules that redirect finance emails — treat it as an active incident and get eyes on it fast.

In one engagement with a venture-backed technology company, fast-growing and without a dedicated in-house security hire, we contained an active intrusion while also running a broader AWS and GCP cloud security review, application and infrastructure penetration testing, and virtual CISO leadership. If you're in a similar position, our incident response service is built for exactly this kind of situation.

Make this part of an ongoing routine, not a one-off fix

Legacy auth has a way of quietly re-appearing: a new integration, a re-enabled setting after a tenant migration, a forgotten exception nobody closed out. Treat identity configuration as something to review on a schedule, not a box you tick once. Our managed security service is built around exactly that kind of ongoing, fix-first program rather than a one-time audit.

For background on requiring multi-factor authentication and reducing identity-based attack paths, CISA maintains guidance worth bookmarking on MFA.

Frequently asked questions

What is password spraying?
Password spraying is an attack technique where an attacker tries a small number of common or previously leaked passwords against a large number of accounts, rather than repeatedly guessing many passwords against one account. It's designed to avoid account lockouts while still finding the small percentage of accounts using weak or reused passwords.

Does turning on MFA automatically stop legacy auth attacks?
Not by itself. MFA has to be enforced on the sign-in path the attacker is using. Legacy IMAP, POP3, and basic-auth connections don't pass through the modern authentication flow, so they can bypass MFA entirely even when MFA is switched on for your organization. You need a separate policy that blocks legacy auth outright.

How do I know if legacy auth is actually being used in my environment?
Check your sign-in or authentication logs for the specific client app or protocol (IMAP4, POP3, Authenticated SMTP, "Other clients," or basic-auth entries in on-prem mail logs). If you don't have full admin log access, a simple test connection with an old-style mail client, as described above, will tell you quickly whether the door is open.

Is it safe to disable legacy auth for everyone at once?
It's safer to phase it: inventory first, migrate the accounts and apps you can identify, then block standard users before extending the block to service and shared accounts. That sequence surfaces the occasional forgotten integration before it becomes an outage, while still closing the gap in a matter of weeks.

If you want a fast, no-pressure look at whether legacy auth or other MFA gaps are open on your tenant right now, start with a free security review.

When a Vendor You Use Gets Breached: What to Do Next

Sheer Safe — Mon, 17 Aug 2026 12:47:41 +0000

When a vendor is breached, don't wait for their update page: figure out fast what that vendor can see or touch inside your business, and act on that answer before you have all the facts.

Vendor breaches are a recurring headline: a phone system, messaging platform, or file-sharing tool used by thousands of businesses discloses an incident, and every customer of that vendor suddenly has to ask what it means for them, usually with almost no visibility into the vendor's internal investigation. The gap between "something happened to our vendor" and "here's what we do about it" is where most companies lose time they can't get back.

Quick answers

What's the first thing to do when a vendor is breached?
Confirm exactly what that vendor can access in your systems — before you do anything else.

Should I rotate credentials before the vendor confirms exposure?
Yes, for anything plausibly exposed — even though it may briefly disrupt a live integration.

How often should I re-check a slow-to-disclose vendor?
It depends on how much access they hold — high-privilege vendors need a 48–72 hour check-in, not a week.

Do I need a written plan before an incident happens?
Yes — a one-page plan per privileged vendor, reviewed at least yearly.

Why vetting a vendor once isn't enough

Most businesses do vendor due diligence at signup: a security questionnaire, maybe a look at their trust page, a checkbox before the contract is signed. That's reasonable, but it only answers the question that matters on day one: is this vendor safe to start using?

It doesn't answer the question that matters every day after: if this vendor gets breached, what happens to us, and what do we do?

Vetting is a point-in-time filter. A breach is an ongoing event with a timeline, and your response needs its own plan, separate from the vetting checklist you ran before signing.

The fix is simple: treat vendor risk as a lifecycle, not a gate. Vet before you sign, revisit access and exposure on a regular cadence, and have a response plan ready for the vendors that matter most.

Your first 24–72 hours: a vendor breach checklist

When a vendor discloses an incident, work through this in order rather than waiting for their full report:

Confirm what the vendor actually does for you. List every system, integration, and data type connected to that vendor — not what you think it touches, but what it's actually configured to access.
Check what credentials or tokens are shared. API keys, SSO connections, webhooks, and stored payment or contact data are what attackers pivot on. Rotate anything that's plausibly exposed, even before the vendor confirms it was — accept that this may briefly break a live integration. That's a smaller cost than leaving a compromised credential live, but coordinate with whoever owns the integration so the break is expected, not a surprise outage.
Check what your contract actually gives you. Look for a breach notification clause (how fast the vendor is contractually required to tell you), any SLA language on incident disclosure, and a right-to-audit clause you can invoke to get more than their public statement offers. If your contract has none of these, that's a gap to fix at renewal — not something you can retrofit mid-incident.
Pull recent activity logs. Look for unusual logins, data exports, or configuration changes tied to that vendor's integration in the window since the breach likely started. Vendors often understate this window early on.
Loop in whoever owns customer communication and compliance. If customer or employee data may have moved through the vendor, your own notification obligations may kick in. Check what applies to your industry and state rather than assuming a fixed deadline.
Document the decision, not just the action. Write down what you knew, when, and why you chose to rotate credentials, pause the integration, or wait for more information. Log it in the same one-page plan or incident doc (see below), owned by whoever is running the response, and retain it for as long as your industry's record-keeping obligations require — this matters if a regulator or customer asks later.

If you don't have anyone in-house who can run this checklist under pressure, that's a gap worth closing before the next vendor incident, not during it. This is exactly the kind of work covered under incident response.

Figure out your actual blast radius

Not every vendor breach is your problem. A breach of a vendor's marketing database is very different from a breach of a vendor that holds your SSO tokens or has admin access to your cloud environment.

A simple heuristic: rank your vendors by what they can do, not what they cost. A vendor with write access to your infrastructure, your identity provider, or your customer data deserves an incident plan. A vendor that only has your name and email for a newsletter probably doesn't need the same level of response.

In one engagement, a venture-backed, fast-growing technology company with no dedicated security hire brought us in for a cloud security review across AWS and GCP, alongside manual application and infrastructure penetration testing and virtual CISO leadership. The review surfaced 900+ AWS findings and worked through 580+ GCP findings to remediation, brought endpoint EDR coverage to 100%, and — during the engagement — we identified and contained one active intrusion.

That containment was only possible because the access map already existed: we knew which systems, credentials, and integrations mattered before the intrusion turned up, which is exactly the map you need on hand before a vendor breach forces the same question about a system you don't control. Details are in our case study.

Build the plan before you need it

Handling a vendor breach well comes down to one thing decided in advance: who owns the call to cut a vendor's access, and how quickly that can actually happen on your systems. A vetting spreadsheet doesn't make that call under pressure — a named owner and a tested process do.

Here's a template you can copy directly, for any vendor with privileged access (identity, payments, cloud infrastructure, core communications):

Vendor Breach Response Plan — [Vendor Name]

Owner: [name/role] — the person authorized to cut access without a meeting
Access this vendor holds: [systems, data types, integrations, credential types]
Notify first, in order: [internal roles]
Immediate action: [specific credentials/integrations to rotate or disable]
Customer/compliance trigger: [conditions requiring external notification, and who drafts it]
Re-check date: [set explicitly — see blast-radius guidance below]

Format: one page, kept wherever your team already stores operational runbooks (shared drive, wiki, or IR tool) — not buried in email.

Owner: whoever holds the security lead or vCISO role keeps it current.

Retention: keep completed plans, with decisions logged, for as long as your compliance obligations require incident records to be retained; review the plan itself at least once a year or whenever the vendor relationship changes significantly — a new integration, more data, or a higher access level.

If you don't have the internal bandwidth to build and maintain this across a growing vendor list, a fractional security lead can own it without you hiring full-time. That's the core of what a virtual CISO does, and it pairs naturally with compliance support if notification obligations are part of the picture.

What if the vendor is slow or won't tell you anything?

This is the realistic failure mode, and it's common. Vendors under legal advice often say very little in the first days. Don't wait for their statement to act.

Work from what you control: rotate your own credentials and tokens regardless of confirmation (accepting the integration risk noted above), restrict the vendor's access to the minimum your operations can tolerate, and set a firm re-check date rather than "when they update us."

How firm depends on the same blast-radius logic from earlier: for a vendor with privileged access to identity, payments, or infrastructure, check back in 48–72 hours, not a week — that's the reason they landed in the high-risk tier in the first place. For a lower-access vendor, a week is a reasonable cadence.

If a high-access vendor stays silent past your re-check date, that silence is itself a decision point — consider suspending the integration until you get real answers.

The takeaway

Vendor breaches are going to keep happening. That's the reality of running a business on other people's software. What separates a bad week from a bad year is whether you had a response plan sitting ready, or whether you're building one from scratch while the news is still breaking.

If you're not sure how exposed your business is to your current vendor stack, a good starting point is a free security review. It's a low-friction way to see where your real access risks sit before you need to react to one.

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

Ransomware Now Reboots Into Safe Mode to Kill Your EDR

Sheer Safe — Fri, 14 Aug 2026 17:55:12 +0000

Akira and other ransomware operators have found a reliable way to blind your defenses before they encrypt anything. They reboot the machine into Windows Safe Mode with Networking, a state where most endpoint detection and response (EDR) agents simply don't run.

Fixing this doesn't require a new tool. It requires closing the specific configuration gaps that make the trick possible.

What's actually happening

Safe Mode exists for troubleshooting. Windows starts with a minimal set of drivers and services, deliberately excluding most third-party software. That's useful when you're diagnosing a stuck update. It's also useful to an attacker, because most EDR and antivirus agents are third-party services, and in Safe Mode they often never load in the first place.

Akira has been observed using this to its advantage. Once an attacker has admin-level access to a network, usually after credential theft, an exposed remote access tool, or a known vulnerability, they push a scheduled task or use built-in Windows commands to force affected machines to reboot into Safe Mode with Networking. The "with Networking" part matters: it keeps enough connectivity alive for the ransomware binary to reach out, drop payloads, or coordinate encryption across multiple hosts, while the security tooling that would normally stop it stays dark.

Why Safe Mode beats most EDR tools

This isn't a flaw in any one vendor's product. It's a gap in how Windows boot modes and third-party services interact. A few things make it effective:

Service load order. Safe Mode only starts services explicitly flagged to run in that mode. Most EDR agents aren't configured that way by default.

Local admin rights are the key. Forcing a Safe Mode boot and disabling recovery options typically requires local administrator access, which is exactly the level of access ransomware crews work to obtain before the final encryption stage.

It's quiet. A reboot into Safe Mode can look like routine IT activity if nobody's watching for it specifically. By the time anyone notices something's wrong, encryption is already running.

The takeaway for a business owner or IT leader: your EDR license does its job right up until the moment an attacker with admin rights decides which mode Windows boots into. Prevention has to happen earlier in the chain.

Closing the gap: what to do this week

You don't need a large security team to meaningfully reduce this risk. A few concrete steps:

Restrict who can force a reboot into Safe Mode. Group Policy can block boot configuration changes (via bcdedit) for standard users, and you can tighten which accounts hold local admin rights on endpoints in the first place. Fewer standing admins means fewer paths to this technique.

Check your EDR vendor's tamper protection and Safe Mode options. Several modern EDR platforms now support running in Safe Mode or alerting on unexpected boot-mode changes. If yours does, confirm it's actually turned on. This is often an opt-in setting, not a default.

Monitor for the behavior, not just the malware. Unexpected use of bcdedit, unplanned reboots across multiple machines in a short window, or scheduled tasks that modify boot configuration are early warning signs, well before encryption starts.

Segment and back up properly. Immutable, offline-reachable backups remain the difference between a bad week and a business-ending event, regardless of how the endpoint defenses were bypassed.

Patch the access points attackers use to get admin rights in the first place. Exposed RDP, unpatched VPN appliances, and weak or reused credentials remain the most common way ransomware crews get the foothold this whole technique depends on.

Most of this is configuration and process work, not new spend. It gets missed not because it's exotic, but because nobody owns the question: who can reboot our servers into Safe Mode, and would we notice?

When prevention isn't enough

No control set is airtight, which is why detection and response matter as much as prevention. In one engagement with a venture-backed technology company that had no dedicated security hire, our team found and remediated hundreds of cloud misconfigurations across AWS and GCP, brought endpoint coverage to 100%, and contained an active intrusion in progress. You can read the details in our case study.

The pattern holds regardless of the specific ransomware technique: gaps compound quietly until someone with admin-level access finds them.

If you're not confident your organization would catch a forced Safe Mode reboot, or you're not sure who currently holds local admin rights across your fleet, a penetration test is the fastest way to find out where the real gaps are. And if ransomware does hit, having an incident response plan and partner in place before it happens is what turns a crisis into a contained event.

For general guidance on ransomware readiness, CISA's #StopRansomware resources are a solid public reference.

We favour fixing issues over flagging them. Every finding we surface gets verified as remediated, not just logged. If you want a clear view of where your organization stands, start with a free security review. It's a straight answer on where you're exposed.

Originally published at https://www.sheersafe.com/insights/ransomware-safe-mode-kill-edr

What VCs Look for in a Security Review Before Funding

Sheer Safe — Fri, 14 Aug 2026 15:13:14 +0000

During technical due diligence, VCs are mainly checking three things: how your cloud environment is configured, who has access to what, and whether you've had (and handled) any security incidents.

Founders who look at these before the data room opens tend to face fewer surprises and a shorter back-and-forth once diligence starts. Founders who skip it often get a term sheet with a security condition attached, or a delay while questions get answered mid-process. A breach or a sloppy AWS account six months after a Series A becomes the fund's problem too. Diligence is how they try to price that risk before it's theirs.

Cloud configuration: are the basics actually in place?

Most growing companies run on AWS, GCP, or Azure, and most technical due diligence starts there. Investors, or the firm they hire, aren't hunting for a perfect environment. They want evidence that someone owns it.

Are storage buckets and databases public by accident? Is there a single AWS root account with no multi-factor authentication (MFA), used day-to-day? Are logging and monitoring switched on, or is there no record of what happened last week, let alone last year? Is production separated from staging and development?

In one engagement with a venture-backed technology company, a cloud security review across AWS and Google Cloud Platform (GCP) surfaced more than 900 findings on the AWS side and led to over 580 remediated on GCP. Those two numbers aren't directly comparable — one is findings identified, the other is findings actually closed out — and the raw counts matter less than what they contained: a mix ranging from minor misconfigurations to a smaller number of more serious exposures that needed fixing quickly. Nobody had reviewed that particular environment end to end with a security lens before.

That result is specific to that one company; it isn't a benchmark for what any other startup's environment looks like, and a much smaller or larger number elsewhere wouldn't mean much on its own. What matters to an investor is whether you're finding and fixing issues like this proactively, or whether they're the ones who find them first.

Access controls: who can touch what, and why

The second thing diligence teams probe is identity and access. This is less about tooling and more about discipline.

Do former employees and contractors still have active credentials? Is there a shared admin login that three people know the password to? Can engineers reach production databases directly, with no approval trail? Is there any separation between who writes code, who deploys it, and who can change security settings?

Investors read weak access control as a signal about company maturity generally, not just security. If nobody has ever asked who can do what and why, other operational basics probably haven't been asked either.

Most of this is something a founder or lead engineer can fix directly, without hiring anyone: revoke access for anyone who's left, replace shared logins with individual accounts, turn on MFA everywhere it's missing, and add a basic approval step before anyone touches production.

What usually does need outside help is the deeper work — mapping every service account and permission across a growing cloud footprint, and setting up the ongoing process so access doesn't quietly drift back to the same state a year later. That's the part that tends to get skipped when there's no dedicated security person watching it.

Incident history: what happened, and how you handled it

Every serious investor will ask, directly or via a questionnaire, whether you've had a security incident. The honest answer matters far less than how you answer it.

A founder who says "yes, we had an intrusion attempt, here's what we found, here's what we contained, here's what changed afterward" sounds in control. A founder who says "no, never," with no monitoring in place to actually know that, sounds unaware rather than lucky.

In the same engagement referenced above, an active intrusion was identified and contained during the course of the work, alongside achieving full endpoint detection and response (EDR) coverage across the company's devices. That's the kind of specific, documented outcome that's easy to describe in a diligence call — a lot more useful than a general assurance that "security is a priority."

If you've genuinely never had an incident because you've never had visibility to detect one, that's worth addressing before diligence starts, ideally through ongoing monitoring rather than a one-time check, so the answer to "have you had an incident" is one you can actually back up.

What actually counts as a dealbreaker

Founders often assume that finding problems during a pre-raise review is itself the risk. In practice, it's usually the opposite: a review that turns up real issues, paired with evidence you fixed or are actively fixing them, tends to read as a company that takes this seriously.

Most investors expect a growing company's environment to have gaps. What they're gauging is whether those gaps are known and being worked on, or invisible.

What tends to actually concern an investor is different: findings that were known about and left unaddressed for a long time with no plan, inconsistent or evasive answers about an incident, or no one on the team who can credibly explain what happened and what changed.

Serious issues discovered by your own review before diligence, with a remediation plan and a timeline attached, are a far better position than the same issues being found by someone else's diligence team mid-process.

How to walk in prepared, not scrambling

The founders who handle this well don't do anything exotic. They just start earlier, before there's a deadline forcing the pace.

Run an independent review well before you expect to be in active fundraising conversations. A cloud and access review, plus a penetration test of your core application, gives you a documented baseline and enough runway to actually fix what it finds rather than patch it under pressure.
Fix, then verify. A list of findings with nothing closed out looks worse than a shorter list where everything was actually remediated. Verification after the fix matters more than the initial scan.
Write down your incident history honestly, with context. One contained incident with a clear response is a stronger story than a blank "N/A" nobody can back up.
Have someone senior who can speak to the reasoning behind your security decisions, not just an engineer defending code. A virtual CISO (vCISO) can sit in the diligence call and explain the "why," which diligence teams generally find reassuring.

You can see the scope of one engagement like this — cloud review across AWS and GCP, penetration testing, vCISO leadership, and incident containment — in our case study with a venture-backed technology company. For general frameworks on thinking about this systematically, the NIST resources on cybersecurity risk management are a solid public reference point.

FAQ: security due diligence for founders

How early should we start preparing for a security review?
Earlier than most founders expect — before you're in active conversations with investors, not once a term sheet is on the table. Fixing and verifying findings takes real time, and that's harder to compress under deadline pressure.

Will finding problems in our own review hurt us with investors?
Generally no. Investors expect a growing company's environment to have gaps. A documented remediation plan for issues you found yourself is a stronger position than the same issues surfacing later in someone else's diligence.

Can we fix access control issues ourselves, or do we need to hire someone?
The basics — revoking old credentials, enabling MFA, removing shared logins — can usually be done in-house. Mapping permissions across a growing cloud environment and keeping access from drifting back over time is where outside help tends to pay off.

What if we've never had a security incident?
That's only reassuring if you have the monitoring in place to know it's true. Without visibility, "no incidents" is closer to "we don't know" than "we're secure."

Where founders should start

VCs aren't trying to catch you out. They're trying to answer one question: will security slow this company down after we invest?

A cloud environment that's been reviewed, access that's been tightened, and an honest, documented incident history go a long way toward answering that before anyone has to ask it out loud.

If you've got a raise on the horizon and haven't had eyes on this yet, start with a free security review. It's a low-friction way to see where you stand before the data room opens.

For more on related topics like cloud security and vCISO support, browse our insights section.

Originally published at sheersafe.com

What Investors Ask About Security in Due Diligence

Sheer Safe — Fri, 14 Aug 2026 15:11:39 +0000

Investors ask three things above all else: who can access your systems, how your cloud environment is configured, and whether anything bad has already happened. Founders who can answer clearly, with evidence, move through diligence faster and look like a safer bet.

Security questions in a data room rarely feel dramatic. Investors aren't asking for a penetration test report on day one. They're asking simple, pointed questions designed to reveal whether you actually run a tight ship or just say you do. You can prepare answers to almost all of them in advance, without scrambling the week before a term sheet.

Access Controls: Who Can Touch What

This is usually the first bucket investors probe, because it's the fastest way to gauge operational discipline.

Who has admin access to production systems, and why?
Is multi-factor authentication (MFA) enforced, or optional?
Do former employees and contractors still have active credentials anywhere?
Is there a single source of truth for who has access to what (customer data, source code, cloud accounts, financial systems)?

The underlying question is simple: if something goes wrong, could you say with confidence who had the ability to cause it? Most founders can answer this in principle but haven't documented it. That gap is what slows diligence down, not the underlying reality.

Cloud Posture: How Your Infrastructure Is Actually Configured

Almost every early-stage company runs on AWS, GCP, or Azure, and investors know misconfigured cloud environments are one of the most common sources of real breaches. Expect questions like:

Are storage buckets and databases publicly accessible by default, or locked down?
Is there a written policy, even a short one, for how cloud accounts are provisioned and reviewed?
How is sensitive data (customer records, credentials, keys) stored and encrypted?
Has anyone independent ever reviewed the environment, or has it only ever been self-assessed?

In one engagement with a venture-backed technology company, a cloud security review across AWS and GCP (Google Cloud Platform) surfaced over 900 AWS findings and led to remediation of 580+ GCP issues. That kind of accumulated technical debt is normal for a fast-growing company, and it's exactly what a diligence process is designed to surface.

The company had never had an independent review before; once it did, the findings were fixed rather than left as a list. That's the difference investors are actually looking for: not a perfect environment, but evidence that issues get found and closed.

You can read the full story in our technology company case study. If you haven't had your cloud environment independently reviewed, our cloud security service and penetration testing service are both built to produce this kind of evidence: a clear before-and-after, not just a report that sits in a drawer.

Incident History: What's Already Happened

Investors aren't expecting a spotless record. They're expecting honesty and a demonstrated ability to respond.

Has there been a security incident, breach, or intrusion, however minor?
If so, how was it detected, contained, and communicated?
Is there a written incident response plan, or would the team be improvising?
Do you have endpoint detection and monitoring in place today, or only after the fact?

In that same engagement, one active intrusion was identified and contained as part of the work, alongside achieving full endpoint detection and response (EDR) coverage across the company's devices.

Founders sometimes worry that disclosing a past incident will scare investors off. In practice, a well-handled incident, one that's documented, contained, and learned from, is usually reassuring. What damages confidence is discovering an incident that was never disclosed, or a team with no plan for the next one.

Our incident response service and managed security service exist to make sure you have both the plan and the ongoing coverage before you ever need to explain it to an investor.

Prepare Before the Data Room Opens

The founders who move fastest through security diligence aren't the ones with flawless infrastructure. They're the ones who did the work before the questions arrived.

Get an independent review now, not during diligence. A cloud and access review a few months ahead of fundraising gives you time to fix things quietly, rather than explaining them under pressure.

Write down your access policy. Even a one-page document, covering who gets access, how it's granted, and how it's revoked, answers most of the access questions before they're asked.

Have an incident response plan on paper. It doesn't need to be elaborate. It needs to exist and be something your team has actually read.

Assign ownership. If no one on your team owns security full-time, a fractional or virtual Chief Information Security Officer (CISO) can hold that role through diligence and beyond, so there's always someone with an answer in the room. Our virtual CISO service is built for exactly this stage of company.

Treat compliance groundwork as leverage, not paperwork. Even before you pursue a formal framework, having basic controls mapped and documented (our compliance support can help here) speeds up every future diligence process, not just this one.

The goal isn't to eliminate every finding before an investor looks. It's to be the founder who already knows what the findings are, has a plan for them, and can say so plainly. That's the posture that tells investors how you'll run the company, more than any single control ever could.

For general best-practice guidance on securing cloud environments, CISA (the Cybersecurity and Infrastructure Security Agency) is a solid, free reference point.

If you're heading into fundraising and want a clear view of where your gaps are before an investor finds them, start with a free security review. It's a quick way to know exactly what you'd be asked, and to already have the answer.

Originally published at 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.