"Hopefully We Are Mostly Secure": Decoding the Social Reality of Secure Coding
"Hopefully We Are Mostly Secure": Views on Secure Code in Professional Practice
This paper presents an ethnographic study on how non-specialist professional developers perceive and manage software security within an Agile organization. Using semi-structured interviews and observations, the authors explore the "human aspect" of secure coding, identifying that developers rely on collective responsibility and integrated technical safeguards rather than individual expertise.
TL;DR
In the high-pressure world of Agile development, "Security" is often framed as a technical mandate. However, this ethnographic study reveals that for most professional developers, security is a collective social practice. Instead of individual expertise, teams rely on "event-driven" triggers like audits and "piggybacking" on existing frameworks to maintain a baseline they hope is "mostly secure."
Background: The Developer as the "First Line of Defense"?
Industry media often oscillates between two extremes: either developers are "Security Champions" who must catch every bug, or they are "Liability Risks" who should be held legally responsible for vulnerabilities.
The authors of this paper argue that both views ignore the social reality of the office. By moving away from the adversarial "attacker mindset," this research looks at security through the lens of human values and organizational culture.
Problem: The "Secondary Concern" Trap
Why do vulnerabilities keep happening? The study highlights several systemic pain points:
- Prioritization: Security is frequently a secondary concern compared to delivering new features.
- Tooling Friction: Cryptography APIs are notoriously difficult to use, and online advice is often fragmented or incorrect.
- The "What You Don't Know" Factor: Developers often suffer from a lack of structure in handling security, leading to an "occasional lack of attention."
Methodology: An Inside Look at Agile Teams
The researchers spent weeks embedded with three distinct teams:
- Oak: Mixed experience, balancing "fun new ideas" with "proven ways."
- Elm: Mobile-focused, relying on long-standing internal experience.
- Beech: Senior-heavy, high-quality output but prone to "strong opinions."
Figure 1: The physical layout of the studied environment, highlighting how proximity influences "ad-hoc" security discussions.
Key Findings: How Security Actually Happens
1. Awareness is Event-Driven
Security awareness doesn't exist in a vacuum. It is heightened by five specific paths:
- Compliance: GDPR and external audits expose "things never thought about."
- Automation: Static analysis tools (like Qualys) feed issues directly into the backlog.
- Peer Review: Code reviews are the frontline for catching authentication "misses."
- Documentation: Wiki-based standards prompt team-wide discussions.
- Code Reading: Learning by seeing how others implemented security "layers."
2. The Strategy of "Piggybacking"
Perhaps the most insightful finding is that developers deliberately rely on others. They "piggyback" on framework permissions, database rules, and network security. As one developer noted, "everything is already within... layers of security," allowing them to focus on the product features.
3. Shared vs. Delegated Responsibility
While developers feel responsible, they often "delegate" the final word to a perceived specialist.
"I’ve delegated that responsibility to [the principal engineer]... it's a 'get out' but also prudent."
Table 1: The diverse range of experience across the interviewees suggests that security views are consistent regardless of career length.
Critical Analysis: The Limits of "Mostly Secure"
The study concludes that "mostly secure" is a pragmatic achievement of collective practice. However, there are clear limitations:
- The "Luck" Factor: Engineers admitted they have no clear way to assess if they've done "enough" security.
- Determined Adversaries: There is a lingering fatalism that a truly "determined" attacker will always find a way through social engineering or brute force, regardless of code quality.
Summary & Future Outlook
This paper serves as a vital reminder for CTOs and Security Officers: Security cannot be automated or mandated into existence without considering the social fabric of the dev team.
Future research should look at how to formalize this "collective responsibility" without stifling the speed of Agile, perhaps by turning those "event-driven" audit moments into permanent, low-friction habits integrated into the IDE and the daily stand-up.