End-users are responsible for 75% of internal data-loss incidents, most of them accidental rather than malicious. For a dev team, that risk concentrates on the endpoint, the machine where code gets written, tested, and pushed.

Here's how to build a strategy that protects that machine without slowing your team down.

Table of Contents

• How to Build an Endpoint Data Loss Prevention Strategy

  • Step 1: Map Where Sensitive Data Lives in the Endpoint

  • Step 2: Set Access Control as the Foundation

  • Step 3: Harden the Endpoint OS Layer

  • Step 4: Lock Down Containers and Local Environments

  • Step 5: Catch Leaks Before They Ship

  • Step 6: Extend Coverage to Public-Facing Surfaces

  • Step 7: Monitor, Measure, and Keep Policies Honest

• Build Security Into How Your Team Already Works

How to Build an Endpoint Data Loss Prevention Strategy

Step 1: Map Where Sensitive Data Lives in the Endpoint

Start by finding out where secrets and sensitive data sit across your team's machines. Likely candidates are things like config files with hardcoded credentials, .env files that never made it to .gitignore, and cached database dumps from a debugging session six months ago that nobody remembered to delete.

Anything that qualifies as a backup, even an ad hoc one, should be treated as sensitive data in its own right. So if the backup encryption isn't in place, that copy is just as vulnerable as the original source of data.

Most teams are surprised by what turns up once they start looking. A short audit across a handful of laptops usually reveals the same handful of habits repeating across a whole team, since one developer's shortcut tends to spread once it works one time.

A simple spreadsheet tracking what kind of sensitive data lives where and on which machines gives the rest of this strategy something concrete to build on. Skip this step and every control that follows ends up guessing at what it's supposed to be protecting.

Try this first:

1. Choose three to five developer machines to begin your initial audit.

2. Search typical locations for environment files, credentials, database dumps, and private keys.

3. Record the finding, file location, data type, owner, and note if the data is still needed.

4. Remove unnecessary copies and update credentials that might have been exposed.

For a Linux machine, a basic first pass could look like:

find ~ -type f \( -name ".env" -o -name "*.pem" -o -name "*.key" \) 2>/dev/null

This approach won't uncover every secret, but it gives your team a solid starting inventory.

For example, if the audit finds ~/projects/client-api/.env containing a database password, you need to move the credential to a secret manager, delete the local file, and update the password.

Step 2: Set Access Control as the Foundation

Every endpoint DLP strategy sits on top of a working access control system. If every developer can pull production credentials regardless of their role, no amount of monitoring downstream will fix that gap.

Scalable access control that's built around roles and attributes limits what a compromised laptop can expose in the first place. After all, a stolen set of credentials only matters as much as the permissions attached to them.

This is also the cheapest control on this whole list to get wrong, and one of the easiest to fix.

Reviewing who has access to what on a recurring schedule rather than once at onboarding will catch the slow creep of permissions that no one remembered to revoke after a project ended.

A simple implementation process:

1. List production systems and sensitive resources.

2. Create roles such as developer, senior developer, DevOps, and administrator.

3. Document which resources each role actually needs.

4. Remove permissions that don't support someone's current work.

5. Review access whenever someone changes projects or leaves the team.

The difference between too much access and appropriate access is easier to see side by side. Here's the same developer role, granted two different ways in Postgres.

Too much access:

-- One role, every database, every table, every operation 

GRANT ALL PRIVILEGES ON DATABASE prod_db TO dev_team; 

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO dev_team; 

Appropriate access:

-- Full access where the work actually happens 

GRANT CONNECT ON DATABASE staging_db TO dev_team; 

GRANT USAGE ON SCHEMA public TO dev_team; 

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO dev_team;

-- No standing connection to production at all 

REVOKE ALL ON DATABASE prod_db FROM dev_team; 

The same idea maps cleanly onto a role table, which is usually the easier version to hand to a team:

For example, a developer should have read and write access to the development and staging databases since those environments are part of their regular work. They shouldn't have direct access to the production database. A DevOps team member may need controlled production access for deployment and troubleshooting, with that access limited to the tasks they're responsible for.

Step 3: Harden the Endpoint OS Layer

Most development machines run some flavor of Linux, whether directly or through WSL, and the operating system layer is where a lot of DLP controls end up getting enforced day to day: file permissions, disk encryption, and keeping user privileges properly separated.

Getting comfortable with core Linux commands makes it a lot easier to audit what's running on a machine, lock file permissions down the right way, and catch something out of place before it turns into a real problem.

Disk encryption also deserves a mention here. Steal a laptop with an unencrypted drive, and everything on it just hands itself over, no password needed, the moment someone pulls the disk and mounts it somewhere else.

Turn on full-disk encryption, and that same stolen laptop becomes a much smaller headache.

For Linux developers, here are a few commands you can run during an endpoint review:

whoami 

sudo -l 

ls -la ~/.ssh 

df -h 

These commands can help identify the current user, available sudo privileges, SSH files, and disk usage.

File permissions are where this gets specific. A secret sitting in a world-readable file is available to every process and every account on that machine, which quietly cancels out the access control work from the previous step.

Check what the permissions actually are before changing anything:

ls -la ~/.ssh

find ~/projects -name ".env" -exec ls -l {} \;

Output worth acting on looks like this:

-rw-r--r--  1 dev  staff  1704  Mar 12 09:14 /home/dev/.ssh/id_ed25519

-rw-rw-r--  1 dev  staff   612  Mar 12 09:14 /home/dev/projects/client-api/.env

Those trailing r-- bits mean group members and every other user on the box can read a private key and a set of credentials. Tighten them so only the owner can access:

chmod 700 ~/.ssh              # directory: owner only

chmod 600 ~/.ssh/id_ed25519   # private key: owner read/write

chmod 644 ~/.ssh/id_ed25519.pub

chmod 600 ~/projects/client-api/.env

To sweep a whole projects directory at once:

find ~/projects -name ".env" -exec chmod 600 {} \;

Then give the actual hardening sequence:

1. Enable full-disk encryption.

2. Keep the OS and security updates current.

3. Remove unnecessary administrator privileges.

4. Review SSH keys and remove unused ones.

5. Enable screen locking.

6. Configure endpoint monitoring where appropriate.

   For example, if a developer's laptop has an old SSH key belonging to a previous project, remove it and revoke the corresponding access rather than leaving it available indefinitely.

Some teams sidestep this risk at the source by moving development onto a virtual desktop infrastructure, where sensitive data lives centrally rather than on the physical machine. But this just relocates the DLP burden rather than removing it, since the virtual environment itself now needs the same access controls and monitoring to protect VMs from data loss.

Step 4: Lock Down Containers and Local Environments

Local development increasingly happens inside containers, and each one is a small self-contained environment that can end up holding secrets if developers aren't careful about what gets stored in it.

A .env file might get baked into an image or credentials might sit in a container's environment variables long after a project wraps up.

Learning to work properly with Docker includes understanding how to keep secrets out of images entirely, using secret managers or runtime injection instead of hardcoding anything into a Dockerfile.

Here's a Dockerfile that looks perfectly straightforward and leaks in two different ways:

FROM node:20
WORKDIR /app
# Problem 1: copies everything, including .env, *.pem, and .git history
COPY . .
# Problem 2: the value is written into an image layer, permanently
ENV DB_PASSWORD="prod-9f2a-4c11-secret"
RUN npm install
CMD ["node", "server.js"]

Deleting the file in a later layer doesn't help, because the earlier layer still contains it. Anyone who pulls the image can read both:

docker history --no-trunc my-app:latest | grep -i password

docker run --rm -it --entrypoint sh my-app:latest -c "cat .env"

The corrected version starts with a .dockerignore, which keeps the sensitive files out of the build context entirely:

# .dockerignore

.env

.env.*

*.pem

*.key

.git

node_modules

Then copy only what the application needs and leave credentials out of the image:

FROM node:20

WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
# Copy application code only, not the whole directory
COPY src ./src
CMD ["node", "src/server.js"]

Supply the credential at runtime instead:

docker run -e DB_PASSWORD="$DB_PASSWORD" my-app:latest

Practical check: Before pushing an image, scan it for .env files, private keys, credentials, and other sensitive data.

Step 5: Catch Leaks Before They Ship

If you catch a leak early, it might cost you less loss.

Wire automated secret scanning into a CI/CD pipeline, and a hardcoded API key gets flagged before it ever reaches a public repository.

Gitleaks and TruffleHog both handle this well by running right in the pipeline and failing the build as soon as a potential credential is detected in a commit.

Tuning the alerting properly takes some patience, but skipping that step tends to backfire. A scanner that keeps crying wolf with false positives encourages a team to click past every warning without even reading it. So, it's worth spending the setup time getting the rules to fit your codebase properly.

For example, a GitHub Actions workflow can run Gitleaks before code reaches production:

name: Secret Scan

on:

  pull_request:

  push:

jobs:

  gitleaks:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v4

        with:
          fetch-depth: 0

      - uses: gitleaks/gitleaks-action@v2

With this setup, the repository gets scanned whenever developers push code or open a pull request. If Gitleaks detects a potential credential, the workflow can stop before the change moves further through the deployment process.

A caught secret shows up in the workflow log looking roughly like this:

Finding:     AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI...
Secret:      wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
RuleID:      aws-access-token
Entropy:     4.31
File:        services/billing/.env.staging
Line:        12
Commit:      8f2a1c9dbe4477a1c0f9e2b3a5d7c8e1f0a2b3c4
Author:      dev@example.com
INF 14 commits scanned.
WRN leaks found: 1
Error: Process completed with exit code 1.

The non-zero exit code is what actually blocks the merge. The file name, line number, and commit hash tell whoever picks it up exactly where to look.

Tuning the alerting properly takes some patience, but skipping that step tends to backfire. Again, you don't want constant false positives causing your team to click past every warning without looking at it. So take the time to get the rules to fit your codebase.

That tuning happens in a .gitleaks.toml at the repository root, where you exempt the paths that legitimately contain fake credentials:

[extend]
useDefault = true

[[rules]]
id = "aws-access-token"
  [rules.allowlist]
  paths = [
    '''tests/fixtures/.*''',
    '''docs/examples/.*'''
  ]
  regexes = [
    '''AKIAIOSFODNN7EXAMPLE'''
  ]

Keep the allowlist narrow. Exempting a whole directory because one file in it kept tripping the scanner is how real credentials start slipping through.

For example, a developer accidentally commits an API key to a pull request. Gitleaks flags it during the workflow, the pull request can't proceed, and the team removes the key and rotates the credential before merging the code.

Step 6: Extend Coverage to Public-Facing Surfaces

Most endpoint DLP strategies focus on laptops and dev machines, but public websites need the same scrutiny, even when they're maintained outside the engineering team.

You might have a poorly configured contact form, a staging subdomain someone forgot was still live, and an admin panel nobody locked down properly. An ⁠API security testing platform can test exposed APIs for vulnerabilities and business logic flaws before they put sensitive data at risk. Any one of those can leak data just as easily as a careless commit ever could.

Part of the problem is that web design and security often get treated as separate jobs handled by separate people. Sites built with hosting, maintenance, and security combined into the process from the start hold up far better than ones where those pieces get tacked on after something goes wrong.

This kind of ongoing oversight matters for a public-facing site the same way endpoint monitoring matters for a developer's machine. Unattended surfaces are where problems tend to build up slowly, unnoticed, until something forces a closer look.

If your dev team owns the marketing site too, treat it as a part of the same DLP scope, handled with the same routine attention as everything else, rather than something someone gets to whenever there's some spare time.

A simple monthly check can catch these issues before they become forgotten infrastructure. Start by listing every active domain and subdomain, then check whether each one still needs to be publicly accessible.

Here's how that usually plays out in practice. A team ships a customer portal rewrite and spins up staging-v2.example.com to demo it to stakeholders. The launch goes fine. Nobody deletes the staging environment, and it keeps running on a copy of the production database that was loaded for the demo.

Eight months later, a routine subdomain sweep turns it up:

# Every subdomain still resolving
dig +short staging-v2.example.com
203.0.113.47

# Is it publicly reachable, and does it need auth?
curl -s -o /dev/null -w "%{http_code}\n" https://staging-v2.example.com/api/v1/customers
200

A 200 with no credentials attached is the problem. Pulling the first record confirms it:

curl -s https://staging-v2.example.com/api/v1/customers | head -c 200
[{"id":4471,"email":"real.customer@example.com","phone":"+1-555-0142",
"plan":"enterprise","last_invoice":"2025-11-03"}]

That's production customer data sitting on an unauthenticated endpoint, indexed by anyone scanning certificate transparency logs for subdomains. The fix has an order to it:

1. Take the environment offline immediately, before anything else.

2. Check access logs to see if anyone else found it first.

3. Decide whether the environment is still needed. If not, delete it and remove the DNS record.

4. If it's needed, put it behind authentication or an IP allowlist and replace the database with generated test data.

5. Add every subdomain to the monthly inventory so the next one doesn't sit unnoticed for eight months.

Keep the same review for public forms, admin panels, cloud storage, and unused API endpoints. The goal is to make every internet-facing surface something the team knows about and actively maintains.

Step 7: Monitor, Measure, and Keep Policies Honest

A DLP strategy without measurement isn't a good strategy. Teams need visibility into where data exposure is showing up in practice, the same way marketing teams have started tracking brand visibility across AI platforms.

For insurance, Similarweb’s AEO platform built for that purpose tracks where and how a brand gets mentioned across AI-generated answers, catching patterns nobody would ever spot by checking one prompt at a time by hand.

Security monitoring for endpoints runs on that same idea. Without a dashboard showing where secrets are exposed or which machines have drifted out of compliance, a team spends its energy cleaning up after incidents instead of catching them early.

The same principle applies to backups: an untested backup is merely an assumption. Regularly testing your disaster recovery plan ensures that your data backup strategy works properly when issues arise.

That principle doesn't stop at the laptop, either. Most companies store sensitive data across Microsoft 365 (mailboxes, SharePoint sites, OneDrive folders, or Teams channels) and it's usually the dev or IT team's job to make sure that data is actually protected, not just retained.

Microsoft's native retention covers accidental deletion within a short window. It isn't built to recover from ransomware or a compromised account that goes unnoticed for weeks. Teams relying on that retention alone, without an independent backup for Microsoft 365 data, are making the same unverified assumption this article already warns against with local backups.

Policy matters here just as much as any of the tooling does.

A policy only works if the people bound by it actually believe in it, and that part is harder to measure than tooling compliance. This is where an anonymous employee confidence tool earns its place, showing whether a team genuinely trusts a security rule or is just quietly routing around it.

Security policies have a similar challenge. Vague one-size-fits-all rules dropped on a team without context can be difficult for developers to follow in practice. Give a team a policy nobody understands and eventually they'll build a workaround for it, regardless of how well-meaning it was when someone wrote it.

Rules that are specific and come with a clear explanation tend to hold up better than a generic PDF buried three folders deep in onboarding.

A security dashboard simplifies the review process. Track the number of secrets detected, endpoints outside required controls, permission changes, and resolution times for each issue.

For a team of twenty developers, that dashboard doesn't need to be more complicated than this:

Two things stand out immediately in a table like that, and neither would be obvious from an incident report.

1. Secrets are getting caught in CI instead of after merge, which means step 5 is doing its job.

2. Patching is going backwards, which means something in the update process isn't working and another reminder email is unlikely to fix it.

For example, if you see that a secret scanner detected an AWS credential in a pull request, stop the merge, revoke or rotate the credential, remove it from the repository, and check for its presence elsewhere. Investigate why the credential was accessible to the developer and update the workflow to prevent recurrence.

Make sure to monitor these metrics regularly instead of waiting for an incident. If the same violations continue, consider implementing clearer policies, improved tools, or a streamlined development process rather than issuing additional warnings.

Build Security Into How Your Team Already Works

A strong DLP strategy doesn't mean slowing engineers down with endless approval steps or locking every laptop into a rigid corporate image, and it shouldn't come at the cost of customer experience either, since the whole point of shipping fast is to serve users well without exposing their data in the process.

The strongest endpoint DLP strategies just run in the background, mostly invisible day to day: access control keeping blast radius small, CI/CD checks catching mistakes before they ship, and monitoring pointing a team toward its real gaps instead of leaving everyone to guess.

Start with access control and CI/CD, since those two catch common mistakes with minimal friction, and build outward once that foundation is solid.

Picking up suitable tools, including the best backup software, behind each of these steps makes the whole thing far easier to build and keep running over time.

Anyone looking to strengthen those foundations, whether that's Linux fundamentals, containerization, or CI/CD pipelines, will find free and practical guides covering precisely this kind of work over at freeCodeCamp.

This has always been an issue in vulnerability management. While a security team might find out about the vulnerable dependency, fixing it may not always be possible at once. Developers need to ensure that the vulnerable code is in use and perform all necessary checks before releasing the fix into production.

Recently, though, there have been some solid advancements in the use of AI for discovering software vulnerabilities and exploits. This research, for example, details some of the findings and the path forward.

But how will this really help the development community? We need to fix things more quickly, but more importantly, we need to be able to figure out which vulnerabilities actually matter and which ones need attention first.

In this article, we'll examine what the classic patching process looks like, how AI is decreasing the amount of time security teams have to react, and why it's not always reasonable just to address vulnerabilities by their severity score.

We'll also discuss exposure management and the difference between it and traditional vulnerability management. Then we'll cover how developers can analyze dependencies, code reachability, and Software Bill of Materials (SBOMs) to figure out the actual vulnerabilities in their applications.

What We'll Cover:

• Patching vs. Exposure Management: What's the Difference?

  • What Is Patching?

  • What Is Exposure Management?

• The Old Patch Management Workflow Was Built Around Time

• AI Is Shrinking the Time Between "Found" and "Exploited"

• Why "Patch Everything" Doesn't Work at Scale

