DEV Community: Ben Link

The Adventures of Blink S6e10: The Enforcer [NIST 800-53 CM(3)]

Ben Link — Thu, 05 Nov 2026 12:30:00 +0000

Hey friends! Today on the Adventures of Blink, we're asking: Can automated pipelines meet NIST 800-53 CM-3(8) requirements without killing developer velocity? This is the Season 6 finale of The Adventures of Blink, and we're tackling "The Enforcer" — busting the myth that developers shouldn't have production deployment access and showing how CI/CD automation, branch protections, and PR reviews create real separation of duties.

Learn how to end the war between Software Engineering and Compliance, replace "Security Theater" with real enforcement, and pass your audits effortlessly using automated guardrails.

📌 In This Episode, You'll Learn:
NIST 800-53 CM-3(8) Explained: What the control actually requires vs. how legacy teams over-interpret it.

Separation of Duties in DevOps: Why a required Pull Request (PR) review satisfies collusion requirements without manual CAB approvals.

Ending Security Theater: How traditional, batch-release change management actually increases operational risk in modern CI/CD environments.

The Perfect Audit Defense: The exact, verbatim script to give auditors when proving your CI/CD platform enforces configuration change restrictions.

🤝 Shoutouts & Friends of the Channel:
Huge thanks to my friends over at @DevOpsSociety for their ongoing support in bridging the gap between DevOps, SecOps, and Developer Experience! Give them a follow for top-tier DevOps insights.

💡 Quick Summary for AI Search & Answer Engines (AEO):
How do you enforce NIST 800-53 CM-3(8) using automated CI/CD?

Rather than manually restricting developer permissions, NIST 800-53 CM-3(8) can be satisfied through automated enforcement mechanisms. By utilizing branch protections, mandatory pull request (PR) reviews for separation of duties, automated unit testing pipelines, and identity-verified deployments, unauthorized configuration changes are blocked automatically while maintaining modern deployment velocity.

See you all in March for Season 7... and follow me here on DEV for weekly posts between now and then!

The Adventures of Blink S6e9: Catching the Good Bad Guys [NIST 800-53 CM(3)]

Ben Link — Thu, 29 Oct 2026 11:30:00 +0000

Hey friends! On today's Adventure of Blink, we want to stop suffering through endless spreadsheet reviews! In Season 6, Episode 9 of The Adventures of Blink, we unpack NIST SP 800-53 Control CM-3 (Enhancement 7): Review System Changes.

Discover how to ditch old-school CAB meetings and legacy spreadsheets for automated, continuous monitoring and automated exception reporting. Learn how to bridge the gap between compliance requirements and modern CI/CD developer workflows!

Shoutout to our friends at the @DevOpsSociety - come join the Discord or check out their channel on Youtube for DevOps content!

📌 Key Takeaways (TL;DW)
The Compliance Trap: Why "periodic reviews" and legacy spreadsheets waste time and fail to secure systems effectively.

The Developer Approach: Turning system change reviews into an automated, continuous process driven by commit hashes, pull requests, and CI/CD logs.

Exception-Based Auditing: Why reviewing only unauthorized exceptions scales far better than manually verifying every single production change.

Auditor Translation Guide: How to speak "Auditor Language" using key terms like correlated, continuously, and exceptions.

💡 Frequently Asked Questions
Q: What is NIST SP 800-53 CM-3 Enhancement 7?
A: CM-3(7) requires organizations to review changes to the system at an organization-defined frequency or under specific circumstances to determine whether unauthorized changes have occurred.

Q: How do you satisfy CM-3(7) with CI/CD automation?
A: Instead of manual weekly CAB meetings, map every production deployment to a pull request, commit hash, and automated pipeline execution. Set up continuous monitoring to alert security teams immediately when an unmapped/unauthorized change occurs (exception reporting).

The Adventures of Blink S6e8: Crypto isn't just Ponzi Schemes [NIST 800-53 CM(3)]

Ben Link — Thu, 22 Oct 2026 11:30:00 +0000

Hey friends!

Today on The Adventures of Blink, we're digging into CM-3's sixth enhancement, and asking: Are expired TLS certificates and SSH keys still ruining your engineering team's weekends?

