Surviving cybersecurity until the end of 2026

Make stolen credentials useless

We've seen how much damage stolen credentials cause in the hands of attackers, so limiting the blast radius once a credential is exposed is paramount. Most teams haven't planned for the scenario where their credentials actually get stolen. Starting from the assumption that they will be exposed makes it easier to put the right compensating controls in place.

In practice, that means:

• Use short-lived tokens or just-in-time (JIT) access, so a service or person only has access to a secret for as long as the task requires. If that credential is compromised, it's already close to expiring or has expired.
• Keep scopes tight. If a service only needs read access, don't give it write access too.
• Make three-factor authentication standard on every tool. Enable 2FA anywhere you can. For example, require 2FA on GitHub and add IP restrictions.
• Audit your applications for any API keys and tokens that have been issued. Assess what they're being used for. Make sure you understand their scope. Revoke what's not needed or use the audit to outline a plan for credential rotation.

Secure the code you didn't write

PHP2Shell made it painfully clear how much risk lives in the code you inherit. Base images and open source libraries arrive with their own baggage, and so do the runtimes underneath them. You become responsible for all of it the moment it enters your estate. You can't avoid inheriting code, but you can choose what you inherit and how.

In practice:

• Start with minimal container images. They include far fewer packages than standard images, which means a smaller attack surface and fewer CVEs by default.
• Pair minimal images with a vendor for hardened container images, so any CVE that does appear gets fixed quickly.
• Fork or mirror libraries internally and consume them from your own feed.
• Use hardened libraries for end-of-life dependencies, or wherever you need extended lifecycle support with backported security fixes.
• Know what's end of life by checking your estate for versions that aren't maintained anymore.
• Use software composition analysis (SCA) to track every open source dependency, including transitive ones, and to report and fix the vulnerabilities it finds.
• Patch when critical disclosures come out. Exploits now follow disclosure within days.

Remove vendors you don't need

Vendor sprawl is real, and every vendor you bring into your organization poses a risk if it isn't managed well. That GitHub plugin you installed last year and only used once? That's a risk. So is the npm dependency you installed for a project you've since moved on from. Vendors include anyone whose code or services run within your estate, from companies you pay to open source maintainers.

In practice:

• Build a well-managed inventory of every application, plugin, integration, and service across your estate.
• Remove third-party vendors where feasible. For the ones you keep, mirror or proxy their services through your own artifact feed.
• Keep IDE extensions and plugins to a minimum.
• List every OAuth grant, GitHub App, personal access token, and connected SaaS integration, and revoke the ones you don't use.
• Assess each vendor before onboarding it. Ask who maintains it and what access it needs, and check whether something you already run does the same job.
• Offboard vendors promptly once a project ends or a contract lapses.
• Add vendor breach scenarios to your incident response plan and test them. Assume one of your vendors gets breached, then walk through how your team reacts.

Take offline what doesn't need to be online

PHP2Shell showed that teams need to justify every service they keep online, and to find what's running across their estate quickly.

That forgotten web server from 2019, the one that was "only supposed to be running for some internal dev work," is exactly the kind of unpatched compute attackers target. Teams often don't learn it exists until it's too late.

In practice:

• Audit your estate, including your external attack surface, and build an inventory of every running service and system.
• Scrutinize that list and be ready to defend why each item is running.
• Make resources accountable by tagging each one with an owner and a purpose. Label environments too, and enforce tagging by policy.
• Keep systems off the public internet unless they need to be there. Put internal tools behind a VPN or zero-trust access.
• Rehearse your patching process well, so you're ready when critical disclosures drop.
• Use auto-shutdown schedules so compute is only online when it's needed. A dev Kubernetes cluster you only use on Tuesdays can shut down for the rest of the week, and it'll cut your bill too.

Control what runs on user machines

Malware attacks against devices are increasing, and in a single week Aikido blocked nearly 500 of them. Developer machines make a juicy target because they hold credentials and access to systems that are sometimes critical. The sections above cover how to limit what those credentials can do, and controlling what actually runs on developer machines shrinks the attack surface further. The Vercel breach this year also showed us how a single browser extension can lead to an incident.

In practice, that means:

• Audit user machines and build an inventory of the installed software and versions, including browser extensions, IDE extensions, MCP servers, and AI tools.
• Block installs of new plugins and extensions until they've been approved.
• Maintain an allowlist so people don't have to wait for the common ones.
• Enforce a minimum package age, or cooldown. Most malicious packages get detected within a few hours, so a cooldown reduces the risk of installing a malicious version.
• Keep secrets off disk. Infostealers look first at plaintext tokens in .env files and shell history. Secrets managers and short-lived tokens are your friends here.

Attack yourself first

"Check yourself before you wreck yourself" is solid security advice. Pentest your network and automate adversary testing across the services you own, so you find the holes before someone else does.

Fixing a leak before it turns into a flood sounds obvious, but do you actually do it? Automated tools make it easier. In practice:

• Deploy attack surface management (ASM) tools across your estate so you know what's exposed, including the things you forgot you had.
• Run external network pentests routinely, not just once.
• Continuously test apps that ship often, instead of treating testing as a once-a-year tickbox.
• Assume breach with tabletop exercises, and test what an attacker could actually reach from a compromised machine or CI runner.

Full checklist

Get your team ready one step at a time.

This week

• Search developer machines for cloud credentials, SSH keys, API tokens, and .env files.
• Set a minimum package age of at least 48 hours for every package manager you use, including npm and PyPI.
• Start blocking malware at install time with Aikido Safe Chain.
• Check what's reachable from the internet and take offline anything that doesn't need to be there.

This month

• Move production secrets off laptops into a secrets manager, and rotate any credentials you found on developer machines.
• Audit dependencies and remove unused or unmaintained ones.
• Build a vendor inventory that covers your apps, plugins, dependencies, and services, and give each one an owner.
• Set auto-shutdown schedules for non-production compute.
• Remove local admin rights on user machines where feasible.
• Run AI Code Analysis on internet-facing code and on code that handles authentication or payments.
• Store identity provider, cloud audit, source control, and CI logs somewhere production credentials can't delete them.
• Set a patch target for critical internet-facing vulnerabilities, measured in hours or days.

Before the end of 2026

• Deploy attack surface management across your whole estate.
• Run an external network pentest, and book the next one for 2027.
• Run tabletop exercises that assume a breach through a compromised vendor, developer laptop, CI runner, or package.
• Run an end-of-year review of all your vendors and service inventories, so every item has an owner going into 2027.

For more, see software supply chain security best practices.

Conclusion

New CVEs and compromised packages will keep coming through the end of the year and well beyond it. Assume you'll be affected at some point, and make sure you're in the strongest possible position when it happens. Teams that limit what a single compromise can reach will contain the next incident faster than teams that rely on blocking every entry point.

For a longer view, read PHP2Shell, the day after tomorrow.