• Exposure Management: Moving from Flaw Counts to Contextual Risk

• The Dependency Tree as an Attack Surface

• Practical Takeaways for Developers

  • Audit Transitive Dependencies

  • Check Code Reachability

  • Generate an SBOM in CI/CD

  • Use Compensating Controls When a Patch Isn't Ready

  • Apply Least Privilege at Runtime

• Wrap Up

Patching vs. Exposure Management: What's the Difference?

Before we look at how AI is changing vulnerability response, it helps to understand two important concepts: patching and exposure management.

What Is Patching?

Patching is a process of updating software to address an existing issue, including a security vulnerability, bug, or a stability problem. This may involve upgrading a library with a known vulnerability, applying a security update for your operating system, or using a new release of an application with a vulnerability fixed.

For instance, if your application uses a particular library with a known security vulnerability, you can upgrade the library once the patched version is available. After that, you'll need to test the update, ensure that the application still operates as intended, and release the upgraded version into production.

So patching isn't only about installing the latest version of the package in question. A dependency update can break an API, some functionality, or even other dependent packages. That's why teams typically use patch management strategies when identifying vulnerabilities, updating decision-making, testing, deploying, and verifying that the patches work.

What Is Exposure Management?

While vulnerability management is concerned mainly with identifying vulnerabilities, exposure management focuses more broadly on whether those vulnerabilities can actually provide a realistic route for an attack.

For example, a vulnerable library, limited in use to a development system, poses less immediate threat than a similarly vulnerable library used in an internet-facing system that's capable of accessing the database.

Some aspects to consider include accessibility via network, asset exposure, vulnerable code paths, identity and access controls, cloud environments, and the sensitivity of systems and data.

Simply put, vulnerability management is concerned with the discovery and tracking of vulnerabilities, whereas exposure management is focused on determining which of those vulnerabilities pose a true or larger risk.

The Old Patch Management Workflow Was Built Around Time

The classic process of vulnerability mitigation depended on step-by-step actions.

1. CVE discovered

2. Security team assesses the severity

3. Maintainer releases an upstream patch

4. Developer updates the dependency

5. CI/CD pipeline runs regression tests

6. Production deployment

7. Remediation verified

The process wasn't flawed by nature, but it operated under the unspoken premise that the defenders were granted enough room to operate through each step.

Let's take a dependency vulnerability example for practice. If the automated scanner detects a vulnerability within a popular utility package such as lodash, engineers don't immediately bump the dependency version in the production environment. They need to confirm if the application code leverages the vulnerable function, check the presence of breaking API changes after the upgrade, and run build validation through integration tests.

Each security patch is essentially a change to the code and needs to be safely pushed through the development and deployment cycle.

AI Is Shrinking the Time Between "Found" and "Exploited"

The buffer between vulnerability discovery and exploitation that used to exist is being eliminated. This is because automated programs can scan through codebases, generate proofs of concept, and discover edge cases.

Modern AI systems help researchers and would-be attackers alike perform tasks like static binary analysis, detecting vulnerabilities, creating exploit payloads, and finding logical issues in complicated software designs.

Programs such as DARPA’s Artificial Intelligence Cyber Challenge (AIxCC) show how AI systems can be used to automatically find and patch vulnerabilities in complex open-source software. During the 2024 semifinal competition, autonomous Cyber Reasoning Systems were tested against projects based on real-world software such as Jenkins, the Linux kernel, Nginx, SQLite3, and Apache Tika. The systems discovered 22 unique synthetic vulnerabilities and successfully patched 15 of them. They also identified one real-world bug in SQLite3, which was responsibly disclosed.

In the context of a real development process, certain tasks in the patching process can be performed by AI. The AI could perform code analysis and dependency analysis in order to detect potential vulnerabilities. It could also help trace the usage of vulnerable functions, recommend changes in code and dependencies, and generate tests to make sure that the suggested patch doesn’t break the existing functionality. The security team could also use AI for pattern detection.

As AI tools get better at assessing software and detecting vulnerabilities, the window of time between vulnerability detection and its mitigation becomes smaller and more important. This change in paradigm also affects how security professionals approach AI and exposure management, especially as the exploit window gets smaller and vulnerabilities need proper prioritization.

AI can also support exposure management by connecting vulnerability information with the environment in which the vulnerable software is running. For example, an AI-assisted security system could correlate a vulnerable dependency with an internet-facing application, its network connections, cloud permissions, and the data or services it can access. This helps security teams move from simply asking whether a vulnerability exists to asking what an attacker could realistically reach through it.

Why "Patch Everything" Doesn't Work at Scale

When an organization-wide scanner generates a list of 500 vulnerabilities spread across multiple microservices, reacting to each one with urgency starts to seem impossible. Developers can suffer from alert fatigue and get overwhelmed pretty easily.

The Common Vulnerability Scoring System (CVSS) is a standardized framework used to describe the severity of a vulnerability. CVSS v3.1 uses the following severity ranges:

CVSS is useful because it provides both developers and security teams with a common language that describes the severity of a vulnerability. Nevertheless, the rating describes the vulnerability but not the environment where this vulnerability appears. In other words, CVSS doesn't tell you if the functionality used by the vulnerability is really used by your application or if the affected system is exposed to the Internet.

To see why CVSS alone isn't always enough, let's say we have two hypothetical vulnerabilities in an organization's environment:

• Vulnerability A: This critical remote code execution vulnerability is part of an isolated testing harness or development-only dependency that's never included in the production environment and doesn't have any external network accessibility.

• Vulnerability B: A high-severity input validation vulnerability is found in an internet-facing API gateway that processes malicious user input and has access to a backend database with customer information.

Looking at just the CVSS score would require the team to focus on Vulnerability A before Vulnerability B. But it's clear that Vulnerability B poses the greater threat to operations. Security studies show us that very few vulnerabilities get exploited once they're known. Telemetry data from the CISA KEV Catalog clearly indicates that attackers focus on a subset of vulnerabilities that have a real path of exploitation.

In reality, teams must consider the CVSS score in addition to many contextual factors when deciding what to fix. A particular vulnerability might have a higher priority if the following conditions are true:

• it has an impact on an internet-facing production system,

• there's a known exploit for the vulnerability,

• there's sensitive information exposed,

• it impacts an important business function,

• or it offers an attacker a means of gaining access to other privileged systems.

But vulnerabilities that occur only in development or are inaccessible for some reason likely don't need to be fixed immediately.

The most appropriate method for determining the importance of vulnerabilities is asking some straightforward questions: Is the vulnerable system accessible? Is the vulnerable code accessible? Is there any exploit for this vulnerability? What privileges does the affected service have? What will an attacker be able to access after exploiting the vulnerability?

Assigning the same level of priority to all alerts wastes engineering efforts on vulnerabilities that might pose no or little risk at all.

Exposure Management: Moving from Flaw Counts to Contextual Risk

Exposure management shifts focus from simply cataloging static vulnerabilities to evaluating an organization's actual operational risk posture.

Instead of asking "How many CVEs exist in our repositories?", exposure management asks "Which vulnerable components, misconfigurations, and reachable network paths create exploitable risk across our running assets?"

The difference becomes easier to see when you look at what each approach focuses on:

When there are 10,000 cloud assets managed by an engineering environment and 1,000 vulnerable libraries found through dependency scanners, the combined numbers don't represent the actual security situation. In order to focus on the right level of risks, you should have some knowledge about the context within which each of these vulnerabilities exists.

• Is the container exposed to the internet or is it hidden behind the internal load balancer?

• Is the code actually invoking the risky symbol or library function?

• What are the identity permissions, cloud roles, and databases that are accessible through the vulnerable service?

Having an understanding of this denominator (total numbers of assets that should receive a specific patch) helps teams identify the exposures that are actually threats so that engineering time is spent on solving the problems that impact production data.

The Dependency Tree as an Attack Surface

Modern software delivery depends on multi-layered packages such as npm, PyPI, Maven, NuGet, base operating system layer packages, GitHub Actions, and third-party APIs. The application logic is written by developers, but the final runtime software contains numerous levels of packages:

Your Application Logic → Direct Dependency (Declared in manifest) → Transitive Dependency (Pulled in automatically) → Underlying OS System Packages → Base Container Image / Cloud Runtime.

If a vulnerability is three levels down in the transitive dependencies and the transitive dependency is unmaintained, but can be accessed via external inputs, then that's an essential part of your application's attack surface.

That's why software development teams have started to use Software Bill of Materials (SBOMs). An SBOM is an inventory of software components that constitute the software or application. Depending on the technology used to create the SBOM, different information can be available including component name, version, dependencies and package ID.

It's helpful in cases where a new vulnerability has been identified. For example, if a vulnerability is discovered in a specific version of lodash, the security team can use its SBOMs to identify which applications or container images contain the affected version. They'll then be able to investigate if there's an exploitable exposure.

An SBOM alone doesn't provide security for the application. Its significance lies in increasing visibility to developers and security personnel regarding what is present in their applications.

Practical Takeaways for Developers

These principles will be relevant once you integrate them into your team's routine development process. There are some practical ways you and your team can employ these best practices and strategies:

Audit Transitive Dependencies

The first thing to do is to verify what dependencies are included in your application. This is very useful when it comes to transitive dependencies, because these dependencies may have been automatically added when installing some other package directly.

For Node.js applications, the command npm ls will display the dependency tree. Python programmers may use pipdeptree, while Java programs created using Maven can use the mvn dependency:tree command. These commands can help you understand the origins of packages and the direct dependency that introduced a vulnerable transitive dependency into your project.

Check Code Reachability

Finding a weak point in a dependency doesn't automatically imply that you're using it within your application. Don't take every vulnerability report as a critical production blocker. Instead, you should investigate if the impacted functionality is actually accessible from your application.

Suppose you find a vulnerability in a certain library function. In this case, you need to look through your codebase for any usage of this function and figure out if there's any possibility of passing user-controlled data to it. You may use either the search function provided by your IDE or command-line utilities such as grep.

An unused or inaccessible from the outside function reduces the urgency of the finding. But it doesn't automatically imply that you should ignore it.

Generate an SBOM in CI/CD

You can also produce a Software Bill of Materials using your CI/CD pipeline. Creating an SBOM will help you identify the components used in the software and make it easier to identify affected components once a vulnerability is found.

For instance, using Syft, you can generate an SBOM from a container image by executing the command: syft my-app:latest -o cyclonedx-json > sbom.json.

This will create a CycloneDX JSON file with information on the components within the container image. This SBOM will then be stored along with the build artifacts. Once a new vulnerability is identified in a particular package version, it becomes easy for the security team to know which applications and container images contain this particular component.

Use Compensating Controls When a Patch Isn't Ready

Sometimes there may be no patch available or it may be too risky to implement it straight away since doing so might introduce breaking changes that need further testing. In such cases, you can use compensatory controls to lessen the exposure of the application until it's patched properly.

Depending on the environment, this may involve limiting the network access to the vulnerable component, isolating the workload from sensitive resources, disabling the feature that has been compromised, or minimizing the privileges of the application.

These controls don't take the place of the security patch but only minimize the risk of exploitation until a patch is implemented.

Apply Least Privilege at Runtime

Lastly, restrict the amount of access your applications have at run time. When a compromise is made due to exploitation, it prevents the spread of that breach to other applications or systems.

When deploying container-based applications, you can leverage read-only filesystems, as well as remove capabilities that aren't required in Linux. For instance, Docker provides the option to use --read-only and --cap-drop=ALL when running containers.

Cloud applications also need to adopt the same concept by ensuring the use of IAM permissions, giving access only to what the application requires.

The goal is simple: if one element has been breached, the attacker should be able to gain access to as few components of the environment around it as possible.

The future of software security doesn't rely on how fast organizations can update their packages without knowing the underlying reasons for doing so. With vulnerability detection becoming more efficient through automation, effective mitigation relies on knowledge about the relationship between the source code, its dependencies, and infrastructure at runtime.

The purpose here isn't just finding new vulnerabilities but recognizing the ones that pose real risks to the application.

Wrap Up

While artificial intelligence is helping teams detect vulnerabilities quicker, modern applications keep becoming increasingly dependent on numerous software layers. This doesn't mean that patching becomes unnecessary. It means that all vulnerabilities don't require the same immediate attention.

Developers also still need to look at where those vulnerabilities exist, whether they're reachable by attackers, and what they could affect. As the time between vulnerability detection and exploitation continues to change, understanding exposure becomes just as important as the patch itself.

In 2026, most people believe they are “covered” because they use a VPN, browse in incognito mode, or occasionally decline cookies. These actions create a sense of control, but they only address a small part of the problem.

The reality is more complex. Privacy today is not about a single tool or setting. It is about how data flows across systems, how identity is inferred, and how behavior is tracked even when you think you are anonymous.

“Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say.”
Source: The Guardian

If you want real protection, you need to understand what actually works and what only creates the illusion of safety.

Table of Contents

• Privacy Is No Longer About Hiding Your IP

• The Illusion of Incognito Mode

• The Rise of First-Party Tracking

• Encryption Still Matters, But It Is Not Enough

• Devices Are the New Weak Point

• Behavioral Data Is the Real Commodity

• Where VPNs Actually Fit

• Identity Is the Core Problem

• Regulation Helps, But It Has Limits

• What Actually Protects You

• The Trade-Offs Are Real

• The Future of Privacy

• Closing Perspective

Privacy Is No Longer About Hiding Your IP

A decade ago, privacy conversations centered on IP addresses. If you could mask your IP, you were considered relatively anonymous. That model is outdated.

Modern tracking systems rely on fingerprinting. Your browser, device type, screen resolution, installed fonts, GPU behaviour, and even how you move your mouse can uniquely identify you. This means that even if your IP changes, your identity can still be reconstructed with high confidence.

Companies no longer need a single identifier. They build probabilistic profiles. These profiles combine dozens of weak signals into one strong identity.

This is why simply using a VPN does not guarantee privacy. It hides where you are connecting from, but it does not hide who you are behaving like.

The Illusion of Incognito Mode

Incognito mode is one of the most misunderstood features in modern browsers. It does not make you anonymous. It simply prevents your local browser from saving history, cookies, and form data.

Your internet service provider can still see your activity. Websites can still track you. Third-party scripts can still build profiles. Incognito mode protects you from other users on the same device, not from the internet itself.

In 2026, relying on incognito mode for privacy is like closing your eyes and assuming no one can see you. It changes your local environment, not the external systems observing you.

The Rise of First-Party Tracking

One major shift in recent years is the move from third-party tracking to first-party tracking. Browsers and regulators have restricted third-party cookies, but this has not reduced tracking. It has changed who does it.

Large platforms now collect data directly. When you log into services, your activity is tied to your account. This is more accurate than cookie-based tracking and harder to block.

Even when you are not logged in, platforms use techniques like link decoration and server-side tracking. These methods bypass traditional browser protections. As a result, blocking cookies is no longer enough.

Privacy today requires reducing how much data you generate, not just controlling how it is stored.

Encryption Still Matters, But It Is Not Enough

Encryption remains one of the most important tools in digital privacy. It ensures that data in transit cannot be easily intercepted.

HTTPS is now standard, and end-to-end encryption is widely used in messaging apps.

However, encryption protects content, not metadata.

Metadata includes who you communicate with, when, how often, and from where. This data can reveal patterns that are often more valuable than the content itself.

For example, knowing that two people communicate regularly at specific times can be enough to infer relationships or activities.

In 2026, sophisticated surveillance systems rely heavily on metadata analysis. This means encryption is necessary, but it is not sufficient.

Devices Are the New Weak Point

Most privacy discussions focus on networks, but devices have become the primary attack surface. Smartphones, laptops, and even smart home devices continuously collect data.

Operating systems gather telemetry. Apps request permissions that go far beyond their core function. Background processes transmit usage patterns, location data, and behavioral signals.

Even trusted platforms collect large amounts of data. This is often justified as necessary for improving services, but it creates detailed user profiles.

Real privacy requires controlling what your devices share. This includes limiting permissions, reducing app usage, and choosing systems that minimize data collection by design.

Behavioral Data Is the Real Commodity

In 2026, raw personal data is less valuable than behavioral data. Companies are less interested in who you are and more interested in what you do.

Behavioral data includes browsing habits, purchase patterns, scrolling speed, typing rhythm, and engagement signals. This data feeds machine learning models and AI automation platforms that predict future actions.

These models power everything from targeted advertising to risk scoring. They are also used in fraud detection, hiring systems, and financial services.

As AI increasingly shapes online interactions, understanding how your data is analyzed can be valuable. It is also important to recognize whether content is generated or influenced by AI. AI detection platforms like ai checker help users identify AI-generated content while supporting greater transparency in digital environments.

The challenge is that behavioral data is difficult to hide. It is generated passively through normal usage. Protecting privacy means reducing the amount of behavior that can be observed and linked over time.

Where VPNs Actually Fit

VPNs still have a role, but it is narrower than most people think. They are useful for securing connections on untrusted networks, such as public Wi-Fi. They can also help bypass geographic restrictions.

However, they do not make you anonymous. They shift trust from your internet provider to the VPN provider. If the provider logs data, your activity is still traceable.

This is where the market has evolved. Users are now looking beyond traditional VPNs such as NordVPN and exploring options that offer stronger privacy guarantees, such as decentralized networks or tools with strict no-logging architectures.

In this context, the idea of a traditional VPN alternatives often comes up, not as a rejection of VPNs, but as a recognition that privacy requires a broader approach.

The key is understanding that a VPN is one layer, not a complete solution.

Identity Is the Core Problem

At the center of modern privacy is identity. Every system you interact with tries to answer one question: is this the same user as before?

If the answer is yes, your actions can be linked over time. This creates a persistent profile.

Breaking this link is difficult. Logging into accounts, using the same device, and maintaining consistent behavior all reinforce identity. Even small signals can reconnect fragmented data.