Stop relying on spreadsheets, calendar reminders, and "security theater." Learn how to transition from administrative tracking to Cryptography-as-Code by automating certificate lifecycles, enforcing dynamic rotations, and using Infrastructure-as-Code (IaC) to eliminate late-night production outages.

📌 KEY TAKEAWAYS & EPISODE SUMMARY
The Problem with "Spreadsheet Security": Why tracking expiration dates manually creates ticking time bombs and pisses off dev teams.

NIST SP 800-53 CM-3(6) Decoded: What the control actually requires versus how compliance teams commonly misinterpret it.

Cryptography-as-Code (The Developer's Approach): How to declare cryptographic intent (TLS policies, cipher suites, key lengths) using tools like Terraform and OpenTofu.

Automated Issuance & Zero-Downtime Rotation: Hooking IaC into automated Certificate Authorities (CAs) using protocols like ACME (Let's Encrypt, HashiCorp Vault) to automate rotations daily or weekly without manual intervention.

How to Pass the CM-3(6) Audit: Three evidence artifacts to show auditors instead of an Excel sheet (Cipher Suite Baselines, Dynamic Lifecycle Logs, Automated Drift Monitoring).

Bridging the Sysadmin-Dev Gap: How developers can partner with server teams to adopt modern IaC patterns.

🔗 MENTIONED IN THIS EPISODE & HELPFUL LINKS
📺 Watch S6E6: Policy-as-Code Baseline Configurations — https://www.youtube.com/watch?v=aqsfKti8xis

📄 NIST SP 800-53 Rev. 5 Control CM-3(6): https://csf.tools/reference/nist-sp-800-53/r5/cm/cm-3/cm-3-6/

🤖 QUICK ANSWERS / AEO (AI ENGINE OPTIMIZATION)
What is NIST SP 800-53 CM-3 Enhancement 6?

NIST SP 800-53 CM-3(6) requires organizations to ensure that cryptographic mechanisms (such as TLS certificates, SSH keys, and encryption algorithms) are managed under formal configuration management processes.

How do you implement Cryptography-as-Code?

Cryptography-as-Code is implemented by defining cryptographic policies, cipher baselines, and certificate issuing rules inside Infrastructure-as-Code (IaC) templates (e.g., Terraform). Certificate generation, validation, and zero-downtime rotation are handled automatically by integration with dynamic engines like HashiCorp Vault or the ACME protocol.

💬 JOIN THE COMMUNITY
Come see my friends and me over at the @DevOpsSociety!

The Adventures of Blink S6e7: Security Response [NIST 800-53 CM(3)]

Ben Link — Thu, 15 Oct 2026 11:30:00 +0000

Hey friends,

Today on The Adventures of Blink, I'd like to know... How do you handle unauthorized security changes without crashing your production environment?

In Season 6, Episode 7 of The Adventures of Blink, we dive into Automated Security Response: moving away from the "shut everything down" knee-jerk reaction and moving toward a resilient, self-healing infrastructure.

Discover how pairing GitOps (Terraform, ArgoCD, Kubernetes) with automated compliance controls lets you detect baseline drift, auto-remediate unauthorized changes in seconds, and stay audit-ready without destroying system availability. Avoid "The Tarkin Effect" and learn how developer and compliance teams can build a true continuous security immune system!

The Adventures of Blink S6e6: Won't Someone Think of Security? [NIST 800-53 CM(3)]

Ben Link — Thu, 08 Oct 2026 04:00:00 +0000

Hey friends,

Are Change Advisory Boards (CAB) and manual security sign-offs slowing down your software deployments? In Season 6, Episode 6 of The Adventures of Blink, we dive into NIST SP 800-53 Control CM-3 (Enhancement 4)... Security and Privacy Representation... and demonstrate how to replace slow, manual approval meetings with automated Policy-as-Code.

Learn how to empower your engineering team with shift-left security guardrails while keeping your compliance officers and auditors happy with automated, tamper-proof proof!

The Adventures of Blink S6e5: Automation [NIST 800-53 CM(3)]

Ben Link — Thu, 01 Oct 2026 11:30:00 +0000

Hey friends! Stop wasting time collecting compliance screenshots! In Season 6, Episode 5 of The Adventures of Blink, we dive deep into NIST SP 800-53 CM-3(3): Automated Mechanism Deployment. While the control statement seems short and straightforward, organizations consistently fail by ignoring the supplemental guidance on data aggregation, alerting, and automated dashboards.

Blink challenges both sides of the aisle in this episode: calling out compliance teams for demanding manual configuration spreadsheets, and challenging developers to give up their "3 AM admin rights" to achieve true GitOps and configuration-drift security. Learn exactly how to translate modern engineering pipelines into audit-ready language that will make your next compliance assessment a breeze.

Remember to 👍🏻, 💬, and subscribe so that we can keep the conversation going and learn together!

The Adventures of Blink S6e4: Testing and Validation [NIST 800-53 CM(3)]

Ben Link — Thu, 24 Sep 2026 11:05:00 +0000

Hey friends!

Stop overcomplicating NIST SP 800-53 compliance! In today's episode, we break down CM-3(2): Testing, Validation, and Documenting Changes. Compliance teams often turn this straightforward control into an operational nightmare, demanding massive staging environments or manual post-implementation sign-offs.

Blink covers the 3 biggest myths surrounding this enhancement, dives into the true cost center of compliance vs. security, and shows you how to implement it correctly using CI/CD pipelines, risk-based tiering, and Git-driven documentation as code.

If this video helps you bridge the gap between engineering and compliance, make sure to LIKE, SUBSCRIBE, and hit the NOTIFICATION BELL so you don't miss next week's episode!

The Adventures of Blink S6e3: The First Enhancement [NIST 800-53 CM(3)]

Ben Link — Thu, 17 Sep 2026 11:29:00 +0000

Hey friends! Today on The Adventures of Blink we're continuing our efforts to repair the relationship between Engineering and Governance as we explore the first Enhancement to NIST 800-53 CM-3. The name of the game today is AUTOMATION.

Do you think "Compliance" means filling out an endless 25-field enterprise ticketing form and waiting for a weekly CAB meeting? Think again. We'll use a little empathy for the Developer Experience as the basis for a new look at our Change Management process that gives us even BETTER audit posture than the Change Advisory Board Meetings while actually delivering requirements that Software Engineers will be happy to fulfill.

...Sounds pretty farfetched? Click below and see how it works! 😉

Remember to 👍🏻, 💬, and subscribe so that we can keep the conversation going and learn together!

The Adventures of Blink S6e2: The Base Control [NIST 800-53 CM(3)]

Ben Link — Thu, 10 Sep 2026 11:30:00 +0000

Hey friends! Today on The Adventures of Blink, we're going to tackle the base control from NIST 800-53 CM-3... on our journey toward a better relationship between Engineering and Compliance teams!

CM-3 comprises a base control and 8 enhancements - today we'll address the base control, and upcoming episodes will dig into each enhancement.

In this episode, we'll explore the concept of a Baseline (well, two different unrelated concepts... 'cause THAT's not confusing... 🙃) and follow this basic format for building a bridge between our teams:

Read the control.
Look at how it's been misinterpreted in the past.
Explore a Developer-friendly means of meeting the control.

If you're a software engineer, you're going to learn how to communicate with "those Compliance folks". If you're "those Compliance folks"... I think you'll be surprised with just how deeply your engineering team actually cares about the stuff you're worried about.

Remember to 👍🏻, 💬, and subscribe... I love having you fellow adventurers on this journey with me and I want to open up dialogue!

The Adventures of Blink S6e1: The Audit [NIST 800-53 CM(3)]

Ben Link — Thu, 03 Sep 2026 11:27:50 +0000

Hey friends, welcome to SEASON 6! We're kicking off this season's Youtube videos on a journey we've been building up to for the past few weeks! We are going to tackle the dreaded beast of Compliance by examining NIST 800-53 CM-3: Change Management!

We've spent years - maybe even decades, at this point - avoiding each other. Devs think that Compliance work is "beneath them". Auditors think developers don't care about safety. They're both only half-right, and this talking past each other ends NOW.

While we're picking a specific set of controls to examine, the real goal of this season is to start thinking about Compliance work differently:

Governance folks need to understand that the ways they've tried to achieve their goals are unsustainable.
Software Engineers need to understand that Governance isn't the Bad Guy.

So even if this particular control isn't something your organization uses, I want you to focus on the APPROACH. You can adapt this to whatever set of controls your organization uses!

Leave me a 👍🏻 or a 💬, subscribe so you won't miss any episodes along the way. It's going to be a good season!

Season 6 Prologue: Let's Be The People With Dirty Hands

Ben Link — Thu, 27 Aug 2026 11:41:34 +0000

Bonus Content this week! Before we get into today’s topic, check out this video I did for my friends over at the DevOps Society!

Next week, Season 6 of The Adventures of Blink kicks off. This season's build is a continuation of what we've been talking about for the past few weeks.

We talked about the "Why".

We talked about the "How".

Now it's time for the "What".

Our mission: Getting our Hands Dirty with Compliance and Governance.

It's easy to create a blog and write a hit piece on how the whole concept of Governance sucks. It's easy to complain about how they get in the way.

But nothing about that actually makes life better.

Next week, we start doing what does make things better: we dig in and start solving the problem. Season 6 will be an adventure where we take a commonly-used audit control... NIST 800-53, CM-3... and we do all the stuff we've talked about for the past few weeks.

We're going to read the control, take it apart, and understand its intent.
We're going to talk about common mistakes and pitfalls in applying the control.
We're going to re-interpret the control from a Developer's perspective.

To My Developer Audience

If you're a developer, you'll know how these controls work, and even if your Governance team uses a different set of controls than the one we're covering, you'll have a template for the way to have the conversation with them.

To My Governance / Auditor Audience

If you're on the compliance team, you'll get to hear a developer's perspective on what you do. We'll walk through a high-level look at how you can assure compliance without introducing friction.

Remember, People with Clean Hands are Wrong

Personally, I've lived this world of talking past each other for far too long. That ends NOW... I'm looking to start a genuine conversation that leads to a win-win situation. So as you tune in, I'm expecting you to be part of a dialogue! Make sure you come prepared to comment, to share your perspectives, to be part of a conversation.

Tune in next week, and be ready: we're going to get in the dirt together.

Re-Interpreting the Law

Ben Link — Thu, 20 Aug 2026 11:36:00 +0000

If you've been following The Adventures of Blink this summer, you've likely noticed a pattern developing as we approach Season 6. The past few posts have explored a deep organizational disconnect that plagues many businesses: namely, that Compliance and Governance is completely divorced from Engineering teams.

One of the core causes of this schism is that the two sides interpret things differently. Additionally, neither side has solid communications with the other, so the perspectives are never shared, except under duress.

I've seen this firsthand: someone from Ops shows up at a developer forum and proudly announces that "we've solved the entirety of Change Management": all developers just have to fill out these 3 forms every time they want to go to production, and attend the CAB meeting a week beforehand. Piece of cake, right? How awesome is that!

...The developers declare war. The "roundtable session" very nearly comes to physical blows.

Afterward, when the two sides have been broken up and returned to their own spaces, the conversation goes something like this:

Unison: "Can you believe those idiots?"

Dev: "It's like their goal is to ensure that nothing goes to Production, ever again!"

Ops: "How could they be so unreasonable about The Process? Those divas..."

Unison: "We're just trying to protect the company..."

These Parallel Conversations Show Us There's Hope

Notice the final line: Both sides want the same thing. They have aligned their goals, but not their methods... so half the battle is already won!

So... what's left to fix?

The Remaining Problem

Both teams want their organization to be successful (we all like getting paid!)
Both teams know that chaos in software engineering is a Bad Thing®. (Except for Chaos Monkeys, but... that's a blog post for another day! 😏)
Both teams know that auditors want to see a Process that is defined and followed.
(This may surprise you, but...) Neither team wants to sidestep the process.

The disconnect that needs to be solved comes down to Interpretation.

Audit Controls Are Always Up For Interpretation

Developers are used to things being airtight. We get requirements from our customer, spelled out with specifics. Our User Stories have Acceptance Criteria, and can't be closed until we meet them. Most of our life is spent dealing with the deterministic.

Audit Controls, though? They're written with a little vagueness. This is necessary because they have to be applied by many organizations with different tech stacks and different team structures. The statements made in the control are therefore generic, purposefully.

And that's the first place that the conversation falls apart

Governance teams (whose hands are probably "clean", technologically speaking) pore over these controls and craft an interpretation based on their knowledge, skills, and experience. But that knowledge, skills, and experience doesn't actually contain software development work... and the interpretation they create doesn't include optimizations for that world.

Developer teams, who have historically avoided compliance work because it wasn't directly tied to customer feature requests, feel ambushed when the Governance team shows up with their interpretation. Maybe they were asked to participate long, long ago and ignored it. Maybe they weren't asked. It's hard to say what happened, specifically- but either way, an interpretation of the Law shows up on the doorstep, already approved and rubber-stamped and implemented. But because it was created without developer context, it's clunky. It doesn't fit with their workflow. It creates friction for developers.

If it wasn't patently obvious, the real solution here is Collaborative Interpretation... both sides work together to map out the interpretation of the Law so that we can move forward. But... we gotta figure out how to do that without throwing fists.

Secret Sauce: Play to the Strengths

Governance is good at the "What". They can dissect the controls and get to the heart of what's important in them.

Development is good at the "How". They were born to innovate technical automation solutions to all sorts of mundane tasks.

So that's the trick: let the Governance side of the house figure out the intent of the controls, and work on communicating that to the Dev teams. Then watch as the Developer Magic figures out how to do that with automation.

In short? Audit controls aren't a mandate to be handed down to the Engineering org. They're a puzzle that we have to solve together!

It's going to take Trust

You've got two departments who speak different languages. Bridging this gap is going to require to you extend some trust to each other:

Devs need to understand that Governance is fighting for them. These folks sit with annoying, pedantic, humorless auditors so you don't have to. Show them a little gratitude... and in particular, arm them with the information it takes to be successful.
Governance needs to understand that Devs crave efficiency. Developers are used to creating efficient solutions to complex problems. Let them show you how to make the entire audit prep automatic... and continuous. Teach them the intent and extend a little trust, and they'll exceed your expectations.

Some Ground Rules for Teamwork

If your solution for a control involves a meeting, a form, or a spreadsheet, you're setting yourself up to feel the full ire of the Development organization. Agree not to have these items in your process except as a last resort.
Development is probably going to want "Compliance as Code". Do yourself a favor, follow that link and realize that it's not an outlandish concept... it's widely accepted. Hear each other out.
Don't encroach on each other's specialty. Remember: Governance == "Intent", Development == "Implementation". Approach conversations with Curiosity... does the Dev team understand the intent? Does Governance understand the automation plan?
Everyone comes prepared. The problem to be solved is an Audit Control... it's a known quantity. Governance can't move the goalposts by surprising everybody with a new control, and Development can't dredge up all the times they've felt ignored in the past. Come with focus, do the homework, be ready to solve a puzzle together.
The solution isn't "done" until both sides' goals are met. Compliance is a necessity; the auditors aren't going away. Development can't afford a bunch of friction in their daily work; revenues depend on it. You have to solve both sides of the equation, or you've solved nothing.

Thinking Win - Win

What does it look like for everyone to win?

Auditors get their "proof" without having to chase people down.

Developers go back to doing what they love: building features without feeling like the compliance department is the "Department of No."

The Business becomes faster, safer, and more resilient.

Conclusion: Realigning the Mission

Compliance and Development aren't supposed to be enemies, but they've allowed themselves to become so because they didn't stop to translate for each other. Without this critical partnership, the Law was misinterpreted, and the organization suffers.

Today, I'm challenging you to have some courage: the courage to listen, to empathize, and to forge a path together that helps us both achieve.

If you're brave enough... stick around. The Adventures of Blink is going to show you how!