When Bad Code Has Real-World Consequences

In March 2018, one of Uber’s autonomous test vehicles struck and killed a pedestrian in Tempe, Arizona. The incident became one of the most scrutinized software-related accidents in recent memory. Investigations revealed a troubling combination of factors: the safety driver behind the wheel was reportedly watching a streaming video on a personal device instead of monitoring the road, and the vehicle’s self-driving sensor system failed to correctly classify and react to the pedestrian in time to apply the brakes.

The National Transportation Safety Board (NTSB) investigated the crash extensively. While the full chain of causation involved human distraction, vehicle design decisions, and operational policies, software behavior was a central element of the NTSB’s findings. For the DevOps and software engineering community, the incident served as a stark reminder: the code teams write can have consequences far beyond a degraded user experience or a missed sprint deadline.

Ethical Pressure Inside the Organization

The Tempe accident did not arise in a vacuum. Prior to it, Uber had already attracted significant negative attention for a range of alleged internal practices. Former software engineer Susan Fowler published a widely read account in early 2017 describing a culture of sexual harassment and management misconduct. Separately, Uber faced accusations that its engineering teams had built tools designed to exploit driver earnings, evade regulatory oversight, and deny service to passengers in ways that skirted legal boundaries.

These allegations, if accurate, represent a scenario in which software developers were asked—explicitly or implicitly—to write code in service of goals that were ethically or legally questionable. This raises an important question for every engineering organization: what happens when the people with the ability to build something are also the first line of defense against building something harmful?

What Developers Say They Would Do

Stack Overflow’s annual developer survey, which at the time of the original reporting included responses from more than 100,000 developers worldwide, offered some data on how engineers think about ethical responsibility. When asked what they would do if asked to write code for an unethical purpose:

• 58.5% said they would refuse to write it.
• 36.6% said their response would depend on the specific situation.
• 4.8% said they would write it.

On the surface, these numbers are encouraging. A strong majority of developers report a willingness to refuse unethical work. However, Stack Overflow noted a significant grey area in the findings: developers were largely uncertain about how they would report an ethical concern, and they held widely differing views about who bears ultimate responsibility when unethical code is shipped. That ambiguity is the real problem.

The Grey Area: Responsibility and Reporting

Knowing that you should refuse to write harmful code is not the same as knowing what to do next. In practice, engineers face a layered set of pressures: sprint deadlines, management directives, fear of retaliation, uncertainty about whether their concern is legitimate, and a general sense that someone higher up the chain must have already considered the implications.

This diffusion of responsibility is well-documented in organizational psychology. In software teams, it can manifest as a situation where no individual developer believes they are personally responsible for the ethical dimensions of a system, even as the system as a whole causes harm.

What DevOps Teams Can Do

Torsten Volk, an analyst at Enterprise Management Associates (EMA), argued that DevOps is uniquely positioned—and uniquely obligated—to build ethical guardrails into development culture. He identified several concrete mechanisms:

1. Full Audit Trails

Maintaining clear, immutable records of who wrote what code and when creates accountability at the individual contributor level. Volk noted that knowing an audit trail exists makes developers more likely to raise concerns with team leads before problematic code ships. Source code management systems like Git already provide the technical foundation for this; the cultural commitment to treating those records as an ethical tool is what organizations often lack.

2. Documented Ethics Discussions

When a developer flags an ethical concern, the outcome of that conversation should be documented—ideally in the same source code management or issue-tracking system the team already uses. This transforms a potentially invisible conversation into a traceable decision, and it protects the developer who raised the concern.

3. Psychological Safety for Raising Concerns

No audit trail matters if developers fear retaliation for speaking up. Organizations must actively cultivate an environment where raising an ethical red flag is treated as a professional responsibility rather than insubordination. This means leadership modeling the behavior, not just writing it into a policy document.

4. Connecting Ethics to Business Risk

Volk also argued that organizations should frame ethical coding practices in terms that resonate at the executive level: risk management and bottom-line impact. Unethical code is not just a moral failure; it is a liability. Regulatory penalties, reputational damage, and the cost of incident response all have quantifiable business consequences. Drawing a direct line between ethical engineering practices and reduced organizational risk is one of the most effective ways to secure sustained leadership buy-in.

Volk drew a parallel to GDPR compliance, suggesting that organizations could similarly recognize and publicize outstanding examples of ethical conduct in development—signaling to customers and partners that responsible engineering is a competitive differentiator, not just a cost center.

Building an Ethical Engineering Culture

The Uber case should not be read as an indictment of autonomous vehicle technology or of DevOps culture writ large. The majority of software developers, as the Stack Overflow data suggests, want to do the right thing. The challenge is structural: organizations must make it easy—and safe—for developers to act on their ethical instincts.

Practical steps for engineering leaders include:

• Adding an ethics review checkpoint to your Definition of Done or pull request template.
• Including ethical risk assessment in architecture decision records (ADRs).
• Running scenario-based ethics training as part of onboarding and continuing education.
• Establishing a clear, non-punitive escalation path for engineers who have concerns about a feature or system they are being asked to build.
• Ensuring retrospectives can surface ethical concerns, not just process inefficiencies.