True privacy requires disrupting this continuity. This can involve using separate environments for different activities, avoiding unnecessary logins, and limiting cross-platform data sharing.

It is not about being invisible. It is about being harder to correlate.

Regulation Helps, But It Has Limits

Privacy regulations have expanded globally. Laws now require companies to disclose data practices, obtain consent, and provide user controls.

These changes have improved transparency, but they have not fundamentally changed data collection. Consent banners are often designed to nudge users toward acceptance. Privacy policies remain complex and difficult to interpret.

Enforcement is also uneven. Large companies adapt quickly, while smaller players may ignore rules altogether.

Regulation sets boundaries, but it does not eliminate incentives. As long as data drives revenue, companies will find ways to collect it within legal frameworks.

What Actually Protects You

Real privacy in 2026 does not come from one app, browser setting, or security tool. Privacy works best as a layered system where several habits work together. Tools help, but behavior matters more. Strong privacy comes from sharing less data, separating identities, reducing tracking signals, and using the right tools carefully.

The first step is to minimize data sharing. Every account signup, app download, connected service, and permission request creates another source of information collection. Share only what is necessary. Use fewer apps and services when possible. Avoid unnecessary integrations between platforms. Review permissions such as location, contacts, microphone access, and background tracking. Less information leaving your control means less information available to collect, sell, or track.

The next step is separating digital identity. Avoid linking every activity to the same account or profile. Use different emails, accounts, or even devices for work, personal use, and anonymous activities. Keeping activities separate makes it harder for systems to build one complete profile about you.

You should also reduce behavioral signals. Modern tracking systems use cookies, tracking pixels, app behavior, and device fingerprinting to identify users. Review app permissions and limit tracking where possible. Fewer signals make profiling harder.

Privacy-focused tools add another layer. Use secure browsers, encrypted messaging apps, secure DNS, and VPNs when needed. Keep them updated and properly configured. Privacy is not about becoming invisible. It is about staying intentional and keeping control over your information.

The Trade-Offs Are Real

It is important to acknowledge that privacy comes with trade-offs. More privacy often means less convenience. Personalized services become less accurate. Seamless experiences may require more manual effort.

Most users are not willing to sacrifice convenience entirely. This is why complete privacy is rare. Instead, the goal should be proportional privacy.

Protect what matters most. Accept some level of exposure where the cost of protection is too high.

The Future of Privacy

Looking ahead, privacy will become more integrated into system design. Technologies like on-device processing, differential privacy, and zero-knowledge proofs are gaining traction.

These approaches aim to reduce data collection while still enabling useful services. Instead of sending raw data to servers, computations happen locally or in privacy-preserving ways.

However, adoption will take time. Economic incentives still favor data collection. Until that changes, users remain responsible for their own privacy posture.

Closing Perspective

The biggest misconception about online privacy is that it can be solved with a single tool. In reality, it is a continuous process.

What protects you in 2026 is not just technology, but how you use it. It is the combination of reducing data exposure, understanding tracking mechanisms, and making deliberate choices about your digital behavior.

Privacy is no longer about disappearing. It is about controlling how visible you are, to whom, and under what conditions.

For years, that list of constraints was the reason people dismissed it. But in 2026, it's the reason Chrome OS might be the most correctly designed operating system for what's coming.

The security architecture treats the endpoint as untrusted by default. The containerized Linux environment gives developers a full headless stack without compromising the host. And an upcoming OS-level rewrite, Aluminium, puts Google's on-device AI models directly into the kernel.

This article covers security architecture, the container-based developer environment, cloud-streamed creative tools via AWS NICE DCV, cloud gaming, and what Aluminium OS means for on-device AI.

Here's what we'll cover:

1. Security-First Architecture in an Era of AI-Powered Threats

2. A Headless Linux Stack That's More Flexible Than It Looks

3. AWS NICE DCV Changes the Creative Tools Conversation

4. Cloud Gaming Works

5. Aluminium OS: On-Device Models on Google's Own Architecture

6. Where This Lands

Security-First Architecture in an Era of AI-Powered Threats

Threat actors are getting better tools. Models like Mythos are lowering the barrier for generating convincing phishing campaigns, crafting polymorphic malware, and automating social engineering at scale.

Traditional operating systems present exactly the attack surface these tools target: writable system files, user-installable executables, patches that sit uninstalled for weeks because someone clicked "remind me later."

Chrome OS sidesteps most of this by design. The root filesystem is read-only and cryptographically verified on every boot through a process called Verified Boot.

If anything has modified the OS files since the last verified state, whether that's malware, a compromised package, or a rogue AI agent that decided to start deleting system files, the device detects it at startup and either self-corrects or refuses to boot.

Persistence across reboots isn't difficult. It's architecturally impossible through software alone.

Updates happen silently. While you're working, the system downloads the next OS version to an inactive partition. On your next reboot, it pivots to the updated version. No prompts, no deferred patches, no exposure window.

Major updates ship every four to six weeks. Security patches land every two to three weeks. The gap between vulnerability discovery and remediation is measured in days.

Chrome OS consistently doesn't appear in the top 50 products by CVE count in the NIST vulnerability database. Windows and the Linux kernel sit near the top every year. When AI is actively being weaponized to find and exploit vulnerabilities faster than humans can patch them, a read-only, verified, automatically updated endpoint is a different category of security posture.

The tradeoff is trust. Chrome OS's security model means trusting Google as the root authority for your entire computing stack: updates, certificate trust, telemetry. Organizations with strict data sovereignty requirements should weigh that dependency carefully.

A Headless Linux Stack That's More Flexible Than It Looks

Chrome OS is a text-based operating system. There's no native GUI layer. Stop and sit with that for a second, because it's the thing that makes people dismiss Chrome OS and also the thing that makes it work.

The entire graphical interface you interact with IS the Chrome browser. The Ash shell, Chrome's window manager, is the desktop. You don't install applications onto it the way you install .exe files on Windows or drag .app bundles into a macOS Applications folder. If it isn't running in a browser tab, an Android VM, or a Linux container, it doesn't run. That restriction is what keeps the host locked down, and it's what makes everything else possible.

Under the hood, Chrome OS runs a minimal virtual machine called Termina through crosvm, Google's Rust-based VM monitor.

Inside Termina, LXD manages Linux containers. The default container, penguin, is a Debian environment with a special trick: it bridges GUI-based Linux applications directly into the Chrome OS desktop through a Wayland proxy called Sommelier. Install VS Code, GIMP, or LibreOffice in penguin and they show up in your Chrome OS app launcher, running in windows alongside your browser tabs. For a lot of developers, penguin alone covers the daily workflow.

But Termina gives you more than penguin. Through the LXD layer you can spin up independent containers that are fully isolated operating systems: Arch, Alpine, Ubuntu, whatever you need.

These aren't attached to the GUI bridge. They run headless, natively, with their own systemd, their own package managers, their own persistent state. Need a clean Ubuntu environment to test a deployment script without touching your main setup? lxc launch and you're there. Need to blow it away? lxc delete and it's gone. No orphaned files on the host, no cross-contamination between environments.

The key distinction from Docker is that LXD runs system containers (full OS emulation) rather than application containers. You get background services, persistent daemons, the works. You can also run Docker inside any of these LXD containers if you need application-level containerization on top of that.

Snapshot your entire environment with lxc snapshot before a risky dependency install and roll back instantly if something breaks. That kind of safety net is broader than version control alone: it captures your full OS configuration, not just code.

Pair this with browser-native tools like GitHub Codespaces, Google Colab, AWS CloudShell, or vscode.dev, and the terminal handles your local tooling while the browser handles everything else.

AI coding assistants like Claude and Gemini already operate natively in the browser. The distance between "cloud IDE" and "local IDE" keeps shrinking.

There are friction points: no custom kernel modules inside Crostini. Nested KVM requires Intel Gen 10+ processors. VPN routing into the Linux container from the Chrome OS host can be a headache, with WireGuard requiring userspace workarounds inside the container.

But none of these break the core architecture for cloud-native work. They're just worth knowing about before you commit.

AWS NICE DCV Changes the Creative Tools Conversation

One of the longest-standing arguments against Chrome OS has been the absence of professional creative software. There's no Premiere, no DaVinci Resolve, no Blender, no Ableton. For years, this was a dead-end conversation.

AWS NICE DCV (Desktop Cloud Visualization) reopens it. DCV is a high-performance remote display protocol that streams GPU-accelerated desktop sessions from EC2 instances to any device, including a Chromebook running the browser-based DCV client. It supports OpenGL, Vulkan, and DirectX rendering, with adaptive encoding that adjusts to network conditions. On AWS, the DCV license is free. You pay only for the EC2 compute time.

Netflix engineers use DCV to stream content creation applications to remote artists. Volkswagen runs 3D CAD simulations across their engineering division through it. A VFX studio called RVX used it to deliver visual effects for HBO's The Last of Us, streaming Nuke, Maya, Houdini, and Blender to artists distributed across Europe from servers in Iceland. Their team said it was the best remote experience they'd ever worked with.

So: a Chromebook connected to a g5.xlarge EC2 instance (one A10G GPU) can run Blender, DaVinci Resolve, or any other GPU-accelerated creative application with full hardware acceleration. The rendering happens in the data center. DCV streams the pixels. The creative professional gets a responsive, high-fidelity workspace on a $400 machine that couldn't locally render a single frame.

The constraints are connectivity and cost. You need sustained bandwidth (25+ Mbps for 1080p work, more for 4K multi-monitor setups) and leaving a GPU instance running around the clock adds up. But for studios and professionals who already budget for high-end workstations, the math often pencils out, especially when you factor in zero local hardware maintenance and the ability to scale GPU power on demand.

Cloud Gaming Works

GeForce NOW survived where Stadia failed because it made a better business decision: bring your own games. Connect your existing Steam, Epic, or Ubisoft library and stream from NVIDIA's server-side hardware. The Ultimate tier now runs on RTX 5080-class infrastructure. 4K at 120fps with ray tracing, on a fanless Chromebook.

Chrome OS has a structural advantage as a cloud gaming client. GeForce NOW runs natively in the Chromium browser via WebRTC, and users consistently report less micro-stuttering and tighter input handling than the standalone Windows desktop app. Under good network conditions, measured total latency runs 13 to 14ms, with sub-3ms ping documented near datacenter proximity. That's below human perceptual threshold for most game types.

Anti-cheat systems like Easy Anti-Cheat and Riot Vanguard are a non-issue in this model. They run on the server where the game executes, not on your local endpoint. On-device gaming isn't viable on Chrome OS and likely never will be. The architecture isn't designed for it, and even projects attempting to bridge local GPUs hit bottlenecks in the container layers. Cloud gaming is the path, and it works.

The limiting factors are network-dependent. Latency spikes above 500ms on bad connections make fast-twitch games unplayable, and NVIDIA's 100-hour monthly cap on the Ultimate tier has drawn criticism. But cloud gaming on Chrome OS has crossed the line from novelty to daily-driver viable for most use cases.

Aluminium OS: On-Device Models on Google's Own Architecture

The most consequential near-term development for Chrome OS is Project Aluminium, a ground-up rewrite that replaces the current Chrome OS foundation with a native Android kernel. Not another bolted-on compatibility layer: a new operating system built on Android 16, designed to run Android applications natively with direct hardware acceleration instead of routing them through the resource-heavy ARCVM virtual machine that currently eats CPU cycles on even basic app launches.

The AI story is the real story. Aluminium is being built with Gemini models integrated directly into the OS: the file system, the application launcher, the window manager.

Google serving their own proprietary models on their own devices, using an architecture optimized specifically to run them, is a level of vertical integration that no other OS vendor has in the pipeline. Apple has the silicon advantage for local inference. Google has the model-to-OS integration advantage. Those are competing theses about where AI compute should live, and both are worth taking seriously.

The rollout timeline from court documents and leaked roadmaps puts a trusted tester program on select hardware in late 2026, premium tablets by early 2027, and general consumer availability in 2028. Chrome OS Classic gets maintained through existing support obligations until 2033 or 2034.

The launch won't be perfect. Google's track record on platform transitions gives the community earned skepticism. But the ability to iterate a natively AI-integrated OS on hardware they control is the kind of capability that compounds over time.

Where This Lands

Two years ago, calling Chrome OS a serious platform for development or creative work would have been a stretch. Today you can run a full Debian environment with systemd daemons, snapshot your workspace, stream Blender from a GPU-backed data center, play AAA games at 4K on hardware you don't own, and do all of it from a verified, read-only endpoint that patches itself while you sleep.

The remaining gaps are real. But they're concentrated in workflows that are themselves moving to the cloud. Chrome OS was designed around assumptions about computing that used to be premature. They're not premature anymore.

Storing them is straightforward. But handling rotation, stale env vars, and the gap between what your pod reads and what AWS actually holds is where many engineers go quiet.

In this guide, you'll build a complete secrets pipeline from AWS Secrets Manager into Kubernetes pods. You'll provision the infrastructure with Terraform, sync secrets using the External Secrets Operator, and run a sample application that reads the same credentials in two different ways: via environment variables and via a volume mount.

By the end, you'll be able to:

• Explain the full architecture from vault to pod

• Run the lab locally in about 15 minutes

• Prove why environment variables go stale after rotation, while mounted secret files stay fresh

• Deploy the same pattern on Amazon Elastic Kubernetes Service with OpenID Connect-based CI/CD

• Troubleshoot the most common failures

Below is an architecture diagram showing secrets flowing from AWS Secrets Manager through the External Secrets Operator into a Kubernetes Secret, then splitting into environment variables set at pod start and a volume mount that updates within 60 seconds.

Table of Contents

• Prerequisites

• How to Understand the Secret Flow

• How to Run the Local Lab

• How to Inspect the ExternalSecret and the Application

• How to Test Secret Rotation

• How to Choose Between External Secrets Operator and the CSI Driver

• How to Deploy the Pattern on Amazon Elastic Kubernetes Service

• How to Configure GitHub Actions Without Stored AWS Credentials

• How to Troubleshoot the Most Common Failures

• Conclusion

Prerequisites

Before you begin, make sure you have the following tools installed and configured.

For the local lab:

• An AWS account with access to AWS Secrets Manager

• The AWS CLI installed and configured. Run aws configure and provide your access key, secret key, default region, and output format. The credentials need permission to read and write secrets in AWS Secrets Manager.

• kubectl installed. For Microk8s, run microk8s kubectl config view --raw > ~/.kube/config after installation to connect kubectl to your local cluster.

• Terraform installed

• Helm installed

• Docker installed

• A local Kubernetes cluster: the lab supports Microk8s and kind. If you do not have either installed, follow the Microk8s install guide before continuing.

For the Amazon Elastic Kubernetes Service sections:

• An Amazon Elastic Kubernetes Service cluster you can create or manage

• A GitHub repository you can configure for workflows and secrets

The lab repository includes two deployment paths: a local path for fast learning and an Amazon Elastic Kubernetes Service path for a production-like setup. All the exact commands for each path live in the repo's docs/DEPLOY-LOCAL.md and docs/DEPLOY-EKS.md.

How to Understand the Secret Flow

Before you run any command, you need to understand how the pieces connect.

The flow has four stages:

1. A developer or automated system updates a secret in AWS Secrets Manager.

2. The External Secrets Operator polls AWS Secrets Manager on a schedule and creates or updates a Kubernetes Secret.

3. Your pod reads that Kubernetes Secret.

4. During rotation, the Kubernetes Secret updates, but your two consumption modes behave differently.

How the External Secrets Operator Sync Works

The External Secrets Operator reads a custom Kubernetes resource called ExternalSecret. That resource tells the operator three things:

• Which secret store to connect to

• Which Kubernetes Secret name to create or update

• How often to refresh

In this lab, the ExternalSecret creates a Kubernetes Secret named myapp-database-creds. The operator also adds a template annotation that can trigger a pod restart when the secret rotates.

How the App Consumes Secrets

The sample application exposes three endpoints so you can validate behavior at any time.

• /secrets/env shows what environment variables the pod sees

• /secrets/volume shows what files in the mounted secret directory look like

• /secrets/compare compares both and reports whether rotation has been detected

The app checks four keys: DB_USERNAME, DB_PASSWORD, DB_HOST, and DB_PORT.

How to Run the Local Lab

The local lab gives you a fast learning loop. You can see the full pipeline working and test rotation without waiting for a cloud deployment.

Step 1: Clone the Repo

git clone https://github.com/Osomudeya/k8s-secret-lab
cd k8s-secret-lab

Step 2: Run the Spin-Up Script

bash spinup.sh

The script will ask you to choose a local cluster type. Pick Microk8s or kind, depending on what you have installed. The script installs the External Secrets Operator via Helm, applies the Terraform configuration, and deploys the sample application.

If the script fails at any point, check docs/TROUBLESHOOTING.md before retrying. The most common causes are missing AWS credentials, a misconfigured kubeconfig, or a Microk8s storage add-on that is not enabled.

Important: Run the Lab UI

The lab ships with a separate guided tutorial interface that runs on your laptop. This is not the in-cluster application, it's a React-based checklist at lab-ui/ that walks you through each concept and checkpoint as you work through the lab.

To start it, open a second terminal and run:

cd lab-ui && npm install && npm run dev

Then open http://localhost:5173. You'll see a module-by-module guide covering the full flow from external secrets to rotation to CI/CD.

Keep this terminal running alongside your lab. The Lab UI and the in-cluster app (localhost:3000) are two separate things, the UI guides you through the steps, the app shows you the live secrets.

Step 3: Access the Application

Once the lab finishes, port-forward the service.

kubectl port-forward svc/myapp 3000:80 -n default

Open http://localhost:3000. You should see a table showing each secret key and whether the environment variable value matches the volume mount value.

Step 4: Validate That Secrets Match

Run the compare endpoint directly from the terminal.

curl -s http://localhost:3000/secrets/compare | python3 -m json.tool

