Controlling Developers Minds Through First Principles and Engineering Models

Controlling Developers Minds Through First Principles and Engineering Models

Speakers: DrydenMaker, Security/Software Engineer, Guidepoint Security

Conference: SAINTCON

YouTube: https://www.youtube.com/watch?v=-Wsc4Tge9Q0

Overview

This talk, presented by Alton Crossley (DrydenMaker), delves into a novel, Inception-themed approach to resolving the perennial friction between security teams and software developers. Crossley argues that traditional methods of imposing security requirements often lead to resistance and non-cooperation from development teams, who may perceive security as undermining their established empirical processes. His core thesis is that true security integration can only be achieved by "planting the inception" of security principles directly into developers' minds, making security an intrinsic motivation rather than an external mandate.

The presentation outlines a strategic framework for security professionals to understand developer motivations, align security goals with business value, and integrate security practices so seamlessly that developers adopt them as their own ideas. This involves a deep dive into the first principles of both security and software engineering, addressing common misconceptions, and leveraging a developer-centric model to foster securable software development from the ground up. By focusing on collaboration, transparency, and practical integration, the talk offers a compelling vision for a future where secure coding is a natural outcome of the development process.

Background

▶ Watch: Introduction: Inception theme and problem statement (0:00)

The persistent friction between security and development teams is a well-documented challenge in the software industry. Security engineers often lament the presence of "bugs that should not have been there," viewing developers as negligent. Conversely, developers frequently perceive security as an impediment, attempting to enforce impractical Service Level Agreements (SLAs) or bypass established development processes, thereby undermining decades of empirical work. This disconnect stems from fundamental differences in perspective and often a lack of mutual understanding regarding core motivations and objectives.

Alton Crossley, drawing on his two decades of experience in software engineering and an early background in security bulletin board systems, recognized this chasm. He observed that while security's first principle is to reduce the probability of material impact, aligning with broader business goals, software engineering's first principle is to resiliently add computing value, ensuring long-term business value. Crucially, Crossley argues that these two principles do not inherently conflict. The perceived friction arises when security teams become overly focused on "security things" in isolation, failing to understand and align with the direct business feed that development already possesses.

Two significant misconceptions contribute to this friction:

1. Motivation for Flexibility: Developers highly value creating flexible code because it enhances their productivity, reduces bug-fixing time, and enables them to respond confidently to feature requests. Security professionals, however, sometimes misinterpret this flexibility as "untamed" or equate it directly with insecurity. A key insight is that security is not implicit functionality; it must be explicitly requested and designed, a truth exemplified by the insecure code often produced by Generative AI if security isn't specified.
2. "Shoveling Left": This refers to the practice of offloading raw, unfiltered security testing results directly to developers, often through integrations with tools like Jira. While seemingly shifting left, this approach is deemed "impractical" because the information is not actionable. Security tools lack context about a company's specific architecture, coding style, or team dynamics, leading to noisy, false-positive-prone outputs. This "freight train through a packed downtown intersection" approach damages security's reputation, pushes vulnerabilities to the bottom of backlogs, and ultimately leads to "limbo" where meaningful impact is lost.

To overcome these challenges, Crossley proposes an "inception" strategy: to plant the idea of secure development within the minds of core engineers, making it their own motivation. This requires understanding their world, speaking their language, and integrating security in a way that feels natural and empowering, rather than burdensome.

Key Findings

▶ Watch: Frank discussion on security vs. development friction (4:00)

The talk articulates several key findings and strategic shifts necessary to bridge the gap between security and development:

