Netflix — open-sourcing the toolchain
This is a real, named company's story, and it sticks to what's publicly documented — Netflix's own TechBlog, its GitHub organization, and public conference talks by its security engineering leadership. Two threads run through it: a set of tools — Security Monkey, Aardvark, and Repokid — that started as internal AWS hygiene automation and ended up open-sourced, imitated, and in one case directly ancestral to an entire product category; and a structural choice, made early and rarely stated out loud elsewhere, that this tooling belonged inside the platform engineering organization rather than inside a compliance function. Where the public record is thin — exact dates, a project's current maintenance status — this page says so plainly.
Imagine a school hall monitor whose only job, at first, is to catch a locker left unlocked and slam it shut — fast, a little dramatic, occasionally over-eager. Now imagine that same hall monitor grows up into someone who instead walks every hallway every single hour, writes down which lockers are unlocked and for how long, and — this is the clever part — automatically takes away a student's spare keys once they haven't used them in three months, because a key nobody uses is a key nobody would even notice losing, and it's one fewer key a thief could steal. That's the arc this page follows: from "slam it shut" to "watch continuously" to "automatically shrink what could go wrong" — and the people running all three were the school's facilities crew, not the principal's office that only checks lockers once a semester.
Where it starts: one monkey in the 2011 Simian Army
☺ Like you're 10: The very first version of this idea didn't watch and report — it watched and immediately punished, the same way Chaos Monkey did for reliability.
Netflix's now well-known Simian Army, described in the company's 2011 TechBlog post "The Netflix Simian Army," included a member built specifically for security: Security Monkey. Per that post, its original job was narrow and blunt — find security groups configured with a dangerous opening (a rule exposing a sensitive port to the entire internet, for instance) and terminate the offending instances outright, plus check SSL and DRM certificates for validity. It ran on exactly the same instinct as Chaos Monkey, its more famous sibling: don't wait for a scheduled review to find the problem, find it continuously — and don't just report it, act on it immediately, because a misconfiguration sitting around waiting for a human to notice is a misconfiguration an attacker gets to find first.
That's worth pausing on, because the rest of this page is about what changed next. Security Monkey as originally conceived wasn't a dashboard. It was an enforcement action wearing the same "monkey" costume as the instance-killing chaos tooling it grew up next to.
From terminator to continuous monitor: Security Monkey becomes its own project
☺ Like you're 10: Terminating things automatically is thrilling to build and terrifying to run at scale — so the grown-up version watches everything, all the time, and only rings an alarm.
Watchers and auditors
Netflix spun Security Monkey out as its own open-source project — a dedicated GitHub repository under the Netflix organization, distinct from the Simian Army codebase — a few years after that original 2011 description, and the tool that emerged looked different in one important way: it no longer terminated anything automatically. What it kept, and built out much further, was the always-on part. Its architecture split into two halves: watchers, one per AWS resource type (S3 buckets, security groups, IAM users and roles, ELBs, RDS instances, KMS keys, and more), each polling the relevant AWS API on a schedule and diffing the result against the last known state; and auditors, which apply a rule set to that state and flag what looks dangerous — a security group open to 0.0.0.0/0 on a sensitive port, an S3 bucket with a public ACL, an IAM policy with a wildcard resource and a wildcard action. Every change got a timestamped history, browsable in Security Monkey's own web UI, so a team could answer "when did this bucket become public, and what did it look like a week ago" without digging through raw CloudTrail logs by hand.
A category before the category had a name
The mechanism that split out of that project — poll the real infrastructure's own API, continuously, on a schedule; diff against a known-good baseline; alert on drift, without waiting for a scheduled review — is, almost word for word, the definition of what the industry later started calling Cloud Security Posture Management (CSPM). Gartner didn't popularize that market-category label until years afterward (commonly cited around 2019); Security Monkey had already been running that exact pattern in production, continuously, at Netflix's scale since roughly 2014. That doesn't mean every later CSPM product descends directly from Security Monkey's codebase — most don't — but the pattern it proved out in public, in the open, is the one the whole category converged on. This course's own Prowler and ScoutSuite run the identical shape today, and CNAPP & the unified cloud security stack covers where that category has consolidated since.
Aardvark and Repokid: automating least privilege at IAM scale
☺ Like you're 10: Nobody can read four thousand keyrings by hand and remember which keys nobody's used in three months — so one program does the reading, and a second program takes the unused keys away.
The problem manual IAM review can't solve
Watching for dangerous configuration is one problem; a second, harder one is that permissions a team requests to unblock themselves during a project routinely outlive the reason they were requested, and nobody circles back to remove them. Across an organization running as many AWS accounts and IAM roles as Netflix does, reviewing that sprawl by hand — reading every role's policy and cross-referencing it against what the role actually calls — simply doesn't scale to a cadence that matters. By the time a manual review catches an over-broad role, it's usually been over-broad for months.
How the two tools split the job
Netflix's answer was two cooperating open-source tools. Aardvark polls AWS IAM's own Access Advisor API — the "service last accessed" data AWS itself tracks per role — across every account in the organization on a schedule, and stores the results centrally. Repokid then reads that data and, for each role, computes the gap between the permissions it's been granted and the services it's actually touched within a rolling window (Netflix's own public write-ups describe something on the order of 90 days), generates a minimized policy that keeps only what's been used, and can apply it directly — repossessing (hence "repo," Repokid's own verb for the action) the unused access.
A dry run and a rollback, not a mandate
The part that makes this safe to run automatically, rather than merely clever, is what Repokid does around the edges of the core action. A role can be excluded from automatic repo-ing — useful for a role that's rarely invoked by design, like a disaster-recovery path or a quarterly batch job, where "unused for 90 days" is a false positive, not a finding. Every change is reversible: the prior policy is kept, so if a repo turns out to have removed something a role genuinely needed, a single rollback restores it. And the tool supports a dry-run mode that reports what it would remove before it's ever allowed to remove anything — the same "show me first" discipline this course covers on workload identity & pipeline IAM.
aardvark: poll IAM Access Advisor across every account → store service-last-used data repokid display --account prod ROLE # show granted vs. actually-used permissions repokid repo --account prod ROLE # dry-run first: report what WOULD be removed repokid repo --account prod ROLE --commit # apply the minimized policy repokid rollback --account prod ROLE # restore the prior policy if something breaks
(Illustrative — a summary of the workflow the two tools' own documentation describes, not a literal, version-pinned command reference. Check the projects' current READMEs before running anything against a real account.)
Automatically removing "unused" access sounds like a pure safety win until the first time it removes something a legitimate but rare workflow actually needed — a failover path invoked once a quarter, a break-glass role nobody's touched since the last real incident. Repokid's real innovation isn't the deletion logic; a script that reads Access Advisor data and deletes anything idle for 90 days is a Friday-afternoon project. The rollback, the opt-out list, and the dry-run-first default are what keep that script from becoming its own incident.
Extending "break it on purpose" into security
☺ Like you're 10: Netflix taught the whole industry to break things on purpose to test reliability — and a few engineers elsewhere, inspired directly by that idea, started asking whether you could break security controls the same way.
The original, blunt Security Monkey — find a bad security group, terminate the instance immediately — was arguably chaos engineering applied to security before either half of that phrase was in wide use: it shared Chaos Monkey's exact instinct of finding a weakness through continuous, automatic pressure rather than a scheduled review. Netflix pulled back from the "terminate automatically" behavior in the standalone project; the record doesn't give one single, citable reason why, though the broader shift from destructive Simian-Army-style tooling toward monitoring-first tooling, as adoption widened beyond Netflix's own risk-tolerant culture, is a reasonable read of the pattern.
The idea didn't stay dormant — it resurfaced formalized, deliberately, and credited explicitly back to Netflix, but built by people outside Netflix. Aaron Rinehart, while at UnitedHealth Group, built a tool called ChaoSlingr explicitly modeled on Chaos Monkey's logic but aimed at security controls instead of infrastructure reliability, and later collaborated with Kelly Shortridge to formalize the discipline in a named body of work — Security Chaos Engineering (the title of their 2023 O'Reilly book) — which applies chaos engineering's hypothesis-inject-observe-learn loop specifically to questions like: does this WAF rule actually block the request pattern we think it blocks; does a revoked credential actually get rejected everywhere it's supposed to be, immediately, not eventually; does the alert we're relying on actually fire when the thing it watches for happens. Give Netflix credit for the precedent and for the willingness to run destructive experiments in production in the first place — and give Rinehart and Shortridge credit for turning that precedent into a discipline with its own name, hypothesis format, and literature. Read more on security chaos engineering.
Why a platform team, not a compliance team, was the right owner
☺ Like you're 10: A report only tells the truth on the day someone wrote it; a running program tells the truth right now, and someone gets paged the moment it stops.
What a compliance team optimizes for
A compliance or GRC function's native rhythm is the audit cycle — a point-in-time snapshot, reviewed on a quarterly or annual cadence, that ends in a document: a spreadsheet of findings, a signed attestation, a PDF handed to an auditor or a regulator. Success is defined as "we passed the review." That's a legitimate and necessary output — see compliance & governance for the frameworks it produces — but it isn't the same job as keeping a live system correct in between reviews.
What a platform team optimizes for
Security Monkey, Aardvark, and Repokid aren't reports — they're running software with the same obligations as any other production service: they have to tolerate AWS API rate limits and pagination, keep working across every AWS API change, store state, expose a UI, get paged when they silently stop scanning, and keep an entire engineering org's accounts current, not sampled. That's an SLA, not a submission deadline. Netflix's cloud security leadership — its VP of Information Security for over a decade, Jason Chan, described this repeatedly across public conference talks — staffed the function with engineers who wrote and operated code, embedded next to the same platform organization already building and running Spinnaker and the rest of NetflixOSS, rather than a reporting line auditing that organization from the outside.
The tell: where the code actually lived
Security Monkey, Aardvark, and Repokid were all published on github.com/netflix — the identical organization, and the identical open-source program, that shipped Spinnaker, Chaos Monkey, and Titus. That's not a trivial detail. It means this tooling was built to the same engineering bar, reviewed and versioned the same way, and released with the same "good enough that other companies would want to run it too" standard as the delivery and reliability tooling sitting right next to it in the same GitHub org — not walled off in a separate repository, a separate review process, or a team's backlog that only security itself could see.
The tell isn't the tool, it's who gets paged. A scan a compliance team runs quarterly can go stale for eighty-nine days before anyone notices. A scan a platform team owns is production software: if it silently stops running, the same on-call rotation that gets paged for a broken deploy gets paged for a broken scan. Ownership by the team with the pager is what keeps a finding current — not the finding itself.
What happened next, and what outlived the project
☺ Like you're 10: The specific tool eventually retired, the way old software does — but the habit it taught the industry didn't retire with it.
Security Monkey's own project pages have, for some years now, marked it as no longer under active development by Netflix, pointing users toward AWS's own native configuration-monitoring tooling (AWS Config and Config Rules), which by that point had matured enough to cover much of the ground Security Monkey pioneered. Salesforce's product security team picked up and continued maintaining a community fork for a period afterward — a small piece of evidence that the pattern had outgrown any one company's ownership.
The pattern really did outlive the specific codebase. Continuous, API-driven scanning of cloud configuration against a rule baseline is table stakes today, run by this course's own Prowler and ScoutSuite, and folded into essentially every commercial CSPM and CNAPP platform on the market. None of them needed to have read Security Monkey's source code to arrive at the same shape — but Security Monkey got there years earlier, in production, at a scale that proved the idea worked before "CSPM" was a line item any vendor was selling.
| Tool | What it did | Status |
|---|---|---|
| Security Monkey | Continuously polled AWS resource state (security groups, S3, IAM, certs, and more), diffed it against history, and flagged risky configuration | Marked end-of-life by Netflix; the pattern lives on in CSPM tooling broadly |
| Aardvark | Aggregated AWS IAM Access Advisor ("service last accessed") data across every account into one central store | Open source; the data layer Repokid depends on |
| Repokid | Read Aardvark's data and automatically minimized IAM policies to what a role had actually used, with dry-run and rollback | Open source; the least-privilege-automation pattern it proved out is now widely copied |
What to steal for your own platform
☺ Like you're 10: You don't need Netflix's account count to copy the habits — put the scanner where the pager is, automate with a rollback, and read the discipline before you improvise it.
- Put continuous cloud-posture scanning inside the platform/engineering org, staffed by people who get paged when it silently stops running — not a document a separate function refreshes on a quarterly calendar. See cloud security posture.
- If you automate the removal of unused access, ship the opt-out list and the one-command rollback before the tool is ever allowed to run in enforce mode — not after the first incident it causes. See workload identity & pipeline IAM.
- Build least-privilege automation on your cloud provider's own "last accessed" data (AWS IAM Access Advisor, or the Azure/GCP equivalents), not a spreadsheet a person is supposed to remember to update.
- Treat CSPM and CNAPP tooling as a build-vs-buy decision informed by this history, not a brand-new category to evaluate from scratch. See CNAPP & the unified cloud security stack.
- If "break it on purpose" appeals to you for security, read the formal discipline first — hypothesis, blast radius, safety engineering — before improvising your own version. See security chaos engineering.
- Measure the tooling itself against a maturity model rather than a gut feeling about how mature it is. See maturity models: DSOMM, SAMM & BSIMM.
Honest caveats: what doesn't transfer
☺ Like you're 10: A story from one very large company, told mostly in that company's own words, doesn't fit in a weekend — and some of it is the size talking, not the idea.
- "Manual review doesn't scale" is truer at Netflix's account and role count than at a five-person startup with one AWS account. The tooling's necessity scales with the sprawl it's managing — a small team may get more value from a lightweight scheduled scan than from standing up the full Aardvark/Repokid pipeline on day one.
- The public numbers here are approximate, not audited. Role counts, the 90-day repo window, and the exact spin-out and deprecation dates come from conference talks, blog posts, and project documentation, not an independently verified history — treat the shape of the story as reliable and the specific figures as approximate.
- "Chaos engineering extended into security" is a shared credit, not a Netflix invention. It's partly Netflix's own precedent (the original terminate-on-sight Security Monkey) and partly credit that belongs to Rinehart and Shortridge, who did the actual naming and formalizing outside Netflix. Don't retroactively credit Netflix with inventing Security Chaos Engineering as a discipline — credit it with proving the underlying instinct worked.
- None of this argues a compliance function is unnecessary. Compliance & governance still has a real, distinct job. The argument here is narrower: the specific job of building and operating always-on scanning and enforcement software belongs with the team that already operates software for a living.
Pick one AWS (or GCP/Azure) account you have access to. List every IAM role or service account with elevated permissions, and for each one, try to answer: when was this permission last actually used, and by what? If the honest answer is "nobody knows" for more than a couple of roles, that gap — not the absence of a policy document — is the exact problem Aardvark and Repokid were built to close. Don't automate anything yet; just write down which roles you can't currently answer that question for.
Sol the Sloth: One box at a time. This account has four thousand IAM roles. Nobody read all of them by hand — the tool did.
Nutty the Squirrel: I filed the last audit's spreadsheet. It said forty-one roles had excess permissions. That was three months ago — is it still true today?
Sol: No idea. Neither do you, until someone runs the scan again. That's the whole problem with a spreadsheet.
Rocky the Raccoon: So if I'm hunting for a role nobody's watching closely, I want the one that hasn't been re-scoped since your last audit — not since this morning's run.
Timmy the Turtle: Which is why Repokid doesn't just report the gap — it closes it, on a schedule, with a rollback if it guesses wrong.
Professor Owl: And notice who built it. Not the audit team — the platform team that already ran the pipeline Repokid plugs into.
Where this connects in the course
☺ Like you're 10: This one company's story touches several lessons — follow whichever matches what you're building next.
The continuous-scanning half of this story is cloud security posture in full, with the two tools this course teaches for it, Prowler and ScoutSuite, running the same shape Security Monkey proved out first — and CNAPP & the unified cloud security stack covers where that category has consolidated since. The least-privilege half is workload identity & pipeline IAM. The "break it on purpose, safely" half — including the honest attribution question this page raises — is security chaos engineering. The ownership argument at this case's center connects directly to compliance & governance and to security culture & champions, and if you want to measure how mature your own team's version of this tooling is, use maturity models: DSOMM, SAMM & BSIMM. For the rest of this course's tools, start at the tooling landscape; for the course's own fictional pipeline breach, see case study: securing a pipeline.
1. What did the original Security Monkey do inside the 2011 Simian Army, and how does that differ from what the standalone open-source project became? 2. Name the two tools that automate least-privilege IAM at Netflix, and say what data the first one collects for the second to use. 3. Why is it risky to automate the removal of "unused" IAM permissions without a dry-run mode and a rollback path? 4. In this page's argument, what's the structural difference between how a compliance team owns a security control and how a platform team owns one? 5. Who actually coined and formalized "Security Chaos Engineering" as a named discipline, and what's Netflix's real relationship to it? 6. What happened to Security Monkey itself, and what pattern outlived the specific project?
Check your answers
- Inside the 2011 Simian Army, Security Monkey found insecure security-group configurations and terminated the offending instances immediately, plus checked SSL/DRM certificate validity — an enforcement action. The standalone open-source project that followed dropped the automatic termination and instead became a continuous, watcher-and-auditor monitoring and alerting system with a historical UI.
- Aardvark aggregates AWS IAM Access Advisor ("service last accessed") data across every account into a central store; Repokid reads that data and automatically generates a minimized IAM policy for each role, keeping only permissions that have actually been used within a rolling window.
- Because "unused for 90 days" can be a false positive for a role that's rarely invoked by design — a disaster-recovery path or a quarterly batch job — and removing real access it turns out was still needed can break that workflow. A dry-run mode (report before acting) and a rollback (restore the prior policy fast) are what keep the automation from becoming its own incident.
- A compliance team's native output is a point-in-time document — an audit finding, a spreadsheet, a signed attestation — reviewed on a quarterly or annual cadence, which can go stale between reviews. A platform team owns the same control as running production software: it has an SLA, gets paged when it silently breaks, and stays current continuously rather than being refreshed on a calendar.
- Aaron Rinehart (with ChaoSlingr at UnitedHealth Group) and Kelly Shortridge formalized Security Chaos Engineering as a named discipline, outside Netflix, in their own book and body of work. Netflix's relationship to it is precedent, not authorship: the original terminate-on-sight Security Monkey demonstrated the underlying instinct — continuous, automatic pressure instead of scheduled review — years before the discipline had a name.
- Netflix's own project pages have, for some years, marked Security Monkey as no longer actively developed, pointing users to AWS Config as a native replacement; a Salesforce-maintained community fork continued for a period afterward. The pattern that outlived it — continuously polling cloud APIs, diffing against a baseline, and alerting on drift — is now the working definition of CSPM, run today by tools like Prowler and ScoutSuite and folded into commercial CNAPP platforms.