When everything is working, the response will include "all_match": true.

How to Inspect the ExternalSecret and the Application

At this point the lab is running. Now you'll want to inspect the manifests so you understand what each part does.

Step 1: Read the ExternalSecret Manifest

Open k8s/aws/external-secret.yaml. Focus on these four fields:

• refreshInterval: how often the operator polls AWS Secrets Manager

• secretStoreRef: which store the operator authenticates against

• target: the name of the Kubernetes Secret to create

• data: the mapping from AWS Secrets Manager JSON keys to Kubernetes Secret keys

Here is what that mapping looks like in this lab:

spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: myapp-database-creds
    creationPolicy: Owner
  data:
    - secretKey: DB_USERNAME
      remoteRef:
        key: prod/myapp/database
        property: username

The property field tells the operator which JSON key inside the AWS secret to extract. If your secret in AWS Secrets Manager is a JSON object, each field gets its own entry here.

Two fields here are worth understanding before you move on. creationPolicy: Owner means the operator owns the Kubernetes Secret it creates. If you delete the ExternalSecret, the Secret is deleted too. ClusterSecretStore is a cluster-scoped store, meaning any namespace in the cluster can use it. A plain SecretStore is namespace-scoped. For this lab, cluster-scoped is the right choice because it keeps the setup simple.

Step 2: Read the Deployment Manifest

Open k8s/aws/deployment.yaml. You are looking for two sections: envFrom and volumeMounts.

envFrom:
  - secretRef:
      name: myapp-database-creds

volumeMounts:
  - name: db-secret-vol
    mountPath: /etc/secrets
    readOnly: true

Both paths read from the same Kubernetes Secret, myapp-database-creds. The envFrom block injects all keys as environment variables at pod start.
The volumeMounts block mounts the same secret as files under /etc/secrets.

This is the core of the rotation lesson. Both paths read the same source. But they behave differently after that source changes.

Step 3: Read the App Comparison Logic

Open app/server.js. The comparison logic reads environment variables from process.env and reads mounted secret files from /etc/secrets/<key>. Then it computes a per-key match and a global all_match value.

The /secrets/compare endpoint sets rotation_detected: true when any key differs between env and volume.

How to Test Secret Rotation

Secret rotation is where real teams feel pain. This lab makes that pain visible so you can explain it clearly and fix it confidently.

How the Rotation Gap Works

When a pod starts, Kubernetes gives it two ways to read a secret.

The first way is environment variables. Think of these like sticky notes written on the wall of the container the moment it boots up. The value gets written once, at startup, and never changes. Even if the secret in AWS gets updated ten minutes later, the sticky note still says the old value. The container cannot see the update because nobody rewrote the note.

The second way is a volume mount. Think of this like a shared folder that someone else can update remotely. Kubernetes creates a small folder inside the container and puts the secret value in a file there. When the secret changes in AWS and ESO syncs it into Kubernetes, the kubelet quietly updates that file within about 60 seconds. The container reads the file fresh every time it needs the value, so it sees the new password automatically.

Same secret, two paths. One goes stale while one stays fresh.

The problem happens when your app reads the database password from the environment variable, the sticky note, and someone rotates the password in AWS. ESO updates Kubernetes. The file gets the new password. But your app is still reading the sticky note, which has the old one. Connection fails.

That difference isn't a bug. It's how the Linux process model and the kubelet work. Understanding it is the difference between knowing Kubernetes secrets and actually operating them.

Here is what you're about to observe in the lab:

• The rotation script updates the secret in AWS

• ESO syncs the new value into Kubernetes within seconds

• The volume file updates automatically

• The environment variable stays stale until the pod restarts

• The /secrets/compare endpoint shows both values side by side so you can see the gap live

Step 1: Confirm the Lab Is Ready

Make sure your pod and the External Secrets Operator are both running before you start.

kubectl get pods -n external-secrets
kubectl get pods -n default

Both should show Running.

Step 2: Run the Rotation Test Script

bash rotation/test-rotation.sh

The script performs these actions in order:

1. Reads the current DB_PASSWORD from the volume mount at /etc/secrets/DB_PASSWORD

2. Reads the current DB_PASSWORD from the environment variable

3. Updates AWS Secrets Manager with a new password using put-secret-value

4. Forces an immediate ESO sync by annotating the ExternalSecret with force-sync

5. Reads the volume value again

6. Reads the environment variable again

After the script runs, the volume and the env var will show different values.

Step 3: Validate With the Compare Endpoint

Hit the compare endpoint and look at the output.

curl -s http://localhost:3000/secrets/compare | python3 -m json.tool

You'll see something like this:

{
  "comparison": {
    "DB_PASSWORD": {
      "env": "old-password-value",
      "volume": "new-password-value",
      "match": false
    }
  },
  "all_match": false,
  "rotation_detected": true,
  "message": "Volume has new value; env still has old value."
}

Step 4: Restart the Deployment to Sync Env Vars

Env vars don't update in place. You need a pod restart so new containers start with the updated Kubernetes Secret.

kubectl rollout restart deployment/myapp -n default
kubectl rollout status deployment/myapp -n default

Then hit /secrets/compare again. All rows should now show "all_match": true.

How to Automate Restarts With Reloader

If you don't want to restart deployments manually after every rotation, you can install Stakater Reloader. It watches an annotation on the Deployment and triggers a rolling restart automatically when the referenced Kubernetes Secret changes. New pods start with fresh env vars, while old pods drain cleanly. The repo's local deployment guide includes the install steps.

How to Choose Between External Secrets Operator and the CSI Driver

Two patterns dominate when it comes to pulling external secrets into Kubernetes: the External Secrets Operator and the Secrets Store CSI Driver.

Both get cloud secrets into pods, but they do it differently. Here's a plain comparison:

This lab uses the External Secrets Operator for two reasons. First, it produces a native Kubernetes Secret, which means your application and deployment patterns match standard Kubernetes workflows. Second, having both envFrom and a volume mount point to the same Secret makes the rotation behavior easy to observe side by side.

Use the CSI Driver when your security team prohibits storing secrets in etcd through a Kubernetes Secret. The driver mounts secret data directly into the pod file system without creating a Kubernetes Secret. The tradeoff is that you lose the native envFrom model.

How to Deploy the Pattern on Amazon Elastic Kubernetes Service

The local lab is ideal for learning. The Amazon Elastic Kubernetes Service path adds the production-like pieces: IAM role-based permissions for the operator, a load balancer for the app, and a full CI/CD workflow.

Step 1: Prepare Terraform and OpenID Connect Access

The repository includes a one-time setup guide for OpenID Connect-based access from GitHub Actions to AWS. Run these commands in the terraform/github-oidc folder.

cd terraform/github-oidc
terraform init
terraform plan -var="github_repo=YOUR_ORG/YOUR_REPO"
terraform apply -var="github_repo=YOUR_ORG/YOUR_REPO"
terraform output role_arn

Copy the role ARN from the output. You'll need it in the next step.

Step 2: Set the Required Environment Variable

The Amazon Elastic Kubernetes Service spin-up path needs your GitHub Actions role ARN so Terraform can grant the CI/CD runner access to the cluster.

To find your AWS account ID, run:

aws sts get-caller-identity --query Account --output text

Then set the variable, replacing ACCOUNT with the number that command returns.

export GITHUB_ACTIONS_ROLE_ARN=arn:aws:iam::ACCOUNT:role/your-github-oidc-role

Step 3: Run the Spin-Up Script for Amazon Elastic Kubernetes Service

bash spinup.sh --cluster eks

When the script finishes, it prints the application URL. Open that URL in a browser and confirm that you see the same secrets table you saw locally, with all keys showing Match ✓.

Step 4: Test Rotation on the Deployed App

After you confirm normal operation, run the rotation test the same way you did locally.

bash rotation/test-rotation.sh

Then use /secrets/compare on the Amazon Elastic Kubernetes Service load balancer URL to validate behavior in the cloud environment.

⚠️ Cost warning: Amazon Elastic Kubernetes Service runs at approximately $0.16 per hour. When you're done with the lab, run bash teardown.sh from the repo root to destroy all AWS resources and stop charges.

How to Configure GitHub Actions Without Stored AWS Credentials

The typical CI/CD setup stores AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in GitHub repository secrets. Those keys never rotate. Anyone with repo access can read them. When someone leaves the team, you have to revoke keys and update every workflow.

OpenID Connect eliminates that problem entirely.

How OpenID Connect Works for GitHub Actions

GitHub can issue a short-lived token for each workflow run. That token identifies the run: the repository, branch, and workflow name. You create an IAM role in AWS whose trust policy says: only accept requests that come from this specific GitHub repository and branch. The GitHub Actions runner exchanges that token for temporary AWS credentials via AssumeRoleWithWebIdentity. No long-lived keys are ever stored anywhere.

Step 1: Create the IAM Role With Terraform

The terraform/github-oidc folder creates the OpenID Connect provider and the IAM role for you. You already ran this in the Amazon Elastic Kubernetes Service setup above. The role ARN is the only value you need to store.

Step 2: Add the Role ARN to GitHub Repository Secrets

In your GitHub repository:

1. Go to Settings → Secrets and variables → Actions

2. Click New repository secret

3. Name it AWS_ROLE_ARN

4. Paste the role ARN from the Terraform output

That is the only secret you store. The role ARN isn't sensitive. It's an identifier, not a credential.

Step 3: Configure Terraform State

For CI/CD to work consistently across runs, Terraform needs a shared state backend. The lab stores Terraform state in an Amazon S3 bucket and uses an Amazon DynamoDB table for state locking. The Amazon Elastic Kubernetes Service deployment guide in the repo covers the backend setup in full.

Step 4: Push to Main and Let Workflows Run

After your first spin-up, every push to the main branch drives the CI/CD pipeline. The repo includes separate workflow files for Terraform infrastructure changes and application deployment changes. Once your application is reachable, use /secrets/compare to validate rotation behavior on the live environment.

How to Troubleshoot the Most Common Failures

Here's a shortlist of the most common symptoms and their fixes.

How to Inspect the Operator and the ExternalSecret

When something isn't syncing, start with these two commands.

# Check the ExternalSecret status
kubectl describe externalsecret app-db-secret -n default

# Check the ESO operator logs
kubectl logs -n external-secrets -l app.kubernetes.io/name=external-secrets

The status conditions on the ExternalSecret resource will usually tell you exactly what failed.

How to Validate Rotation From the App Side

When you are debugging rotation, don't rely only on Kubernetes resource state. Use the /secrets/compare endpoint to see what the running application actually observes. The endpoint tells you whether env and volume match and whether rotation has been detected. That is the ground truth for your application's behavior.

Conclusion

You now have a complete secrets pipeline from AWS Secrets Manager into Kubernetes pods using Terraform and the External Secrets Operator. You ran the local lab, inspected the ExternalSecret and Deployment manifests, and validated that the application sees the right credentials.

You also tested secret rotation and observed the key behavior firsthand: mounted secret files update within the kubelet sync period, while environment variables stay stale until the pod restarts. That single observation explains a large class of production incidents.

Finally, you saw how the same design extends to Amazon Elastic Kubernetes Service with OpenID Connect-based CI/CD, and you have a troubleshooting checklist for the failures most teams hit.

The lab repository is at github.com/Osomudeya/k8s-secret-lab. If you ran the local lab, the natural next step is phases 4 and 5 from the repo's staged learning path: try the CSI driver path on Microk8s, then follow the EKS setup to see the same pipeline with a real CI/CD workflow and no credentials stored in GitHub. Both are documented in the repo and take less than 30 minutes each.

If this helped you, star the repo and share it with someone who is learning Kubernetes.

I send weekly breakdowns of real production incidents and how engineers actually fix them, not tutorials but real failures
→ Join the newsletter

Attack surfaces are broad, technology stacks are complex, and adversaries are quick to exploit weak points.

Against this backdrop, companies must decide how best to test their defences.

Two main approaches have emerged as leaders: human-led penetration testing services and automated testing platforms. Each has strengths and limitations. Choosing the right one depends on your security goals, risk tolerance, and budget.

At its core, penetration testing is about finding security holes before attackers do. But how you get there matters.

Human experts bring creativity and real-world insight, while automated platforms offer scale and speed.

This article explores both approaches and compares top providers to help you decide what’s better for your organization in 2026.

What we'll cover:

1. What Are Penetration Testing Services?

2. What Are Automated Penetration Testing Platforms?

3. Why the Debate Matters in 2026

   • Depth of Testing: Humans vs Machines

   • Speed and Frequency of Testing

   • Cost Considerations

   • Integration with Security Workflows

4. Real World Context: Top Providers in 2026

5. Compliance and Reporting

6. Which One Should You Choose in 2026?

7. Final Thoughts

What Are Penetration Testing Services?

Penetration testing services are engagements where cybersecurity professionals actively probe your systems to find vulnerabilities. These experts use a mix of tools, manual techniques, and real-world attack simulations to surface weaknesses that machines might miss.

These services may include scheduled tests, one-time assessments, and ongoing engagements. Many providers tailor their approach to the environment being tested, whether that’s a corporate network, web application, cloud infrastructure, or mobile ecosystem.

Human testers think like attackers, combining automated scans with logic and adaptability that machines cannot replicate on their own.

These engagements are typically measured in reports, debrief sessions, and clear remediation guidance. The human element is the defining factor. A skilled tester doesn’t just find flaws. They understand context, creative exploit paths, and business impact.

What Are Automated Penetration Testing Platforms?

Automated penetration testing platforms use software to scan, crawl, and test systems for vulnerabilities. These platforms run scheduled scans or continuous assessments with minimal human intervention. They aim to find flaws early and often, integrating with development pipelines or security operations centers.

Automation brings consistency, speed, and the ability to repeat tests frequently. Many modern platforms use machine learning to prioritize findings and reduce noise. Some offer automation rules that trigger scans based on changes in the environment or codebase.

In contrast to full manual services, platforms are best suited for ongoing baseline assessments and rapid feedback. They are often priced in subscription models and integrate with other tooling like bug tracking systems or SIEMs. While they can pinpoint known vulnerability patterns efficiently, automated tools are limited in creative attack paths and logic-based exploits.

Why the Debate Matters in 2026

In 2026, the cybersecurity landscape is both more advanced and more hazardous. Organizations operate hybrid clouds, microservices architectures, and complex supply chains.

Threat actors are using AI to scale attacks. In this environment, the question is not only about finding old vulnerabilities but anticipating novel attack methods.

With limited resources, security leaders must choose wisely. Do you invest heavily in services with human experts? Do you adopt automated platforms that test continuously?

Maybe a mix is best. To answer these questions, let’s explore how the two approaches compare across key criteria.

Depth of Testing: Humans vs Machines

Human-led penetration tests shine when deep context and logic are required. Expert testers can chain together multiple issues to compromise a system in ways automated tools don't anticipate. They explore paths, think creatively, and adapt in real time to the environment they encounter.

Automated platforms excel at breadth and repetition. They perform wide sweeps of systems quickly and can generate alerts on common vulnerability classes. They're particularly strong in repetitive tasks like scanning hundreds of endpoints or validating compliance controls.

But platforms often rely on predefined signatures and patterns. They perform poorly when an exploit requires intuition or lateral thinking.

In simple terms, human services dig deep while platforms dig wide.

Speed and Frequency of Testing

Automated platforms have a clear advantage in speed and frequency. They can run multiple scans in parallel, test after every code commit, and provide almost immediate feedback. This makes them ideal for DevOps pipelines and agile environments that change daily.

Penetration testing services, by design, occur on a schedule. A quarterly or annual test may be thorough, but it cannot match the cadence that automated tools provide.

Manual tests take time to plan, execute, and analyze. In fast-moving environments, this might leave gaps between testing windows.

For many organizations, automation fills these gaps, while manual testing provides periodic, deep insight.

Cost Considerations

Cost is always a factor. Automated platforms generally come with lower upfront costs compared to human-led engagements. Subscriptions scale with usage and provide continuous assessment for a predictable price. This makes them appealing to midsize companies or teams with limited budgets.

Penetration testing services, especially from reputable consultancies, command higher fees. These reflect labor costs, expertise, and the bespoke nature of the work.

However, the value gained is often more than just flaw detection: it’s expert interpretation, custom exploitation paths, and strategic guidance.

In cost-benefit terms, automated platforms provide the most value per dollar for baseline security, while services deliver high-value insight that can justify a higher cost.

Integration with Security Workflows

Automated platforms are built to integrate with broader security tooling. They often connect to continuous integration/continuous delivery (CI/CD) pipelines, vulnerability management platforms, and ticketing systems. This integration ensures that issues are communicated to the teams who need them most and tracked to resolution.

Penetration testing services can integrate into workflows too, but this usually requires additional coordination. Reports must be ingested into tracking systems and aligned with internal priorities. Some providers offer APIs and extended services that help bridge this gap, but the process typically takes more effort than with automated platforms.

Integration matters because security cannot operate in isolation. Automated platforms fit more naturally into modern DevSecOps workflows, while services provide episodic insights that must be planned and bridged into operations.

Real World Context: Top Providers in 2026

To illustrate how these approaches manifest in practice, consider a few leading options. Each provider offers different strengths in manual services or automated tooling.

One such provider is XBOW. XBOW is known for deep manual testing engagements, combining expert human testers with structured methodologies across network, application, and cloud environments. Their work emphasizes real-world attack simulations and strategic risk reporting.

Another well-known provider is Cobalt. Cobalt blends human expertise with platform-based management. Their Pentest as a Service (PtaaS) model connects testers to client environments through a platform that organizes findings, workflows, and communication. Clients can collaborate with testers, track issues in real time, and integrate results with other systems.

A different model comes from Synack. Synack uses a crowd of vetted testers who work with a secure testing platform. This hybrid model aims to combine the creativity of human testers with the scalability and tracking of automated systems. Clients benefit from diverse testing styles and coordinated reporting within a structured platform.