• Non-Conflicting First Principles: The core insight is that the first principles of security (reducing material impact) and software engineering (resiliently adding computing value) are not in conflict. This foundational alignment makes the "inception" of security into development minds theoretically possible and practically achievable.
• Security is Not Implicit: A crucial finding is that security is never an implicit functionality. It must be explicitly designed, requested, and built into the software. This understanding is vital for both security professionals in defining requirements and for developers in internalizing secure coding practices.
• The Dangers of "Shoveling Left": Directly pushing unfiltered, unactionable security scan results to developers is counterproductive. It creates noise, fosters resentment, and ultimately pushes security issues into a "limbo" state where they are ignored. Effective security integration requires context-aware, actionable information.
• Targeting Core Engineers: Not all developers are equally receptive to security "inception." The strategy must focus on core engineers—those who are passionate about building, constantly seeking improvement, and drive the overall development process. Their adoption will influence others.
• The "I Am Creating a Securable Product" Implant: The central idea to implant is a self-belief: "I am creating a securable product." This concept is designed to hijack developers' inherent desire for improvement and quality, channeling it towards security without it feeling like an external imposition.
• The Securable Software Engineering Model (SSEM): A pivotal contribution is the emphasis on the Securable Software Engineering Model (SSEM), derived from the OWASP Project Phase framework. This model provides a standardized, developer-friendly language to discuss security concerns through attributes like maintainability, trustworthiness, and reliability, rather than security-centric jargon.
• Maintainability as Foundation: Maintainability is identified as the most fundamental attribute of securable code. If code cannot be confidently analyzed, changed, and tested, it cannot be secured. This shifts the focus from purely security vulnerabilities to core engineering qualities that enable security.
• Embrace and Extend Existing Processes: Effective security integration involves enhancing and extending existing development processes (e.g., requirements gathering, merge reviews, logging) rather than replacing them or introducing disruptive new ones. This ensures security becomes a natural part of the workflow.
• Product Security as the Future: The talk advocates for a product security model, where security teams take an active, cross-functional role across product, architecture, engineering, QA, and operations, moving beyond traditional assessment or validation roles.

Technical Deep Dive

▶ Watch: Defining the first principle of security (6:00)

The talk outlines a multi-layered approach to achieve "inception," carefully dissecting the motivations and processes of software engineering to integrate security intrinsically.

First Principles and Core Alignment

Crossley begins by establishing the first principles of both security and software engineering. For security, the principle is to reduce the probability of material impact, which necessarily involves aligning with business goals, as businesses exist to do business, not just to be secure. For software engineering, the principle is to resiliently add computing value, ensuring long-term business value beyond disposable, single-use code. The critical insight is that these principles are not in conflict; software engineers create value, and security defends it. This non-conflict forms the bedrock for successful inception.

Addressing Misconceptions: Flexibility and "Shoveling Left"

Before implanting ideas, two major misconceptions must be navigated:

1. Motivation for Flexibility: Developers naturally strive for flexible code because it dramatically increases their productivity and confidence in responding to new feature requests or bug fixes. This flexibility allows them to leverage existing code for new purposes, a feeling the speaker likens to a "minor superpower." However, security often views "untamed flexibility" as a vulnerability, equating it with insecurity. The distinction is crucial: security is not implicit functionality. As seen with Generative AI, code is only secure if security is explicitly requested. Software engineers need to learn to "tame their monster" (flexibility) in ways that align with security, but not necessarily for the reasons security might initially assume.
2. "Shoveling Left": This detrimental practice involves security teams pushing raw, often impractical, information from security testing tools (e.g., SAST/DAST results) directly into developer backlogs (like Jira). This approach is akin to "mowing grass," where vulnerabilities are checked off only to reappear. It fails because raw tool outputs lack architectural context, coding style nuance, or team personality, rendering them unactionable. This noise disrupts developers, damages security's reputation, and ultimately traps security initiatives in "limbo." The solution is to make security information highly actionable and context-specific.

Targeting the Right Minds: Core Engineers

The "inception" focuses on a specific type of developer: the core engineer. Crossley categorizes programmers into three types:

1. Those who don't care about quality, only pay.
2. Those building skills for a different career path.
3. Core engineers (likened to the "Eames" or "Ariadne" from Inception), who enjoy building, excel at it, constantly seek improvement, and understand the intricate relationships within software. These are the decision-makers and process drivers. The inception won't take hold unless this third type accepts it, as they are the "dream world" architects.

The idea to implant is simple: "I am creating a securable product." This message, if genuinely internalized, hijacks their existing desire for quality and improvement, directing it towards security.

Level 1: Framing Security with the Securable Software Engineering Model (SSEM)

The first level of inception involves challenging developers with the problem that "there is no static state of secure" and providing them with a tool to see they are already contributing to security. This tool is the Securable Software Engineering Model (SSEM), derived from the OWASP Project Phase framework (Framework for Integrating Application Security into Software Engineering).

The SSEM expresses security concerns using standardized, well-established software engineering terminology, avoiding security jargon that triggers subconscious rejection. Its key attributes include:

