Notifications
Clear all
Topic starter
01/08/2026 10:48 pm
TL;DR: Security controls that developers hate can collapse adoption, create workarounds, and blunt response to supply chain risk, according to Aikido’s interview with Tyro CISO Arun Singh. The governance problem is not just technical fit but whether security changes preserve enough developer trust to be followed at scale.
NHIMG editorial — based on content published by Aikido: Tyro's CISO on why developer trust matters more than security brilliance
Questions worth separating out
Q: How should security teams roll out controls without losing developer trust?
A: Start by reducing friction in the highest-frequency workflows, then explain the risk trade-off in terms developers can validate.
Q: Why do security controls fail when they sit outside DevOps workflows?
A: They fail because they arrive after the design choices are already locked in and teams are under pressure to ship.
Q: What breaks when package policy is enforced too aggressively?
A: Aggressive package controls can slow delivery, increase shadow approvals, and push teams to bypass the intended process.
Practitioner guidance
- Define control rollback thresholds before rollout Set measurable thresholds for developer complaints, workflow delay, and exception requests so a control can be reversed or adjusted before trust degrades across the wider engineering organisation.
- Move secrets detection into the IDE layer Use in-workflow scanning to flag secrets, insecure patterns, and risky package imports before commit, then route only true exceptions to security review.
- Formalise package cooldown exceptions Document who can override a cooldown period for new package versions, what evidence is required, and how approvals are logged for auditability.
What's in the full article
Aikido's full post covers the operational detail this analysis intentionally leaves for the source:
- The full interview context behind Arun Singh's rollout experience and how the trust issue evolved across engineering teams.
- Practical examples of developer-facing controls, including IDE scanning and device protection, with workflow-specific implementation detail.
- The reasoning behind the seven-day package cooldown policy and how the engineering team explained it internally.
- Additional commentary from the Secure Disclosure conversation on security culture, developer friction, and adoption at scale.
👉 Read Aikido's analysis of developer trust, supply chain risk, and AppSec controls →
Developer trust and security controls: what teams are missing?
Explore further
01/08/2026 10:56 pm
Developer trust is a control surface, not a soft metric. Once security teams burn trust with disruptive or poorly explained changes, later governance asks are harder to enforce even when they are technically sound. That makes control design part of operational risk management, not just change management. For AppSec leaders, this means the success criterion is adoption fidelity, not policy intent.
A question worth separating out:
Q: How do security teams know whether preventive controls are actually working?
A: Look for blocked ingestion attempts, reduced malicious artifact reach, faster revocation of high-value tokens, and fewer downstream findings created by the same trust path. If risky packages still reach runners or integration abuse still propagates across tenants, the control is not operating at the right point in the lifecycle.
👉 Read our full editorial: Developer trust is now a security control, not a soft metric