Each of these approaches has merit. Some lean more toward pure services, others toward platform-driven collaboration. Your choice should align with your security maturity and goals.

Compliance and Reporting

For regulated industries, compliance matters. Automated platforms often include reporting features that map directly to standards like PCI DSS, HIPAA, or ISO 27001. These reports can be generated on a regular cadence and integrated into audit evidence.

Penetration testing services provide compliance support too, but the reports are typically narrative and bespoke. The real value is in expert interpretation of compliance requirements and guidance on remediating complex findings.

In essence, automation provides structured, repeatable reporting, while services deliver customized insights that may carry more weight with auditors and internal stakeholders.

Which One Should You Choose in 2026?

There is no one-size-fits-all answer. Many organizations adopt both approaches. Automated platforms serve as the first line of defense by continuously scanning for known issues and tracking progress over time. Human-led services then provide a deeper second layer, uncovering complex issues and offering strategic guidance.

If your environment is highly dynamic, with frequent releases and evolving infrastructure, an automated platform is essential. If you operate in a high-risk sector where attackers are likely to craft bespoke exploits, human-led penetration testing services are indispensable.

Most mature security programs use both. Automation drives frequency and scale. Human services provide depth and insight. Together, they form a layered testing strategy that maximizes coverage and minimizes blind spots.

Final Thoughts

In 2026, cybersecurity testing is more sophisticated and essential than ever. Organizations must balance speed, depth, cost, and context when selecting between penetration testing services and automated platforms. While one is not inherently better than the other in all cases, understanding their differences and complementary strengths will help you build a robust security posture.

Automated platforms catch the routine and repetitive, giving continuous visibility into known risks. Human-led services uncover the hidden and unexpected, thinking beyond patterns to simulate real adversaries. For most teams, the future of testing lies in a hybrid approach that leverages both.

By aligning your security goals with the right mix of services and tools, you can stay ahead of threats now and in the years to come.

Hope you enjoyed this article. Learn more about me by visiting my website.

Disaster recovery testing is what separates assumed resilience from proven recovery, but it’s still skipped, rushed or treated as a checkbox exercise. For developers and technical teams, that gap can turn a manageable failure into a prolonged outage.

Table of Contents

• What is Disaster Recovery Testing?

• How Disaster Recovery Testing Works in Practice

• Disaster Recovery Testing Methods Developers Should Know

• What Technology Disaster Recovery Testing Evaluates

• How to Test a Disaster Recovery Plan

• Disaster Recovery Test Scenarios: Practical Examples

• Disaster Recovery Test Report: Turning Tests Into Improvements

• Disaster Recovery Audits and Continuous Validation

• Conclusion

What is Disaster Recovery Testing?

Disaster recovery (DR) testing is the process of validating that systems, data and applications can be restored after a disruptive event within defined recovery objectives. It generally evaluates:

• Recovery Time Objective (RTO): How quickly systems must be restored.

• Recovery Point Objective (RPO): How much data loss is acceptable.

• Operational readiness: Whether teams know what to do during an incident.

A disaster recovery test plan documents how these elements are tested, who is responsible and what success looks like. Without testing, DR plans are assumptions, not guarantees.

How Disaster Recovery Testing Works in Practice

In real environments, disaster recovery testing is used to check all elements of the disaster recovery plan and is rarely a single event. It’s a structured exercise that simulates failure, observes system behavior and measures outcomes against expectations.

A typical DR test involves:

1. Defining scope – Which applications, services, or data sets are included.

2. Selecting a scenario – Outage, corruption, ransomware, region failure, and so on.

3. Executing recovery actions – Restore data, fail over systems, reconfigure dependencies.

4. Measuring results – Time to recovery, data consistency, service availability.

5. Documenting findings – What worked, what failed, what needs improvement.

For developers, the key shift is recognizing that DR testing isn’t just an ops exercise. Application architecture, data handling and deployment patterns all influence recovery outcomes.

Importantly, regulatory pressure is also reshaping how organizations approach recovery validation. Frameworks such as the NIS2 Directive require essential and important entities in the EU to implement robust cybersecurity risk management measures, including incident response and business continuity capabilities.

Disaster Recovery Testing Methods Developers Should Know

Different testing methods provide different levels of confidence. Mature teams use more than one. Each method has a place, but relying only on low-impact testing creates blind spots that surface during real incidents.

Checklist Testing

The simplest method: Teams review documented recovery steps without executing them. This helps validate documentation completeness but does not confirm real-world recoverability.

Tabletop Exercises

Stakeholders walk through a simulated disaster scenario and discuss responses. Tabletop tests are useful for identifying communication gaps and unclear responsibilities, especially for cross-team coordination.

Partial or Component Testing

Specific systems, such as databases or backup restores, are tested in isolation. Developers often encounter this when validating recovery procedures for individual services or environments.

Full-scale Testing

This is the most comprehensive method. It involves actual failover or full recovery in production-like environments. While disruptive, full-scale tests provide the highest confidence.

What Technology Disaster Recovery Testing Evaluates

Modern environments are complex, and disaster recovery testing must validate more than just data restores.

DR testing evaluates:

• Backup integrity – Are backups usable, consistent and complete?

• Application dependencies – Do services come back in the correct order?

• Infrastructure recovery – Can compute, storage and networking be re-provisioned?

• Identity and access – Do credentials, secrets and permissions still function?

• Automation and scripts – Do recovery workflows still match current architectures?

For developers, this often reveals hidden coupling between services, outdated scripts or environment-specific assumptions that were never documented.

How to Test a Disaster Recovery Plan

Testing a disaster recovery plan doesn’t require shutting down production on day one. A practical, incremental approach works best.

1. Start with a single application: Pick a service with well-defined data and dependencies. Avoid starting with your most complex system.

2. Validate backup restores: Restore data into a non-production environment and confirm application functionality, not just file presence.

3. Measure RTO and RPO: Time the recovery process and compare results to stated objectives. At this stage, many teams can discover that their objectives were unrealistic.

4. Test failure assumptions: Simulate real-world issues like missing credentials, expired certificates or partial data loss.

5. Document gaps immediately: Update the disaster recovery test plan while findings are fresh. Untested fixes are just new assumptions.

This approach makes disaster recovery testing part of standard processes rather than a once-a-year compliance task.

Automating Restore Validation

One of the most common gaps in disaster recovery testing is stopping at “restore completed” instead of validating that the application actually works. A restored database that can’t serve queries or contains incomplete data doesn’t meet recovery objectives.

Teams can reduce this risk by automating post-restore validation. For example, after restoring a PostgreSQL database into a staging or isolated DR environment, a simple validation script can confirm connectivity and basic data integrity:

import psycopg2

import sys


def validate_restore():

    try:

        conn = psycopg2.connect(

            host="restored-db.internal",

            database="appdb",

            user="dr_test_user",

            password="securepassword"

        )

        cur = conn.cursor()

        cur.execute("SELECT COUNT(*) FROM users;")

        result = cur.fetchone()



        if result and result[0] > 0:

            print("Restore validation successful.")

        else:

            print("Restore validation failed: No data found.")

            sys.exit(1)


        conn.close()

    except Exception as e:

        print(f"Restore validation error: {e}")

        sys.exit(1)


validate_restore()

This script does three important things:

• Confirms the database is reachable

• Executes a real query, not just a connection check

• Fails explicitly if the expected data is missing

In practice, teams can integrate scripts like this into CI/CD pipelines or scheduled recovery drills. The goal isn’t to test every edge case, but to move from “backup exists” to “restore is functionally verified.” Over time, these automated checks become part of the disaster recovery test plan, helping teams measure RTO accurately and detect configuration drift before a real incident exposes it.

Disaster Recovery Test Scenarios: Practical Examples

Effective disaster recovery testing focuses on realistic failures, not idealized outages.

Accidental Deletion or Misconfiguration

A dropped database table, deleted storage bucket or bad configuration change tests how quickly teams can restore specific data without rolling back entire systems. These everyday incidents often reveal slow or overly manual recovery processes.

Data Corruption and Application Failure

Buggy releases can silently corrupt data while systems remain online. This scenario validates point-in-time recovery and whether teams can identify when corruption started, not just restore the latest backup.

Ransomware Simulation

Ransomware testing checks whether clean, uncompromised backups can be restored in isolation. It often exposes gaps in backup immutability, credential handling and realistic recovery times.

Infrastructure or Platform Outage

Simulating the loss of a cluster, availability zone or region tests automation and infrastructure-as-code maturity. In virtualized environments, most commonly VMware disaster recovery, testing involves restoring virtual machines at a secondary site and validating networking and application dependencies.

Credential and Access Failure

Recovery can stall if credentials, certificates or secret keys are unavailable. Testing this scenario validates identity systems and whether recovery procedures rely on fragile access assumptions.

Disaster Recovery Test Report: Turning Tests Into Improvements

Testing without documentation is wasted effort. A disaster recovery test report turns results into actionable improvements.

A valuable DR test report includes:

• Test scope and scenario

• Expected vs. actual RTO/RPO

• Recovery steps executed

• Failures, delays and root causes

• Recommended changes

For developers, this often results in concrete action items: refactoring startup dependencies, adding health checks, improving automation or adjusting data protection policies. The report should feed directly into backlog planning.

Disaster Recovery Audits and Continuous Validation

Audits often expose what teams already suspect: Disaster recovery plans exist, but haven’t been tested recently (or at all).

Rather than treating audits as one-time events, teams should adopt continuous validation:

• Regular restore tests integrated into CI/CD pipelines.

• Scheduled DR tests tied to major architecture changes.

• Automated alerts when recovery objectives drift.

This shifts disaster recovery testing from an annual obligation to an ongoing practice that evolves alongside the environment.

Conclusion

Disaster recovery testing is not about pessimism, it’s about realism. Systems and people change, and failure modes evolve faster than documentation. Without testing, even the best-designed recovery plan can become outdated.

For developers and technical teams, practicing disaster recovery testing builds confidence rooted in evidence, not assumptions. It exposes hidden dependencies, validates data protection strategies and ensures that when something goes wrong, recovery is predictable instead of chaotic.

We just posted a course on the freeCodeCamp.org YouTube channel that will help you master the fundamentals of cybersecurity and ethical hacking. This is a beginner-friendly, hands-on course using Kali Linux.

You’ll learn to identify, exploit, and defend against real-world vulnerabilities while building a solid foundation in penetration testing, network security, and vulnerability assessment. By mastering professional tools like Nmap and Wireshark, you will develop the practical skills and mindset needed to secure systems and think like an ethical hacker. This course was created by Sunny Dimalu The Cyborg.

Here are the sections in this course:

• Introduction

• What is Kali Linux

• Basic Commands & Terminal Customization

• ls Command

• cd Command

• Nano Editor

• cat Command

• Create Files Using cat

• Create Directories

• grep Command

• wc Command

• Output Redirection

• Piping

• Copy Files

• Remove Files & Directories

• Types of Users

• Root User

• sudo Command (Administrative Tasks)

• ip addr Command

• Install Packages

• Remove Packages

• Introduction to Nmap

• Scan Ports

• Wi-Fi Security: System Requirements & Wireless Card

• Introduction to Aircrack-ng

• Monitor Mode vs Managed Mode

• Enable Monitor Mode

• Scan Wi-Fi Networks & Capture Traffic

• Scan 5GHz Wi-Fi Networks (Theory)

• Scan 5GHz Wi-Fi Networks (Practical)

• What is a 4-Way Handshake

• Capture a 4-Way Handshake

• What is a De-authentication Attack

• Capture 4-Way Handshake Using De-authentication Attack

• Wordlists & Dictionary Attacks

• Crack / Recover Wi-Fi Password

• Detect De-authentication Attacks /Threats

• Wireshark Tutorial

Watch the full course on the freeCodeCamp.org YouTube channel (4-hour watch).

Table of Contents

• What is "React2Shell"?

• Why is this Happening Now?

• Should You Worry About this Change?

• Is this Mandatory?

• How Bad Can It Get? The Extent of Exploitation

• What Would be the Code Change for This?

• Advanced: Verify with the Original Exploit (PoC)

• Emergency Response: What If You Were Already Compromised?

• Conclusion

What is "React2Shell"?

Think of your server receiving data like a mailroom receiving packages.

Usually, a mailroom checks if a package is safe before opening it. But in vulnerable versions of React and NextJS, the "Flight" protocol (used to communicate between the server and client) acts like a mailroom that blindly opens every package and follows any instructions inside immediately.

This vulnerability (CVE-2025-55182) allows an attacker to send a specifically crafted "package" (HTTP request) that forces your server to execute malicious code – like stealing passwords or installing viruses –without even logging in.

Why is this Happening Now?

It's all about how modern frameworks handle data serialization. There are a few reasons why this was just discovered.

First, React has complex serialization. To make Server Components seamless, React sends complex data structures back and forth.

Second, it has the "Flight" protocol. The vulnerability was found in how this specific protocol de-serializes (unpacks) data. It was too trusting of the input it received from the client side.

Should You Worry About this Change?

You need to pay attention if your app qualifies for any of the below:

• You are using NextJS App Router: This is the default in newer NextJS versions (v13+).

• You are using React 19: Specifically versions with Server Components enabled.

• You use Server Actions: If your app takes user input and processes it on the server using React's server actions.

Is this Mandatory?

Yes. This is a critical security update. If your app qualifies in any of the above scenarios, you need to act immediately. Because, this vulnerability is being exploited right now.

How Bad Can It Get? The Extent of Exploitation

You might be thinking, "My site is just a simple content wrapper, surely I'm not a target?" Unfortunately, with Remote Code Execution (RCE), the attacker doesn't just "break" your site – they own the server it runs on.

Here is exactly what a hacker can do once they exploit this vulnerability:

Total Environment Theft

The most immediate risk is your .env file. Attackers can execute code to read your environment variables, instantly gaining access to your AWS Secret Keys, Database passwords, Stripe API keys, and OpenAI tokens.

The "Shell" Access

As the name "React2Shell" implies, attackers can open a reverse shell. This gives them a command-line interface on your server, allowing them to browse your file system as if they were sitting in front of your computer.

Lateral Movement

Once inside your NodeJS server, they are behind your firewall. They can now attack your internal services (like Redis, internal databases, or private micro-services) that are usually blocked from the outside world.

Supply Chain Poisoning

If your build server is vulnerable, an attacker could potentially inject malicious code into your deployment pipeline, affecting every user who visits your site in the future.

Botnet Recruitment

Hackers often automate these attacks to install crypto-miners, using your server's CPU (which you pay for!) to mine digital currency for them, often crashing your application in the process.

What Would be the Code Change for This?

You don’t need to rewrite your application code, but you must update your dependencies in your release line.

The vulnerability is fully resolved in the following patched NextJS releases:

• 15.0.5

• 15.1.9

• 15.2.6

• 15.3.6

• 15.4.8

• 15.5.7

• 16.0.7

Patched canary releases for NextJS 15 and 16:

• 15.6.0-canary.58 (for 15.x canary releases)

• 16.1.0-canary.12 (for 16.x canary releases)

These versions include the hardened React Server Components implementation.

Here are the patched versions for React JS:

• 19.0.1

• 19.1.2

• 19.2.1

Frameworks and bundlers using the aforementioned packages should install the latest versions provided by their respective maintainers.

Alternatively, you can run npx fix-react2shell-next in your NextJS project to launch an interactive tool which can check versions and perform deterministic version bumps per the recommended versions above. See the GitHub repository for full details.

There is no workaround other than upgrading to a patched version.

It’s highly recommended to rotate all your application secrets, once you have patched your version and re-deployed your application.

Advanced: Verify with the Original Exploit (PoC)

If you want to be 100% sure your patch is working, or if you want to understand how the attack actually works, you can use the original Proof of Concept (PoC) created by the security researcher (Lachlan Davidson) who found the bug.

Repository: React2Shell-CVE-2025-55182-original-poc

Lachlan provided three variations of the exploit script. The most important one for testing is 01-submitted-poc.js, which is the exact, simplified version submitted to Meta for the bug bounty.

How the Exploit Works

According to the repository, the attack works by tricking the parser:

1. The attacker sends a payload using $@x to access a specific data Chunk.

2. They "plant" a .then function on a fake object.

3. The JavaScript runtime thinks it is handling a Promise and tries to "unravel" it.

4. This allows the attacker to re-enter the parser with a malicious fake chunk, giving them access to internal server gadgets (like _response) to execute code (RCE).

Steps to Recreate the Issue

⚠️ WARNING: Only run this against a local development server (localhost) that you own. Never run this against production servers or public websites.

Note: I forked Lachlan’s repo and made minor changes to make it easy for you to run the script.

Step 1: Clone the Repository

Run the following commands to clone the repository, navigate into the project, and install dependencies:

git clone https://github.com/arunachalam-b/React2Shell-CVE-2025-55182-original-poc.git
cd React2Shell-CVE-2025-55182-original-poc
npm i

Step 2: Run a Vulnerable Local Server

Start your NextJS application locally (ensure it’s running a vulnerable version, for example NextJS 15.0.0, for the test to succeed).

npm run dev
# usually runs on http://localhost:3000

Step 3: Execute the Test

You will need to modify the script or use a tool like curl to send the payload structure found in 01-submitted-poc.js to your server's endpoint (usually a Server Action endpoint). Or simply run the following command if your app is accessible at http://localhost:3000:

node 01-submitted-poc.js

If the exploit succeeds (on the vulnerable version), the console will log the execution of the code (RCE). If the exploit fails (after you patch), the server will either reject the request or error out safely.

You can also confirm if your infected web server prints 50 in the console. Because we inject the code to do a calculation (look at _prefix field in the below JSON) that results in 50.

After you apply the fix, you should see an error while running the script. In this case, as I’m using NextJS v15.1, the fix is upgrading the next package to version 15.1.9. Here are the screenshots after upgrading the package and running the script.