• Maintainability: This is the most fundamental attribute. If code is not maintainable, it cannot be secured because it cannot be confidently analyzed, changed, or tested. Maintainability implies code that is understandable by humans (as per Martin Fowler's quote: "Good programmers write code that humans can understand"). This is verified through merge reviews, which are underutilized by security.
• Trustworthiness: A systemic, higher-level attribute requiring cooperation between modules and clear architecture. Programmers need to understand how the architecture intends to exhibit security features like authorization. This necessitates upfront planning and documentation, challenging pure agile approaches that eschew such activities.
• Reliability: Promotes predictable running under unfavorable circumstances and load. It's a system-level attribute dependent on both maintainability and trustworthiness. Resilience, while often highlighted, is just one piece of the larger reliability picture.

By using the SSEM, the conversation shifts from "Is it secure?" (a security-centric question) to "Does this given piece of code meet our goals for this particular attribute?" (a developer-centric, specific, and productive question). The SSEM also proves useful in prompt engineering for AI-assisted code generation.

Level 2: Feeding the Idea through Process Enhancement

The second level focuses on extending existing development processes to gather more information for security and provide actionable insights to developers when they need them, without being disruptive. This is an "embrace and extend" strategy, not "lift and shift."

Examples of process enhancements for a fictitious company, Fisher Marl (a large organization with 700 developers, 330 code contributors, and sensitive data):

• Reference Architectures: Align with architects concerned about high availability by providing secure reference architectures (e.g., mitigating DDoS).
• Completeness/Requirements: Address gaps in requirements (e.g., invalid input, inconsistent authorization). Leverage OWASP reference requirements (e.g., ASVS, SCVS, MASVS) and provide checklists to ensure security requirements are included upfront. Sponsor initiatives to bake security directly into frameworks, making the secure path the easiest.
• Transparency (Instrumentation, Logging, Tracing): Avoid the "Three-Mile Island" scenario of too many meaningless alarms. Ensure logs are actionable, providing context (why, when, how often). This is critical for incident response, pentesting, and daily issue resolution. Sponsor initiatives to improve logging and tracing.
• Merge Reviews & Dependency Management: Encourage robust merge reviews (as a benefit to both code and engineers) and use the SSEM to evaluate dependencies (informing "borrow, buy, or build" decisions).

This level emphasizes security's active participation over mere assessment, ensuring involvement in planning phases.

Level 3: Driving Secure Development Subconsciously through Requirements

The final level focuses on setting clear, practical security expectations by leveraging the requirements activity—the "lifeblood of development." This is where security is injected into the source of work, handled with care to avoid business conflict.

Key aspects:

• Embrace "Security is Not Implicit": This understanding is central.
• Leverage OWASP Projects: Utilize resources like OWASP Mobile Application Security Verification Standard (MASVS), Application Security Verification Standard (ASVS), Software Component Verification Standard (SCVS), and Authentication/Authorization Cheat Sheets to guide the creation of practical security requirements. These should be adapted, not blindly dumped.
• Match Internal Processes: Security requirements must be integrated into developers' existing formats: acceptance criteria, user stories, use cases, and threat scenarios. If they match the internal pattern, developers will process them as any other task, without consciously flagging them as "security."

This "formula" ensures security is perceived as integral to development's advancement, making the integration transparent and effective.

The Kick: Embracing Product Security

The "kick" after successful inception is the realization that security's role must fundamentally shift. The talk advocates for a transition to product security, where security professionals take an active, structured, and cross-functional role across the entire product lifecycle—engaging with product teams, architecture, engineering, QA, and operations. This involves embracing the assurance nature of AppSec and skillfully using assurance information. The OWASP Project Phase framework not only helps developers but also frames how security interacts with development, moving beyond "shoveling left" without disruption or gimmicks. This is not an either/or choice (security vs. development) but a synergistic "both."

Demo / Proof of Concept

▶ Watch: Defining the first principle of software engineering (6:40)

The talk "Controlling Developers Minds Through First Principles and Engineering Models" is primarily a conceptual and strategic presentation, outlining a theoretical framework and practical methodology for integrating security into development workflows. It does not feature a live software demonstration or a technical proof of concept in the traditional sense of showcasing a tool or an exploit.

Instead, the speaker uses a fictitious target company, Fisher Marl, to illustrate the application of his concepts. Fisher Marl is described as having a large attack surface, handling sensitive data (PII, PHI, credit cards), possessing significant intellectual property, and employing a moderate-sized development team of around 700 developers with 330 code contributors. This hypothetical scenario allows the speaker to walk through how the proposed "inception" strategy, the Securable Software Engineering Model (SSEM), and process enhancements would be applied in a realistic corporate environment, highlighting specific challenges and solutions without requiring a live demo.

Defensive Implications

▶ Watch: Reconciling security and engineering principles; why friction exists (8:00)

The strategies outlined in this talk provide a robust framework for security teams to significantly enhance their defensive posture by fundamentally changing their relationship with development.

1. Shift from Gatekeeper to Partner: Security teams must abandon the "gatekeeper" or "assessor" mentality and adopt an active, collaborative role. Instead of merely identifying flaws, they should embed themselves within the development lifecycle, becoming trusted partners focused on enabling secure creation. This means actively participating in planning, design, and code reviews, rather than just post-development testing.
2. Adopt the Securable Software Engineering Model (SSEM): Implement the OWASP Project Phase SSEM as a common language for discussing security. By framing security concerns in terms of maintainability, trustworthiness, and reliability—attributes that resonate deeply with software engineers—defenders can foster understanding and shared responsibility. This model helps articulate why certain security practices are essential in a way that developers naturally grasp.
3. Prioritize Maintainability: Recognize maintainability as a foundational defensive attribute. Unmaintainable code cannot be secured effectively because it resists confident analysis, change, and testing. Defenders should advocate for and integrate practices that improve code maintainability, such as robust merge reviews, clear coding standards, and comprehensive documentation. This indirectly strengthens security by making code easier to audit and fix.
4. Integrate Security into Existing Workflows: Avoid creating separate, burdensome security processes. Instead, embed security requirements and checks into developers' existing tools and rituals. For example, integrate security requirements into user stories, acceptance criteria, and threat scenarios. Ensure that security tasks are formatted and presented in a way that makes them indistinguishable from other development tasks, reducing friction and subconscious rejection.
5. Stop "Shoveling Left": Cease the practice of blindly pushing raw, unfiltered security tool outputs to developers. Instead, security teams must act as an intelligent filter, contextualizing findings with architectural knowledge and team specifics, and presenting highly actionable information. This builds trust and ensures developer effort is spent on meaningful fixes, not chasing false positives.
6. Enhance Transparency through Instrumentation: Advocate for and help implement robust instrumentation, logging, and tracing capabilities within applications. This provides critical visibility into system behavior, enabling more effective incident response, faster debugging, and better detection of anomalous activity. Clear, actionable logs that differentiate normal behavior from critical events are a powerful defensive asset.
7. Sponsor Security Initiatives: Proactively identify and sponsor initiatives to "bake in" security at a broader architectural or framework level. This includes developing secure reference architectures, creating shared libraries with secure defaults, or integrating security controls directly into the development environment. Making the secure path the easiest path significantly scales defensive efforts.
8. Leverage OWASP Resources Strategically: Utilize OWASP projects like ASVS, MASVS, SCVS, and cheat sheets as authoritative references for defining practical, adaptable security requirements. These resources provide a solid foundation for building secure software and can be tailored to specific organizational needs.
9. Embrace a Product Security Model: Transition to a product security organizational structure. This involves security professionals taking an active, ongoing role across the entire software development lifecycle, from initial concept to deployment and operation. Product security practitioners work directly with product managers, architects, engineers, QA, and operations, ensuring security is considered at every stage and integrated into every decision.

By implementing these defensive implications, organizations can move beyond reactive security measures and cultivate a proactive, developer-driven security culture, ultimately leading to more resilient and trustworthy software products.

Key Takeaways

• Align First Principles: The friction between security and development stems from misaligned perspectives, not conflicting fundamental goals. Security aims to reduce impact, while development aims to add value; these are complementary.
• Security is Explicit, Not Implicit: It's crucial to understand and communicate that security is not an inherent feature of code; it must be explicitly designed, requested, and implemented.
• Avoid "Shoveling Left": Dumping raw, unactionable security tool findings onto developers is counterproductive, damages trust, and leads to security issues being ignored. Contextualized, actionable information is key.
• Leverage the SSEM: The Securable Software Engineering Model (SSEM) from OWASP Project Phase provides a developer-friendly language to discuss security through attributes like maintainability, trustworthiness, and reliability, fostering shared understanding.
• Integrate, Don't Disrupt: Embed security into existing development processes—such as requirements gathering, merge reviews, and logging—so it becomes a natural, subconscious part of the workflow rather than an external imposition.
• Embrace Product Security: The future of effective software security lies in adopting a product security model, where security professionals are actively involved and embedded across all phases and teams of the software development lifecycle.

About the Speaker(s)

Alton Crossley, also known as DrydenMaker, is a Product Security Consultant for Guidepoint Security. He brings a wealth of experience to the field, with a significant background of approximately 20 years in software engineering, complemented by experience in network engineering. Crossley's early exposure to security came from spending his adolescence on security bulletin board systems in the early 1990s. His unique journey from a deep software engineering background into product security provides him with a valuable perspective on bridging the gap between developers and security concerns, which he aims to share to help reduce friction in the industry.