Software is not neutral. The decisions made during a sprint—what a sensor system is optimized for, how an algorithm weights certain outcomes, which edge cases are treated as acceptable losses—can ripple outward in ways that affect real people. DevOps culture, with its emphasis on shared responsibility, continuous feedback, and transparency, is well suited to make ethical accountability a first-class engineering concern rather than an afterthought.

Security teams and DevOps engineers frequently operate with different priorities, vocabularies, and success metrics. DevOps teams measure themselves on deployment frequency, lead time, and mean time to recovery. Security teams measure themselves on risk reduction, compliance posture, and incident avoidance. Without deliberate effort to align these frameworks, communication breaks down — and the consequences are real: delayed releases, security controls bolted on at the last minute, or worse, vulnerabilities shipped to production.

The Root Causes of Miscommunication

Several structural and cultural factors contribute to the disconnect between security and DevOps:

• Different risk languages: Security professionals speak in terms of threat models, CVEs, and compliance frameworks. DevOps engineers speak in terms of pipelines, containers, and uptime. Neither group is wrong — they simply lack a shared vocabulary.
• Late-stage security reviews: When security is only engaged at the end of a release cycle, it becomes a bottleneck rather than an enabler. Engineers experience security as an obstacle, and security teams feel ignored during design.
• Siloed tooling: Security tools that don’t integrate into CI/CD pipelines require manual handoffs, creating friction and incentivizing teams to work around security checks.
• Asymmetric accountability: In many organisations, DevOps teams own the delivery outcome while security teams own the risk outcome. This split accountability makes it easy for each group to blame the other when something goes wrong.
• Perceived culture clash: DevOps culture prizes speed and experimentation. Traditional security culture prizes control and caution. Without deliberate bridging, these values feel mutually exclusive.

Security as a Trusted Advisor, Not a Gatekeeper

When a security team can assess brand, financial, and strategic risks, they are best able to act as a trusted advisor to the DevOps team as they build and maintain secure systems.

SecurityWeek

This framing is important. A security team that understands business risk — not just technical vulnerability — can communicate in terms that resonate with engineering leadership and product owners. Instead of flagging a misconfigured S3 bucket as a CVSS score, they can articulate the potential brand damage, regulatory fine, or customer data exposure that misconfiguration represents. That context changes the conversation from adversarial to collaborative.

Trusted advisors are consulted early and often. Gatekeepers are avoided until unavoidable. Security teams that want a seat at the DevOps table need to demonstrate that engaging with them early makes delivery faster and safer — not slower.

Practical Steps to Improve Security-DevOps Communication

1. Embed Security Early in the SDLC

Shift security left by involving security engineers during architecture and design reviews, not just pre-production audits. Threat modelling sessions held at the start of a sprint or feature cycle catch design-level risks before they are expensive to fix.

2. Adopt a Shared Risk Register

Maintain a risk register that is visible and meaningful to both security and DevOps teams. Prioritise risks using business impact, not just technical severity. This gives DevOps engineers the context to make informed trade-off decisions without waiting for a security sign-off on every ticket.

3. Integrate Security Tooling into the Pipeline

Static analysis (SAST), dependency scanning (SCA), container image scanning, and secrets detection should all run automatically within the CI/CD pipeline. When security feedback arrives in the same interface engineers already use — pull requests, build dashboards — it becomes part of normal workflow rather than a separate process to manage.

4. Define Clear Escalation Paths

Engineers should know exactly what to do when a security scanner flags a critical finding at 2 AM during a deploy. Pre-agreed escalation paths, documented acceptance criteria, and defined waiver processes remove ambiguity and prevent both over-reaction (blocking all deployments) and under-reaction (silently ignoring findings).

5. Run Joint Post-Mortems

When a security incident or near-miss occurs, conduct a blameless post-mortem that includes both security and DevOps stakeholders. Shared analysis of what went wrong builds mutual understanding and surfaces systemic communication failures that individual teams cannot see on their own.

6. Establish a Security Champions Programme

Designate security champions — engineers within DevOps teams who receive additional security training and serve as the first point of contact for security questions. This distributes security knowledge without requiring a security engineer to be embedded in every team, and it builds empathy between the two disciplines.

The DevSecOps Model as a Structural Solution

The DevSecOps movement exists precisely because the communication failure between security and DevOps is a well-recognised, recurring problem. DevSecOps treats security as a shared responsibility distributed across the entire software delivery lifecycle — not as a separate phase owned by a separate team. Organisations that successfully adopt DevSecOps typically report fewer last-minute security blockers, faster time to remediation, and improved trust between engineering and security functions.

Achieving this requires more than tooling. It requires executive sponsorship, changes to team incentive structures, and sustained investment in cross-functional training. But the alternative — continued miscommunication, late-stage security failures, and adversarial team dynamics — carries its own significant cost.

Key Takeaways

• Security and DevOps teams miscommunicate because they measure success differently and use different risk languages.
• Security teams that understand business risk — brand, financial, strategic — can act as trusted advisors rather than gatekeepers.
• Shifting security left, integrating tooling into pipelines, and establishing shared risk registers are concrete steps to improve collaboration.
• DevSecOps is the structural answer to the communication problem, but it requires cultural change, not just tooling.
• Security champions and joint post-mortems build the mutual understanding that processes alone cannot create.

Originally referenced from: The Danger of Miscommunication Between Security and DevOps — SecurityWeek.