Step 4: Verification

Once you have confirmed the exploit works on the old version, update your packages (as shown in the section above) and run the script again. It should no longer trigger the code execution.

Emergency Response: What If You Were Already Compromised?

If you suspect your server was exposed to the internet with a vulnerable version, assume the worst. A hacker may have already stolen your keys or left a "backdoor" to return later. Patching the code alone is NOT enough in this case.

Follow this "Nuke and Pave" protocol immediately:

Step 1: Isolate and Shutdown

Take the compromised server offline immediately. Do not try to "fix" it while it is running.

Step 2: Rotate ALL Secrets (Crucial Step)

Assume every secret in your .env file is in the hands of a hacker. You must generate new ones:

• Change the password for your database users.

• Rotate AWS Access Keys, Google Cloud Service Account keys, and so on.

• Roll your Stripe/PayPal/Razorpay API keys.

• Rotate your NEXTAUTH_SECRET or any JWT signing keys.

Step 3: Do Not "Clean" — Rebuild

Do not attempt to find and delete malware files on the server. Hackers are good at hiding.

• Destroy the existing container, droplet, or EC2 instance entirely.

• Build a fresh instance from your source code (after applying the patch).

Step 4: Audit Your Logs

Look at your database and cloud provider logs. Did anyone download your entire user database? Did anyone spin up expensive GPU instances on your AWS account? Check for unusual activity that occurred before you patched.

Conclusion

In this article, you learned about the "React2Shell" vulnerability, how to verify it using the original developer's tools, and how to upgrade your app to secure your Server Components. I hope you have a clear idea about why this update is urgent. By being proactive now, you can avoid a catastrophic data breach.

You can follow my Twitter/X account to receive the top AI news everyday. If you wish to learn more about cybersecurity, subscribe to my email newsletter and follow me on social media.

Both hide your IP address and help you browse the internet more privately, but they work in different ways and serve different purposes. From simple security to web scraping for LLM training, both serve various purposes for businesses.

If you have ever wondered which one you should use, this article will help you understand how they work, their main differences, and where residential proxies fit into the picture.

What We’ll Cover

• What is a VPN?

• What is a Proxy?

• The Core Difference Between VPNs and Proxies

• Performance and Speed

• Use Cases for VPNs

• Use Cases for Proxies

• How to Combine VPNs and Residential Proxies

• Which One Should You Choose?

• The Future of Privacy Tools

• Conclusion

What is a VPN?

A Virtual Private Network, or VPN, is a service that creates a secure and encrypted tunnel between your device and the internet.

When you connect to a VPN, all your traffic passes through a remote server operated by the VPN provider. This hides your real IP address and encrypts everything you send or receive.

VPNs are often used by individuals who want to protect their privacy or access content that is restricted in their region.

For example, someone in India can use a VPN to connect to a U.S. server and access websites that are available only in the United States. Because the connection is encrypted, internet service providers and hackers cannot see which websites you visit or what data you exchange.

What is a Proxy?

A proxy acts as a middleman between your device and the internet.

When you connect to a proxy, your request is first sent to the proxy server, which then forwards it to the target website. The website sees the proxy’s IP address instead of your own.

Unlike VPNs, proxies usually do not encrypt your traffic. This means that while your IP address is hidden, the data itself can still be visible to others.

Proxies are often used for tasks like web scraping, managing multiple social media accounts, or accessing geo-restricted sites in a lightweight way.

There are different types of proxies, such as datacenter proxies, mobile proxies, and residential proxies. Among these, residential proxies are the most trusted because they use real IP addresses assigned by internet service providers.

The Core Difference Between VPNs and Proxies

The biggest difference between a VPN and a proxy lies in encryption.

VPNs encrypt all network traffic from your device, while most proxies do not. This means VPNs provide a higher level of security and privacy. Even if someone intercepts your data, they cannot read it.

Proxies, on the other hand, focus more on IP masking rather than full encryption. They are lighter, faster, and more flexible for specific use cases like automation, scraping, or content testing.

For example, a company that needs to collect product data from multiple e-commerce sites will use residential proxies rather than a VPN because proxies allow scalable, distributed access from different IP addresses.

Another key difference is the level of system-wide protection. A VPN encrypts all the traffic coming from your device, including background apps.

A proxy typically only routes traffic from specific browsers or applications. This makes VPNs better for personal privacy and proxies better for targeted tasks.

Performance and Speed

Since VPNs encrypt traffic, they can reduce speed due to the extra processing involved. Proxies, by contrast, are often faster because they skip encryption and route only specific requests.

However, not all proxies are equal. Datacenter proxies may be fast but easier to detect, while residential proxies are slower but far more reliable for tasks that require realism. Businesses often accept this small trade-off in speed for better accuracy and reduced blocking.

VPNs usually have fewer IPs and servers compared to proxy networks, which can limit their flexibility. Proxies can rotate thousands of IPs automatically, which helps avoid bans and distribute requests efficiently.

Use Cases for VPNs

VPNs are ideal for individuals who value security and privacy. They are useful for browsing safely on public Wi-Fi, accessing restricted websites, or hiding browsing habits from internet service providers.

Remote workers often use VPNs to securely access corporate networks. Journalists and activists rely on them to bypass censorship or protect communication in restrictive regions.

For everyday users, a VPN provides a simple and effective way to browse anonymously and encrypt all data traffic.

Use Cases for Proxies

Proxies shine in automation and business scenarios. They are essential for data gathering, web scraping, and digital marketing. By using residential proxies, companies can collect information from multiple websites without getting blocked.

For example, a brand can track how its ads appear to users in different countries. E-commerce businesses can compare competitor prices or monitor product listings in real time. Social media managers use proxies to handle multiple accounts without triggering platform restrictions.

Proxies also help in large-scale web scraping for LLM training. They allow businesses to gather public data anonymously and at scale without getting blocked or throttled by websites.

How to Combine VPNs and Residential Proxies

In some cases, professionals use both. For example, a researcher may connect to a VPN for encryption and then route specific scraping tasks through residential proxies for location diversity. This hybrid setup balances privacy and data collection efficiency.

Combining them also reduces the risk of IP bans. If a target site starts blocking one set of IPs, the user can switch networks seamlessly. This approach is popular in cybersecurity testing, ad verification, and large-scale monitoring.

Which One Should You Choose?

If your goal is privacy, use a VPN. It secures your entire connection and hides all your online activities. If your goal is automation, data collection, or region-specific testing, use proxies.

Residential proxies are especially effective when websites have strong anti-bot protection or region-based restrictions. They combine anonymity with authenticity, making your traffic look like that of a regular home user.

For individuals who need both security and flexibility, a mix of VPN and proxy can work best. You can encrypt your connection with a VPN and use residential proxies for specific tools or scripts that need rotation and scale.

The Future of Privacy Tools

As online tracking becomes more advanced, tools like VPNs and residential proxies are becoming essential for both individuals and businesses. Companies use them to access unbiased market data and protect digital assets, while individuals use them to browse safely and privately.

In the future, we may see hybrid solutions that blend the privacy of VPNs with the scalability of proxy networks. These systems could automatically switch between encryption and proxy routing based on the task at hand, providing a seamless balance between speed and security.

Conclusion

VPNs and proxies both protect your identity online, but they serve different purposes. VPNs focus on privacy and encryption, while proxies , especially residential proxies , focus on scalability and access.

Understanding how each works helps you choose the right tool for your needs. Whether you want to stay anonymous, collect data safely, or test websites from different countries, using the right combination of VPN and residential proxies can give you both privacy and power in the digital world.

Hope you enjoyed this article. Find me on Linkedin or visit my website.

Every year, more companies face threats that put their data, reputation, and customer trust at risk. As these threats grow, so does the demand for skilled cybersecurity professionals.

One of the best ways to stand out in this competitive field is to earn a recognised certification. Certifications not only validate your skills but also open doors to better job opportunities, higher pay, and global recognition.

In this article, we will look at the top five cybersecurity certifications that can help you build or advance your career. Whether you are new to cybersecurity or already working in the field, these certifications can take your skills and credibility to the next level.

What we Cover

• Certified Information Systems Security Professional (CISSP)

• Certified Information Security Manager (CISM)

• Certified Ethical Hacker (CEH)

• CompTIA Security+

• Offensive Security Certified Professional (OSCP)

• Choosing the Right Certification

• Conclusion

Certified Information Systems Security Professional (CISSP)

The CISSP, offered by (ISC)², is considered one of the most prestigious certifications in cybersecurity. It’s designed for experienced professionals who want to prove their ability to design, implement, and manage an enterprise-level security program.

CISSP is often seen as a leadership certification rather than a purely technical one. It demonstrates a deep understanding of security principles across multiple domains, including areas such as security and risk management, asset security, security architecture and engineering, communication and network security, identity and access management, security assessment and testing, security operations, and software development security.

Together, these eight domains cover every major aspect of protecting an organization’s information systems. Several security agencies have highlighted the importance of CISSP certification, so it’s an expected certification if you are looking for senior-level security roles.

To earn the CISSP, you need at least five years of professional experience in two or more of these domains. The exam itself is challenging and is designed to test not just what you know, but how you apply that knowledge in complex, real-world scenarios. It requires you to think both technically and strategically, balancing hands-on expertise with business and management considerations.

Even if you don’t yet meet the experience requirement, you can still pass the exam and become an Associate of (ISC)². Once you complete the necessary work experience, you can upgrade to a full CISSP.

CISSP holders are often found in senior roles such as Chief Information Security Officer, Security Architect, or IT Director. Employers worldwide value this certification because it demonstrates your understanding of both the technical and organisational aspects of cybersecurity.

If your goal is to move into senior management or to lead enterprise-wide security programs, CISSP remains one of the most respected and valuable certifications you can pursue.

Certified Information Security Manager (CISM)

The CISM, managed by ISACA, is a globally recognized certification for professionals who manage, design, and oversee an enterprise’s information security program. It’s particularly valuable for those who want to move from technical roles into management.

CISM focuses on four main areas: information security governance, risk management, program development and management, and incident management. These domains reflect the skills required to align an organization’s security strategy with its overall business goals.

Unlike certifications that focus mainly on technical details, CISM emphasizes the connection between business needs and security policies. It prepares you to communicate effectively with senior management and to justify security investments in terms of business outcomes.

Industry leaders like DestCert have highlighted the importance of the CISM certification for its role in shaping professionals who understand both the technical and strategic sides of cybersecurity. As organizations increasingly seek leaders who can balance risk, compliance, and technology, the demand for CISM-certified experts continues to grow.

To earn the CISM, you need at least five years of experience in information security management, with at least three years of experience in at least three of the four CISM domains. After passing the exam, you also need to agree to ISACA’s code of ethics and commit to continuing education to keep your certification active.

Certified Ethical Hacker (CEH)

The CEH certification, offered by EC-Council, is one of the most recognized credentials for those who want to specialize in ethical hacking and penetration testing. It teaches you how to think like a hacker, identify vulnerabilities, and secure systems before attackers can exploit them.

CEH covers topics such as footprinting, scanning, enumeration, system hacking, web application hacking, and social engineering. The goal is to understand the attacker’s mindset so you can defend more effectively. It also includes hands-on labs that allow you to practice hacking techniques in a controlled environment.

This certification is often the first step for many cybersecurity professionals who want to move into roles such as penetration tester, red team member, or security analyst. It demonstrates that you know how to identify weaknesses and apply countermeasures to protect systems and data. Since it’s a beginner certification, there are often questions whether CEH is worth taking. But it is still the most widely known cybersecurity certification in existence.

Employers value CEH because it bridges the gap between theory and practice. While it’s not as advanced as some other certifications, it provides a solid foundation for anyone interested in offensive security. If you are looking to start a career in ethical hacking or penetration testing, CEH is an excellent choice.

CompTIA Security+

CompTIA Security+ is one of the most widely accepted entry-level certifications in cybersecurity. It’s ideal for beginners who want to establish a strong foundation in security concepts before moving on to advanced certifications.

Security+ covers essential topics such as threat management, cryptography, risk management, identity management, and incident response. It also focuses on practical skills needed to perform day-to-day security tasks. Unlike some certifications that require extensive experience, Security+ is accessible to anyone with a basic understanding of networking and IT systems.

The certification is vendor-neutral, which means it applies to a broad range of technologies rather than being tied to a specific company or product. Many organizations use it as a benchmark for hiring junior security professionals or system administrators.

Security+ is also approved by the U.S. Department of Defense for its cybersecurity workforce, which further adds to its credibility. Passing the exam shows that you understand the key principles of cybersecurity and are ready to take on entry-level security roles.

After earning Security+, many professionals go on to pursue more advanced certifications such as CISSP or CISM. It serves as a perfect starting point for building a long-term cybersecurity career.

Offensive Security Certified Professional (OSCP)

The Offensive Security Certified Professional (OSCP), offered by Offensive Security, is one of the most respected certifications in the field of ethical hacking and penetration testing. Known for its hands-on and highly practical nature, the OSCP sets a high standard for proving real-world hacking skills.

Unlike many certifications that focus on theory or multiple-choice questions, the OSCP exam challenges you to demonstrate your ability to find and exploit vulnerabilities in live machines within a controlled environment. It requires you to hack into multiple systems, gain administrative access, and document your process in a professional penetration testing report.

The OSCP exam is widely regarded as one of the toughest in cybersecurity. Candidates are given 24 hours to complete the test, during which they must identify, exploit, and escalate privileges across different targets. This format tests not only your technical knowledge but also your persistence, creativity, and problem-solving skills.

Earning the OSCP shows that you can think like an attacker, apply advanced exploitation techniques, and work methodically under pressure. It’s ideal for people who want to advance their careers in offensive security, red teaming, or penetration testing. Common job roles for OSCP holders include penetration tester, security consultant, red team operator, and exploit developer.

The OSCP focuses on practical skills such as network scanning, enumeration, buffer overflows, privilege escalation, and pivoting through networks. The accompanying course, “Penetration Testing with Kali Linux (PWK),” provides comprehensive training that helps candidates prepare for the exam by learning through real-world scenarios.

Employers value the OSCP because it demonstrates more than just knowledge. It also proves your ability to apply that knowledge in complex, hands-on situations. Many in the cybersecurity industry consider it a rite of passage for ethical hackers and a mark of true technical skill.

If your goal is to become an advanced penetration tester or to build deep technical expertise in offensive security, earning the OSCP is one of the most rewarding certifications you can pursue.

Choosing the Right Certification

Selecting the right certification depends on your current experience and career goals. If you are new to cybersecurity, CompTIA Security+ is a great place to start. If you already have some experience and want to specialize in ethical hacking, the CEH will help you build practical offensive skills.

For those aiming for leadership and management positions, CISM and CISSP are both excellent choices. CISM focuses on aligning security with business strategy, while CISSP focuses on designing and managing enterprise-wide security programs. If your career involves core technical expertise, the OSCP is a natural next step.

Each certification not only validates your technical skills but also strengthens your reputation as a trusted cybersecurity professional. Employers often use certifications as a signal of commitment and capability, making them a valuable investment in your career.

Conclusion

Cybersecurity is a field that never stops evolving. New threats emerge every day, and the technology used to defend against them changes just as quickly. To stay relevant and competitive, you’ll need to keep learning and proving your expertise. This will help you both advance your career and be prepared to defend what matters most.

Hope you enjoyed this article. Find me on Linkedin or visit my website

It's taught by one of the world's most-loved computer science teachers, Dr. David J. Malan.

In this course, you’ll learn how to secure your accounts, data, systems, and software against today’s threats. You’ll also learn how to recognize and evaluate tomorrow’s, both at home and at work. Then you’ll learn how to preserve your own privacy as well.

This course teaches you how to view cybersecurity not in absolute terms but in relative ones as well: as a function of risks and rewards (for an adversary) and costs and benefits (for you).

Dr. Malan presents both high-level and low-level examples of threats, providing students with all they need to know technically to understand both.

Here are the sections in this course:

• Introduction

• Securing Accounts

• Securing Data

• Securing Systems

• Securing Software

• Preserving Privacy

Watch the course on the freeCodeCamp.org YouTube channel (8-hour watch).

In this tutorial, you’ll build a distributed rate limiter. This is the kind of system you need when your application is deployed across multiple servers or virtual machines, and you need to enforce a global limit on all incoming requests.

You’ll build a simple URL shortener application and then implement a robust rate limiter for it using a powerful and efficient combination of tools:

• Python and Flask for your web application.

• Redis as your high-speed, centralized data store for tracking requests.

• Terraform and Proxmox to define and provision your virtual machine infrastructure.

• Docker to containerize your application for easy deployment.

• Nginx as a load balancer to distribute traffic across your app servers.

• k6 to load-test your system and prove that your rate limiter actually works.

This is intended for new developers learning about various system design concepts or for experts who just want a refresher.

By the end of this guide, you'll understand not just the code, but the complete system architecture required to deploy a scalable, resilient application.

Let's get started!

Prerequisites

While not absolutely required to follow along, I’d recommend setting up a Proxmox server on an old laptop to implement the topics you learn and code along with the article. I recommend this YouTube playlist for getting started. Please note that I am in no way affiliated with this channel. I just found it helpful for me.

However, If you do not have a local Proxmox server, you can skip that part and just follow along to understand how a rate limiter is built and how it is set up to properly work with multiple servers.

Table of Contents

• Prerequisites

• The Big Picture: Our System Architecture

• Step 1: How to Define the Infrastructure with Terraform

• Step 2: How to Implement the Rate Limiter Logic in Python

• Step 3: Containerizing and Testing

• Conclusion

The Big Picture: Our System Architecture

Before we dive into the code, let's look at the architecture we're building. I will be using Proxmox Virtual Environment to setup a server cluster just like you would have in a datacenter.

How to Set Up Proxmox

