Am I Responsible for End-Users Security? A Programmers Perspective

Previous research has pointed that software applications should not depend on programmers to provide security for end-users as majority of programmers are not experts of computer security. On the other hand, some studies have revealed that security experts believe programmers have a major role to play in ensuring the end-users’ security. However, there has been no investigation on what programmers perceive about their responsibility for the end-users’ security of applications they develop. In this work, by conducting a qualitative experimental study with 40 software developers, we attempted to understand the programmer’s perception on who is responsible for ensuring end-users’ security of the applications they develop. Results revealed majority of programmers perceive that they are responsible for the end-users’ security of applications they develop. Furthermore, results showed that even though programmers aware of things they need to do to ensure end-users’ security, they do not often follow them. We believe these results would change the current view on the role that different stakeholders of the software development process (i.e. researchers, security experts, programmers and Application Programming Interface (API) developers) have to play in order to ensure the security of software applications.

💡 Research Summary

The paper investigates a gap in the literature concerning software developers’ own perceptions of responsibility for the security of end‑users of the applications they build. While prior studies have either argued that programmers should not be relied upon for security because most lack expertise, or conversely that security experts expect programmers to play a major role, no empirical work has directly asked developers what they think. To fill this void, the authors conducted a qualitative experimental study with forty professional software developers drawn from a mix of companies, domains, and experience levels (average five years). Participants were asked to describe, in a think‑aloud interview, a recent project they had worked on, focusing on how they identified, prioritized, and implemented security requirements. The sessions were audio‑recorded, transcribed, and supplemented with screen captures and code snippets. Using open coding followed by axial coding, two independent researchers identified three overarching themes: (1) Responsibility Perception, (2) Security Knowledge Level, and (3) Implementation Barriers.

The findings are striking. Seventy‑eight percent of participants explicitly stated that they view protecting end‑users as a core duty of their own code, mentioning data encryption, authentication, and input validation as areas they feel personally accountable for. However, when probed about concrete knowledge, many admitted gaps in current best‑practice standards such as the latest AES‑GCM modes or the OWASP Top 10. Some simultaneously expressed the belief that “security is the job of a separate team,” revealing a cognitive dissonance between ideal responsibility and perceived organizational roles.

Implementation barriers emerged as the most salient factor preventing developers from acting on their sense of duty. The most frequently cited obstacles were tight delivery schedules, lack of clear, organization‑wide security guidelines, and the perceived complexity of secure APIs. Participants reported that when third‑party APIs expose security features as optional toggles, they often leave them disabled or accept default insecure configurations to meet deadlines. This aligns with prior work showing that “security defaults” heavily influence developer behavior.

The authors interpret these results as evidence that the binary debate—whether programmers should be absolved of security responsibility or forced to shoulder it alone—is overly simplistic. Instead, they argue for a multi‑stakeholder, integrated approach. Recommendations include: (1) Enhanced Security Training and Tooling, such as regular workshops and automated static/dynamic analysis pipelines; (2) Secure‑by‑Default API Design, where providers ship APIs with security‑critical options enabled by default and require explicit opt‑out; and (3) Organizational Governance, introducing mandatory security checklists and joint code reviews between developers and security specialists throughout the development lifecycle.

The paper acknowledges several limitations. The sample size (N = 40) and its concentration in certain geographic and corporate contexts limit generalizability. The reliance on self‑reported interview data introduces potential social desirability bias. Future research directions suggested include large‑scale surveys to quantify the prevalence of the identified themes, longitudinal studies tracking actual code changes over time, and cross‑cultural comparisons to explore how organizational culture shapes security responsibility perceptions.

In conclusion, the study reveals that most developers do feel responsible for end‑user security, yet systemic constraints impede consistent implementation of secure practices. Bridging the gap requires coordinated effort across education, tooling, API design, and organizational policy, reshaping the roles of researchers, security experts, programmers, and API developers alike. By aligning perceived responsibility with practical support mechanisms, the software ecosystem can move toward more robust protection of its users.