The security industry often fixates on tools: which scanner catches the most vulnerabilities? Which firewall has the highest throughput? However, the real friction in security is rarely technological—it is relational.
We sat down with Michele Chubirka (also known as “Mrs. Y”), a Cloud Security Advocate at Google, to discuss a radical shift in how we approach security culture. From applying a “Restorative Justice” framework to InfoSec, to deciding whether your startup actually needs Kubernetes, Michele offers a masterclass on empathy, pragmatism, and moving beyond the “Department of No.”
You can read the complete transcript of the epiosde here >
What is a “Restorative Justice Framework” and how does it apply to Information Security?
Restorative Justice is a social science framework traditionally used in the criminal justice system as an alternative to the standard punitive/permissive model. Instead of focusing on punishment (“You broke the rule, go to jail”), it focuses on repairing harm and restoring community.
In the context of Information Security, Michele applies this to the dynamic between security teams and the rest of the organization.
- The Problem: The traditional security approach involves walking into a room, showing a report full of red “failures,” and shaming the engineering team. This stigmatizes the team, humiliates them before leadership, and kills the relationship.
- The Solution: Using restorative practices (influenced by John Braithwaite’s concept of Reintegrative Shaming), security teams can address the “harm” (e.g., unpatched systems, vulnerabilities) without labeling the person as “bad.” It separates the deed from the doer, fostering a culture where teams work together to fix the issue rather than hiding mistakes to avoid punishment.
Why is “shame” such a dangerous emotion in security culture?
Shame is a powerful silencer. Michele references the work of Tomkins and Nathanson on Affect Script Psychology and the “Compass of Shame.” When people feel shamed (e.g., after a harsh vulnerability report or a phishing test failure), they typically react in one of four ways:
- Withdraw: They stop responding to emails.
- Avoid: They change the subject.
- Attack Self: They shut down and feel incompetent.
- Attack Other: They get defensive and scream at the security team (“You don’t understand our workload!”).
None of these reactions lead to a secure environment. A restorative approach acknowledges the mistake but moves quickly to “effective resonance”—processing the situation together and moving forward respectfully.
How can organizations build a “No-Fault” culture?
Building a no-fault culture requires what Michele calls “Professional Intimacy”—the ability to have honest, empathetic conversations in a business setting.
- Empathy is Key: Just as we ask developers to care about security, security professionals must care about developers’ constraints. “Compassion fatigue” is real in security; dealing with constant attacks and breaches is traumatic. Acknowledging this stress on both sides helps humanize the interaction.
- Shift Left (Relational): Instead of just shifting tools left, shift relationships left. Show up early, not as an antagonist at the end of the SDLC, but as a collaborator who understands the friction developers face.
What is the most effective way to teach security to a lean startup team?
If you are a startup with limited budget, you cannot afford a massive security team. Michele advises:
- Hire a Generalist First: Avoid the “superhero” who wants to do everything alone. Hire someone with high emotional intelligence who views security as a collaboration.
- Don’t Do the Threat Model: A security person should never do the threat model alone. The developers who built the application understand its logic and flaws far better. The security team’s job is to facilitate that conversation, not dictate it.
- Security Champions: Instead of forcing everyone into a generic training session, identify the developers who are already curious about security. Empower them with information and delegate decision-making to them. This creates ownership rather than compliance.
The Kubernetes Reality Check: Should a startup use it?
Michele’s advice on Kubernetes is pragmatic: “Dance with the cloud that brought you”.
- Use Managed Services: Unless you are building a cloud platform yourself, you rarely need “best-in-class” self-managed Kubernetes. Managed services (like GKE Autopilot) are “good enough” and abstract away the massive operational complexity.
- Avoid Overlay on Overlay: A common mistake is using an overlay network on top of a cloud provider’s existing overlay network just to avoid “vendor lock-in.” This creates nightmare latency and troubleshooting scenarios. Startups should focus on shipping product, not managing Kubernetes control planes.
How do we integrate Security into DevOps without killing velocity?
Security tools often act as a brake on fast-moving DevOps pipelines. Michele suggests treating security testing like a firewall with “Fast Path” and “Slow Path” traffic:
- Slow Path (Initial Review): When a new service or major feature is established, inspect it thoroughly.
- Fast Path (Routine Checks): For minor updates, use “side channel” testing. Scan code offline or look for diffs rather than blocking the main pipeline for hours.
- Align with Existing Testing: If the engineering team relies on unit tests, put your SAST (Static Analysis) there. If they rely on functional tests, put your DAST (Dynamic Analysis) there. Security should mirror the engineering workflow, not obstruct it.
Conclusion: Security is a Feature, Not a blocker
Ultimately, security is a product feature—like seatbelts in a car. You don’t have to justify why a car needs seatbelts, but the buyer still cares more about the speed and color. By adopting a Restorative Justice framework, security leaders can move away from shaming and blaming, fostering a culture where developers are partners in safety rather than targets of compliance.