Proxmox Virtual Environment is an open source platform for virtualization. It lets you manage multiple VMs, ccontainers and other clusters with ease. For instance, I turned my old gaming computer into a Proxmox server which lets me run more than 20 virtual machines on it at the same time, making it similar to my very own datacenter. This lets me experiment with distributed applications by simulating datacenter environments.

To setup your own cluster, all you need is an old computer. You can download the ISO image from here and boot from the USB drive. Once you install it, you can configure the host machine via a web browser on any other computer on the same network.

For example, my proxmox server is located at 10.0.0.108 and I can access it via the browser on my laptop.

We define all our virtual machines in our main.tf file. And run a simple command terraform apply to spin these servers up. For more reading on how to use Terraform with Proxmox, I recommend this blog post

Back to our use case, we’ll have a few virtual machines that will serve as different kinds of servers:

1. A Load balancer

2. A Rate Limiter ( A Redis Cache )

3. Two Web Servers

4. A Postgres database

5. One Virtual Machine that will test the load by simulating hundreds of calls per minute.

If all of this seems daunting, don’t worry too much about it. You don’t need to set all this up to follow along.

Centralized Rate Limiter

Since our application will run on multiple servers (or "nodes"), we can't store request counts in memory on each individual server. Why? Because each server would have its own separate count, and we wouldn't have a global rate limit.

The solution is to use a centralized data store that all our application nodes can access. This is where Redis comes in.

Here’s a diagram of our setup:

1. User requests first hit our Nginx load balancer.

2. The load balancer distributes the traffic evenly between our two web server VMs. The configuration is simple, using an upstream block to define the servers.

3. Each web server runs our Python Flask application inside a Docker container.

4. Before processing any request, the Flask app communicates with the central Redis rate limiter VM to check if the user has exceeded the rate limit.

5. If the user is within the limit, the app processes the request and interacts with the PostgreSQL Database. If they're over the limit, it sends back a “429 Too Many Requests” error.

This architecture ensures that no matter which web server handles the request, the rate limit is checked against the same, shared data source.

Step 1: How to Define the Infrastructure with Terraform

Manually setting up multiple virtual machines can be tedious and prone to errors. That's why we use Terraform, an Infrastructure as Code (IaC) tool. It lets us define our entire infrastructure in configuration files.

Note: You can skip this section if you just want to see the rate limiter in action and how it’s used.

Our main.tf file defines all the components of our system. Let's look at a key piece: the Redis VM.

# --- Redis Cache for Rate Limiter ---
resource "proxmox_vm_qemu" "redis_cache" {

    vmid        = 130
    name        = "redis-cache-rate-limiter"
    target_node = "pve"
    agent       = 1
    cores       = 1
    memory      = 1024
    # ... cloud-init config ...
    ipconfig0  = "ip=10.0.0.130/24,gw=10.0.0.1"
    # ... disk and network config ...

    # 1. Install Docker
    provisioner "remote-exec" {
        inline = [
            "sleep 30; sudo apt-get update -y",
            "sudo apt-get install -y docker.io docker-compose",
            "sudo mkdir -p /opt/redis"
        ]
    }

    # 2. Upload docker-compose file
    provisioner "file" {
         source      = "files/redis-docker-compose.yml"
         destination = "/home/${var.ssh_user}/docker-compose.yml"
    }

    # 3. Move file and run docker-compose
    provisioner "remote-exec" {
        inline = [
            "sudo mv /home/${var.ssh_user}/docker-compose.yml /opt/redis/docker-compose.yml",
            "cd /opt/redis && sudo docker-compose up -d"
        ]
    }
}

This block tells Terraform to create a Proxmox QEMU virtual machine with a specific IP address (10.0.0.130). After the VM is created, it uses provisioners to connect via SSH and run commands. Here, it installs Docker, uploads our redis-docker-compose.yml file, and starts the Redis container.

The redis-docker-compose.yml itself is very straightforward:

version: '3.8'
services:
  redis:
    image: redis:latest
    container_name: redis_cache
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - redisdata:/data

volumes:
  redisdata:

This ensures we have a persistent, containerized Redis instance ready to serve our application. The Terraform configuration similarly defines our web servers, load balancer, and databases.

Step 2: How to Implement the Rate Limiter Logic in Python

Now, for the heart of our system: the Python code that implements the rate limiting logic. We're using a sophisticated and memory-efficient algorithm called the Sliding Window Log.

The idea is simple: for each user, we keep a log of the timestamps of their recent requests. We store this log in a Redis Sorted Set.

Let's break down the code from app.py.

The Flask @app.before_request Hook

Flask allows us to run code before any request is handled by its intended view function. This is the perfect place to put our rate limiter.

import psycopg2
import string
import random
import redis
import time
from flask import Flask, request, redirect, jsonify

app = Flask(__name__)

# --- Database Connection Details ---
DB_HOST = "10.0.0.200" 
DB_NAME = "urldb"
DB_USER = "myuser"
DB_PASS = "mypassword"

REDIS_HOST = "10.0.0.130" # IP of your redis-cache-lxc

# --- Rate Limiter Settings ---
RATE_LIMIT_COUNT = 10  # 10 requests
RATE_LIMIT_WINDOW = 60 # per 60 seconds

# Establish a reusable Redis connection
redis_client = redis.Redis(host=REDIS_HOST, port=6379, decode_responses=True)

@app.before_request
def rate_limiter():
    # Use the user's IP address as the key
    # In a real app, you'd handle proxies via request.environ.get('HTTP_X_FORWARDED_FOR', request.remote_addr)
    key = f"rate_limit:{request.remote_addr}"
    now = time.time()

    # Use a Redis pipeline for atomic operations
    pipe = redis_client.pipeline()
    # 1. Add current request timestamp. The score and member are the same.
    pipe.zadd(key, {str(now): now})
    # 2. Remove all timestamps older than our window
    pipe.zremrangebyscore(key, 0, now - RATE_LIMIT_WINDOW)
    # 3. Get the count of remaining timestamps
    pipe.zcard(key)
    # 4. Set an expiration on the key so it cleans itself up
    pipe.expire(key, RATE_LIMIT_WINDOW)

    # Execute the pipeline and get the results
    results = pipe.execute()
    request_count = results[2] # The result of the zcard command

    if request_count > RATE_LIMIT_COUNT:
        # Return a 429 Too Many Requests error
        return jsonify(error="Rate limit exceeded"), 429

def get_db_connection():
    conn = psycopg2.connect(host=DB_HOST, dbname=DB_NAME, user=DB_USER, password=DB_PASS)
    return conn

def init_db():
    conn = get_db_connection()
    cur = conn.cursor()
    cur.execute('''
        CREATE TABLE IF NOT EXISTS urls (
            id SERIAL PRIMARY KEY,
            short_code VARCHAR(6) UNIQUE NOT NULL,
            original_url TEXT NOT NULL
        );
    ''')
    # Check if the index exists before creating it
    cur.execute('''
        SELECT 1 FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace
        WHERE c.relname = 'idx_original_url' AND n.nspname = 'public';
    ''')
    if cur.fetchone() is None:
        cur.execute('CREATE INDEX idx_original_url ON urls (original_url);')
    conn.commit()
    cur.close()
    conn.close()

def generate_short_code(length=6):
    chars = string.ascii_letters + string.digits
    return ''.join(random.choice(chars) for _ in range(length))

@app.route("/", methods=['GET'])
def index():
    return "URL Shortener is running!\n", 200

@app.route('/shorten', methods=['POST'])
def shorten_url():
    original_url = request.form['url']
    conn = get_db_connection()
    cur = conn.cursor()

    cur.execute("SELECT short_code FROM urls WHERE original_url = %s", (original_url,))
    existing_url = cur.fetchone()

    if existing_url:
        short_code = existing_url[0]
    else:
        short_code = generate_short_code()
        cur.execute("INSERT INTO urls (short_code, original_url) VALUES (%s, %s)", (short_code, original_url))
        conn.commit()

    cur.close()
    conn.close()

    return jsonify(short_url=f"/{short_code}")

@app.route('/<short_code>')
def redirect_to_url(short_code):
    conn = get_db_connection()
    cur = conn.cursor()
    cur.execute("SELECT original_url FROM urls WHERE short_code = %s", (short_code,))
    url_record = cur.fetchone()
    cur.close()
    conn.close()

    if url_record:
        return redirect(url_record[0])
    else:
        return "URL not found", 404

if __name__ == '__main__':
    init_db() 
    app.run(host='0.0.0.0', port=5000)

How It Works, Step-by-Step

1. Identify the User: We create a unique Redis key for each user based on their IP address: rate_limit:1.2.3.4.

2. Use a Pipeline: Network latency can be a bottleneck. A Redis pipeline bundles multiple commands into a single request-response cycle. This is much more efficient than sending them one by one. It also ensures the sequence of commands runs without being interrupted by commands from other clients.

3. Log the Current Request (ZADD): We add the current timestamp (as a Unix epoch) to a sorted set. We use the timestamp for both the "member" and the "score," which allows us to easily filter by time.

4. Clean Up Old Requests (ZREMRANGEBYSCORE): This is the "sliding window" part. We remove any timestamps from the set that are older than our RATE_LIMIT_WINDOW (60 seconds). This efficiently discards requests that are no longer relevant to the current rate limit period.

5. Count the Recent Requests (ZCARD): We get the cardinality (the number of items) in the set. After the previous step, this number is our count of requests within the last 60 seconds.

6. Mark the current record to expire (EXPIRE): We set an expiration on the key itself. If a user stops making requests, Redis will automatically delete their rate limit data after 60 seconds, preventing memory from filling up with old keys.

7. Execute and Check: The pipe.execute() command sends all our bundled commands to Redis. We then check the result of our ZCARD command. If the count exceeds our RATE_LIMIT_COUNT, we immediately return a 429 error.

This approach is incredibly fast and efficient. All the heavy lifting is done inside Redis, which is optimized for these kinds of operations.

Step 3: Containerizing and Testing

To deploy our application consistently across multiple VMs, we use Docker. Our Dockerfile is standard for a Python application: it starts from a Python image, installs dependencies from requirements.txt, copies the application code, and defines the command to run the app.

But how do we know it works? We test it!

We use k6, a modern load testing tool, to simulate heavy traffic. Our test script, rate-test.js, is designed specifically to verify the rate limiter.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    // Ramp up to 20 users. This is more than the 10 req/min limit
    // and should trigger the rate limiter.
    { duration: '30s', target: 20 },
    { duration: '1m', target: 20 },
    { duration: '10s', target: 0 },
  ],
};

export default function () {
  const url = 'http://10.0.0.100/shorten'; // The Load Balancer IP
  const payload = { url: `https://www.test-ratelimit-${Math.random()}.com` };

  const res = http.post(url, payload);

  // Check if the request was successful OR if it was correctly rate-limited
  check(res, {
    'status is 200 (OK)': (r) => r.status === 200,
    'status is 429 (Too Many Requests)': (r) => r.status === 429,
  });

  sleep(1);
}

The stages array configures the test to gradually increase the number of virtual users to 20. Since our rate limit is 10 requests per minute, this load is guaranteed to trigger the limiter.

The check function is the crucial part. It verifies that the server's response code is either 200 (meaning the request was successful) or 429 (meaning our rate limiter correctly blocked the request).

We should see about 10 of our requests go through of the around 1600 requests per minute that we send from the same IP address.

We can also check the logs on our webserver to see all the requests that were sent to it.

And if we look at the Redis cache/database itself, we’ll see all the keys and the TTL at which they expire.

This is how we rate limit applications using a Redis Cache Server.

Here are the complete files used in the project.

    terraform {
    required_providers {
        proxmox = {
        source  = "telmate/proxmox"
        version = "3.0.2-rc04"
        }
    }
    }

    provider "proxmox" {
    pm_api_url          = var.proxmox_api_url
    pm_api_token_id     = var.proxmox_api_token_id
    pm_api_token_secret = var.proxmox_api_token_secret
    pm_tls_insecure     = true
    }

    # --- Shared Provisioner Connection Settings ---
    locals {
        connection_settings = {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
        }
    }

    # --- Database LXC Containers ---
    resource "proxmox_lxc" "postgres_db" {
    hostname     = "postgres-db-lxc"
    target_node  = var.target_node
    ostemplate   = var.lxc_template

    rootfs {
        storage = "local-lvm"
        size = "8G"
    }

    password     = "admin"
    unprivileged = true
    start        = true

    features {
        nesting = true
        # keyctl = true
    }

    network {
        name   = "eth0"
        bridge = "vmbr0"
        ip     = "10.0.0.200/24"
        gw     = "10.0.0.1"
    }

    provisioner "remote-exec" {
        connection {
        type        = "ssh"
        user        = var.ssh_user
        private_key = file(var.ssh_private_key_path)
        host        = split("/", self.network[0].ip)[0]
        }
        inline = [
        "sudo apt-get update",
        "sudo apt-get install -y docker.io docker-compose python3-setuptools",
        "sudo usermod -aG docker ${var.ssh_user}",
        "sudo mkdir -p /opt/postgres",
        "sudo chown ${var.ssh_user}:${var.ssh_user} /opt/postgres"
        ]
    }

    provisioner "file" {
        connection {
        type        = "ssh"
        user        = var.ssh_user
        private_key = file(var.ssh_private_key_path)
        host        = split("/", self.network[0].ip)[0]
        }
        source      = "../databases/pg-docker-compose.yml"
        destination = "/opt/postgres/docker-compose.yml"
    }

    provisioner "remote-exec" {
        inline     = ["cd /opt/postgres && sudo docker-compose up -d"]

        connection {
        type        = "ssh"
        user        = var.ssh_user
        private_key = file(var.ssh_private_key_path)
        host        = split("/", self.network[0].ip)[0]
        }
    }
    }

    resource "proxmox_lxc" "mongo_db" {
        hostname    = "mongo-db-lxc"
        target_node = var.target_node
        ostemplate  = var.lxc_template

        rootfs {
            storage = "local-lvm"
            size = "8G"
        }

        password    = "admin"
        unprivileged = true
        start       = true

        features {
            nesting = true
        # keyctl = true # Somehow this is blocking the apply command
        }

        network {
            name   = "eth0"
            bridge = "vmbr0"
            ip     = "10.0.0.210/24"
            gw     = "10.0.0.1"
        }

        # Provisioners similar to postgres_db
        provisioner "remote-exec" {
            connection {
                type        = "ssh"
                user        = var.ssh_user
                private_key = file(var.ssh_private_key_path)
                host        = split("/", self.network[0].ip)[0]
            }
            inline = [
            "sudo apt-get update",
            "sudo apt-get install -y docker.io docker-compose python3-setuptools",
            "sudo usermod -aG docker ${var.ssh_user}",
            "sudo mkdir -p /opt/mongo",
            "sudo chown ${var.ssh_user}:${var.ssh_user} /opt/mongo"
            ]
        }

        provisioner "file" {
            connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = split("/", self.network[0].ip)[0]
            }
            source      = "../databases/mongo-docker-compose.yml"
            destination = "/opt/mongo/docker-compose.yml"
        }

        provisioner "remote-exec" {
            connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = split("/", self.network[0].ip)[0]
            }
            inline     = ["cd /opt/mongo && docker-compose up -d"]
        }
    }

    # --- Redis Cache for Rate Limiter ---
    resource "proxmox_vm_qemu" "redis_cache" {

        vmid        = 130
        name        = "redis-cache-rate-limiter"
        target_node = "pve"
        agent       = 1
        cpu {
            cores       = 1
        }

        memory      = 1024
        boot        = "order=scsi0" # has to be the same as the OS disk of the template
        clone       = "debian12-cloudinit" # The name of the template
        scsihw      = "virtio-scsi-single"
        vm_state    = "running"
        automatic_reboot = true

        # Cloud-Init configuration
        cicustom   = "vendor=local:snippets/qemu-guest-agent.yml" # /var/lib/vz/snippets/qemu-guest-agent.yml
        ciupgrade  = true
        nameserver = "1.1.1.1 8.8.8.8"
        ipconfig0  = "ip=10.0.0.130/24,gw=10.0.0.1"
        skip_ipv6  = true
        ciuser     = var.ssh_user
        cipassword = var.ssh_password
        sshkeys    = var.ssh_key

        # Most cloud-init images require a serial device for their display
        serial {
            id = 0
        }

        disks {
            scsi {
            scsi0 {
                # We have to specify the disk from our template, else Terraform will think it's not supposed to be there
                disk {
                storage = "local-lvm"
                # The size of the disk should be at least as big as the disk in the template. If it's smaller, the disk will be recreated
                size    = "5G" 
                }
            }
            }
            ide {
            # Some images require a cloud-init disk on the IDE controller, others on the SCSI or SATA controller
            ide1 {
                cloudinit {
                storage = "local-lvm"
                }
            }
            }
        }

        network {
            id = 0
            bridge = "vmbr0"
            model  = "virtio"
        }

        connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = "10.0.0.130"
        }

        # 1. Install Docker and create the final app directory
        provisioner "remote-exec" {
            inline = [
                # Wait for cloud-init to finish before doing anything else
                "echo 'Waiting for cloud-init to finish...'",
                "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Still waiting...' && sleep 1; done",
                "echo 'Cloud-init finished.'",

                # Now, safely install packages
                "sudo apt-get update -y",
                "sudo apt-get install -y docker.io docker-compose",
                "sudo mkdir -p /opt/redis",
            ]
        }

        provisioner "file" {
            source      = "../caching/redis-docker-compose.yml"
            destination = "/home/${var.ssh_user}/docker-compose.yml"
        }

        provisioner "remote-exec" {
            inline = [ "sudo mv /home/${var.ssh_user}/docker-compose.yml /opt/redis/docker-compose.yml" ]
        }

        provisioner "remote-exec" {
            inline = [ "cd /opt/redis && sudo docker-compose up -d" ]
        }
    }

    resource "proxmox_vm_qemu" "web-servers" {

        count = 2

        vmid        = count.index + 150
        name        = "web-server-tf-${count.index + 1}"
        target_node = "pve"
        agent       = 1
        cpu {
            cores       = 1
        }
        memory      = 1024
        boot        = "order=scsi0" # has to be the same as the OS disk of the template
        clone       = "debian12-cloudinit" # The name of the template
        scsihw      = "virtio-scsi-single"
        vm_state    = "running"
        automatic_reboot = true

        # Cloud-Init configuration
        cicustom   = "vendor=local:snippets/qemu-guest-agent.yml" # /var/lib/vz/snippets/qemu-guest-agent.yml
        ciupgrade  = true
        nameserver = "1.1.1.1 8.8.8.8"
        ipconfig0  = "ip=10.0.0.${111 + count.index}/24,gw=10.0.0.1"
        skip_ipv6  = true
        ciuser     = var.ssh_user
        cipassword = var.ssh_password
        sshkeys    = var.ssh_key

        # Most cloud-init images require a serial device for their display
        serial {
            id = 0
        }

        disks {
            scsi {
            scsi0 {
                # We have to specify the disk from our template, else Terraform will think it's not supposed to be there
                disk {
                storage = "local-lvm"
                # The size of the disk should be at least as big as the disk in the template. If it's smaller, the disk will be recreated
                size    = "5G" 
                }
            }
            }
            ide {
            # Some images require a cloud-init disk on the IDE controller, others on the SCSI or SATA controller
            ide1 {
                cloudinit {
                storage = "local-lvm"
                }
            }
            }
        }

        network {
            id = 0
            bridge = "vmbr0"
            model  = "virtio"
        }

        connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = "10.0.0.${111 + count.index}"
        }

        # 1. Install Docker and create the final app directory
        provisioner "remote-exec" {
            inline = [
                # Wait for cloud-init to finish before doing anything else
                "echo 'Waiting for cloud-init to finish...'",
                "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Still waiting...' && sleep 1; done",
                "echo 'Cloud-init finished.'",

                # Now, safely install packages
                "sudo apt-get update -y",
                "sudo apt-get install -y docker.io",
                "sudo mkdir -p /opt/app",
            ]
        }

        # 2. Upload ONLY the necessary files to the user's home directory
        provisioner "file" {
            source      = "../web-servers/app.py"
            destination = "/home/${var.ssh_user}/app.py"
        }
        provisioner "file" {
            source      = "../web-servers/Dockerfile"
            destination = "/home/${var.ssh_user}/Dockerfile"
        }
        provisioner "file" {
            source      = "../web-servers/requirements.txt"
            destination = "/home/${var.ssh_user}/requirements.txt"
        }

        # 4. Move files from the home directory, build the image, and run the container
        provisioner "remote-exec" {
            inline = [
                # Move each file individually to be compatible with all shells
                "sudo mv /home/${var.ssh_user}/app.py /opt/app/",
                "sudo mv /home/${var.ssh_user}/Dockerfile /opt/app/",
                "sudo mv /home/${var.ssh_user}/requirements.txt /opt/app/",

                # Build the Docker image
                "sudo docker build -t my-python-app /opt/app",

                # Stop and remove any old containers to prevent conflicts
                "sudo docker stop $(sudo docker ps -q --filter ancestor=my-python-app) 2>/dev/null || true",
                "sudo docker rm $(sudo docker ps -aq --filter ancestor=my-python-app) 2>/dev/null || true",

                # Run the new container
                "sudo docker run -d --restart always -p 80:5000 my-python-app"
            ]
        }

        # In your proxmox_vm_qemu "web_servers" resource
        depends_on = [
            proxmox_lxc.postgres_db,
            proxmox_vm_qemu.redis_cache
        ]
    }

    # --- Load Balancer VM ---
    resource "proxmox_vm_qemu" "load_balancer" {
        name        = "lb-1"
        target_node = var.target_node
        clone       = var.vm_template
        agent       = 1
        cpu {
            cores       = 1
        }
        memory      = 512
        boot        = "order=scsi0" # has to be the same as the OS disk of the template
        scsihw      = "virtio-scsi-single"
        vm_state    = "running"
        automatic_reboot = true

        # --- Add these lines for Cloud Init Drive ---
                # --- Add these lines for Cloud Init Drive ---
        cicustom   = "vendor=local:snippets/qemu-guest-agent.yml" # /var/lib/vz/snippets/qemu-guest-agent.yml
        ciupgrade  = true
        nameserver = "1.1.1.1 8.8.8.8"
        ipconfig0  = "ip=10.0.0.100/24,gw=10.0.0.1"
        skip_ipv6  = true
        ciuser     = var.ssh_user
        cipassword = var.ssh_password
        sshkeys    = var.ssh_key

        # Most cloud-init images require a serial device for their display
        serial {
            id = 0
        }

        disks {
            scsi {
            scsi0 {
                # We have to specify the disk from our template, else Terraform will think it's not supposed to be there
                disk {
                storage = "local-lvm"
                # The size of the disk should be at least as big as the disk in the template. If it's smaller, the disk will be recreated
                size    = "5G" 
                }
            }
            }
            ide {
            # Some images require a cloud-init disk on the IDE controller, others on the SCSI or SATA controller
            ide1 {
                cloudinit {
                storage = "local-lvm"
                }
            }
            }
        }

        network {
            id = 0
            bridge = "vmbr0"
            model  = "virtio"
        }

        connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = "10.0.0.100"
        }

        # Step 1: Install Nginx
        provisioner "remote-exec" {
            inline = [
                # Wait for cloud-init to finish before doing anything else
                "echo 'Waiting for cloud-init to finish...'",
                "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Still waiting...' && sleep 1; done",
                "echo 'Cloud-init finished.'",

                # Now, safely install packages
                "sudo apt-get update -y",
                "sudo apt-get install -y nginx"
            ]
        }

        # Step 2: Upload config to a temporary location
        provisioner "file" {
            source      = "../web-servers/nginx.conf"
            destination = "/tmp/nginx.conf" # Use /tmp instead
        }

        # Step 3: Use sudo to move the file to its final destination and reload nginx
        provisioner "remote-exec" {
            inline = [
                "sudo mv /tmp/nginx.conf /etc/nginx/sites-available/default",
                "sudo systemctl reload nginx"
            ]
        }
    }


    # --- Load Tester VM ---
    resource "proxmox_vm_qemu" "load_tester" {
        name        = "load-tester-vm"
        target_node = var.target_node
        clone       = var.vm_template
        agent       = 1
        cpu {
            cores       = 1
        }
        memory      = 1024
        boot        = "order=scsi0" # has to be the same as the OS disk of the template
        scsihw      = "virtio-scsi-single"
        vm_state    = "running"
        automatic_reboot = true

        # --- Add these lines for Cloud Init Drive ---
        cicustom   = "vendor=local:snippets/qemu-guest-agent.yml" # /var/lib/vz/snippets/qemu-guest-agent.yml
        ciupgrade  = true
        nameserver = "1.1.1.1 8.8.8.8"
        ipconfig0  = "ip=10.0.0.160/24,gw=10.0.0.1"
        skip_ipv6  = true
        ciuser     = var.ssh_user
        cipassword = var.ssh_password
        sshkeys    = var.ssh_key

        # Most cloud-init images require a serial device for their display
        serial {
            id = 0
        }

        disks {
            scsi {
                scsi0 {
                    # We have to specify the disk from our template, else Terraform will think it's not supposed to be there
                    disk {
                    storage = "local-lvm"
                    # The size of the disk should be at least as big as the disk in the template. If it's smaller, the disk will be recreated
                    size    = "5G" 
                    }
                }
            }

            ide {
            # Some images require a cloud-init disk on the IDE controller, others on the SCSI or SATA controller
                ide1 {
                    cloudinit {
                    storage = "local-lvm"
                    }
                }
            }
        }

        network {
            id = 0
            bridge = "vmbr0"
            model  = "virtio"
        }

        provisioner "remote-exec" {
            connection {
                type        = "ssh"
                user        = var.ssh_user
                private_key = file(var.ssh_private_key_path)
                host        = "10.0.0.160"
            }
            inline = [
                # Wait for cloud-init to finish
                "echo 'Waiting for cloud-init to finish...'",
                "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Still waiting...' && sleep 1; done",
                "echo 'Cloud-init finished.'",

                # Install prerequisites
                "sudo apt-get update -y",
                "sudo apt-get install -y gnupg curl",

                # Add the k6 repository and key
                "curl -sL https://dl.k6.io/key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/k6-archive-keyring.gpg",
                "echo 'deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main' | sudo tee /etc/apt/sources.list.d/k6.list",

                # Install k6
                "sudo apt-get update",
                "sudo apt-get install -y k6"
            ]
        }

        provisioner "file" {
            connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = "10.0.0.160"
            }
            source      = "../load-testing/script.js"
            destination = "/home/${var.ssh_user}/script.js"
        }

        provisioner "file" {
            connection {
            type        = "ssh"
            user        = var.ssh_user
            private_key = file(var.ssh_private_key_path)
            host        = "10.0.0.160"
            }
            source      = "../load-testing/rate-test.js"
            destination = "/home/${var.ssh_user}/rate-test.js"
        }

    }

Conclusion

You've now seen how to build a complete, scalable, and resilient system that includes a crucial component for modern web applications: a distributed rate limiter.

We've covered the entire stack:

• Infrastructure as Code with Terraform to define our virtual machines. (check out my repo here for all the code and any updates I make).

• A centralized, high-speed cache with Redis to store our rate limiting data.

• An efficient Sliding Window Log algorithm implemented in Python with Flask.

• Containerization with Docker for consistent deployment.

• Load balancing with Nginx to distribute traffic.

• Load testing with k6 to validate our implementation.

If you’d like to learn more of the concepts that are used when building large scale systems please follow me at Sravan Karuturi.

The course was developed by Google Cloud and helps people earn the Google Cloud Cybersecurity Certificate. This certificate program is your training ground to protect valuable digital assets from the ever-evolving world of cybercrime.

Why Learn Cybersecurity with Google Cloud?

In our hyper-connected world, the security of digital infrastructure is important. Every organization, from startups to global enterprises, needs skilled professionals to defend against threats.

As a Cloud Security Analyst, you'll be the one to analyze threats, build defenses, and safeguard critical systems in the cloud. This program provides the essential skills to enter this high-growth field, blending expert-led instruction with immersive, hands-on Google Cloud challenges to build your expertise and impress future employers.

What’s Inside the Certificate Program?

This program is a carefully structured path designed to take you from foundational concepts to advanced, real-world application. You'll not only learn technical skills like threat identification and risk management but also how to respond to incidents and communicate effectively during a crisis.

Here’s what you’ll learn across the five-course series:

1. Introduction to Security Principles in Cloud Computing Start with the essentials of cybersecurity. You’ll explore the security lifecycle, understand the impact of digital transformation, and grasp key cloud computing concepts. This module introduces you to the common tools and responsibilities of an entry-level cybersecurity analyst.

2. Strategies for Cloud Security Risk Management Dive into the critical process of managing risk in the cloud. This course covers widely-used risk management frameworks and industry standards like HIPAA, NIST CSF, and SOC. You'll learn to navigate the complexities of compliance and develop strategies to protect organizations.

3. Cloud Security Risks: Identify and Protect Against Threats Explore the core principles of identity and access management within a cloud environment. You'll get hands-on with concepts like Authentication, Authorization, and Auditing (AAA), credential management, and techniques for identifying and mitigating system vulnerabilities.

4. Detect, Respond, and Recover from Cloud Cybersecurity Attacks This course focuses on the operational side of security. You will develop crucial skills in monitoring, logging, and security alerting. You'll also learn proven techniques for mitigating attacks and customizing threat detection to stay ahead of adversaries.

5. Put It All Together: Prepare for a Cloud Security Analyst Job Apply everything you’ve learned in a final capstone mission. This project simulates a real-world security scenario, challenging you to combine your skills in risk management, vulnerability identification, and incident response to solve a complex problem and build a standout portfolio piece.

Start Your Journey Today

This course provides the tools and training you need to succeed in the exciting and critical field of cloud cybersecurity. And it’s built around practical experience. It’s a thrilling mix of expert-led courses and immersive challenges through interactive labs on the Google Cloud Skills Boost platform.

These labs give you a chance to practice in a real cloud environment, reinforcing your learning with practical skills that employers are looking for.

Watch the full course on the freeCodeCamp.org YouTube channel and begin your journey into cybersecurity (10-hour watch).

Every year, billions of credentials are stolen and sold on the dark web.

Cybercriminals don’t always need advanced techniques to break into your account. Often, they rely on simple, automated methods that exploit human habits ,  like reusing passwords or choosing predictable ones.

Below are five of the most common ways attackers crack passwords and how you can protect yourself.

Brute Force Attacks

Brute force attacks are one of the oldest hacking techniques still in use.

In this approach, attackers use a computer program to try every possible combination of characters until it finds the correct password.

While this may seem tedious, tools like Hydra, Medusa, or John the Ripper can attempt thousands  –  or even millions  –  of guesses per second.

For example, if your password is “test123,” a brute force tool will likely crack it in seconds. A 6-character password with only lowercase letters has 308 million possible combinations, which modern GPUs can process in minutes or less.

Your best defense against brute force is password length and complexity.

A random, 16-character password with mixed-case letters, numbers, and symbols is practically immune to brute force attacks with today’s hardware.

Using a password manager like NordPass, Bitwarden, or 1Password makes generating and storing such passwords easy and offers strong password protection.

Dictionary Attacks

Unlike brute force, a dictionary attack narrows the search space by trying passwords from a precompiled list of commonly used words and phrases.

These lists often include leaked passwords from previous data breaches, popular sports teams, keyboard patterns like “qwerty” or “123456,” and even names or swear words. They are also called wordlists.

Many people mistakenly believe that tweaking a common password  –  for instance, changing “password” to “P@ssw0rd!”  –  makes it secure. But dictionary attack tools account for these variations.

For instance, the tool Crunch allows attackers to generate wordlists with pattern-based rules, meaning “Welcome@123” is still a likely guess.

“123456”, “password”, and “qwerty” are still among the most common passwords in the world. Even passwords like “iloveyou” and “dragon” show up repeatedly.

To protect yourself, never use real words, names, or predictable patterns in your passwords. Instead, try using passphrases that are long, random, and unique  –  such as “truck-pillow-coffee-skyline” or a completely random string like “g6D@!rXplQ8#1zVn”.

Again, a password manager is the easiest way to maintain this level of randomness and uniqueness.

Credential Stuffing

Credential stuffing is one of the most successful and least sophisticated attack methods. It exploits one simple fact: people reuse passwords across multiple accounts.

When a site like LinkedIn or Dropbox gets breached and the passwords leak online, attackers take those stolen credentials and try them on other websites  – your email, Facebook, Netflix, or even bank portals.

This technique is highly automated. Attackers use bots to test thousands of username-password combinations across dozens of sites until they find a match.

Let’s say you used your Gmail password to sign up for a small forum years ago. That forum gets hacked, and your login details are exposed. If you’re still using that same password on Gmail, attackers now have a key to your inbox  –  which also means they may get access to all your other accounts via password reset links.

To defend against credential stuffing, use a unique password for every account. You don’t need to memorize all of them  –  just use a reputable password manager.

Also, turn on multi-factor authentication (MFA) wherever possible, so even if someone has your password, they still can’t log in without the second factor.

Phishing Attacks

Phishing isn’t a technical exploit  –  it’s a psychological one.

Instead of guessing your password, attackers trick you into giving it away.

Phishing often comes in the form of fake emails, text messages, or websites that look legitimate but are designed to steal your credentials.

For example, you might receive an email that looks like it’s from your bank, asking you to “verify your account.” The link takes you to a fake login page that captures your username and password the moment you enter them.

Tools like Evilginx and Modlishka can even bypass MFA by intercepting tokens in real time.

Phishing is widespread because it works. According to CISA, phishing was the most common initial attack vector in 2022. And it’s getting more convincing with the use of AI to write emails, spoof sender addresses, and create realistic-looking websites.

To stay safe, never click on suspicious links or enter login details on a site you reached through an email. Always type URLs manually or use browser bookmarks for sensitive sites like banking or email.

Train yourself to spot red flags  –  like poor grammar, urgency, or mismatched sender names.

Social Engineering and Password Resets

Sometimes, hackers don’t need technical skills at all  –  they just need to be convincing.

Social engineering involves manipulating people into giving up confidential information. One common tactic is calling customer support and pretending to be you. If the rep isn’t careful, they might reset your password or give access to your account.

This actually happened to tech journalist Mat Honan in 2012, when hackers used social engineering to take over his Apple account. They then used it to wipe his phone, lock him out of email, and access other connected services.

Another trick is exploiting weak password reset systems. If a service allows you to reset your password by answering questions like “What’s your pet’s name?” or “Where were you born?”, attackers may already know the answers from your social media or data leaks.

To avoid this risk, limit what personal information you share online.

Use fake answers for password reset questions  –  just store them in your password manager.

And wherever possible, enable two-factor authentication using an app like Authy or Google Authenticator instead of relying on SMS, which can be intercepted via SIM swapping.

Defense is Easier Than Recovery

Cybercriminals don’t always need to “hack” their way in  –  they just need you to slip up.

The good news is that most password attacks rely on human error and predictable habits. By using a password manager, enabling multi-factor authentication, and staying alert to phishing attempts, you can block nearly all of these threats.

Think of your digital life like a house. Would you use the same key for your home, car, office, and locker? Would you leave it under the mat? That’s exactly what weak or reused passwords do online.

Stay one step ahead. Lock your digital doors properly  – and don’t give attackers the key.

Join the Stealth Security Newsletter for more articles on Cybersecurity.