If you haven’t read the background, you might want to do so first.
The REFLEX Framework offers a practical, developer-first approach to embedding security awareness, resilience, and response into everyday workflows. REFLEX transforms developers from passive users of security policies into active defenders of their environments, code, and systems.
REFLEX teaches developers how to think like an attacker and how to translate that insight into defensive muscle memory they can apply on a day-to-day basis.
The aim is to make security thinking a habit, not a checklist.
REFLEX, as a methodology, works as follows
Reconniance
New vulnerabilities or software weaknesses are discovered all the time. Reconnaissance is about staying up to date on both the technical consequences of these discoveries and estimating how they might be exploited.
It’s also about the wider, more general, drive-by cyber attacks that occur in the background all the time. At this stage, we’re teaching developers the security hygiene they need to have every day. Just like washing your hands is a habit, we work to make daily software developer actions secure as a matter of course.
It’s not just about traditional software or software supply chains. We teach developers about the pitfalls of AI - as a weapon in the hands of the bad guys, as a misapplied power tool by the inexperienced and as a critical element of a modern business that’s now embedded in their software supply chain.
The final piece is to teach developers about external elements that affect how they develop software. From legislation and regulations to the motivations behind cyber attackers, we connect developers with these elements and help them understand why improving their security posture and attitude to security is essential and within their control.
Evaluate
This phase is about applying the education and insight from Reconnaissance to the developer’s real environment. We teach developers how to assess themselves, including their actions, environment, and application, from an attacker’s point of view.
Evaluate is a self-check that will produce a series of actions for later steps.
We teach developers to be critical about their choices, offer alternative viewpoints on how they have operated before, and help them use public data on vulnerabilities, weaknesses, etc., in more effective ways.
By teaching developers how their specific choices and general behaviour can be exploited, we ground them in the practical. By connecting their decisions to the types of attacks that can exploit them, we make cyberattacks relevant and real.
We also teach developers to apply a critical eye to tools and practices that others may promote for security purposes. For instance, we will explore how Software Composition Analysis (a vital element in supply chain security) works and teach developers how to assess whether the SCA tools they use can provide the security protections they promise.
During evaluation, we strive to get developers to step back and examine their behaviour and their environments with this informed, critical eye.
Although there are elements similar to threat modelling, we expand the objectives to cover the tools and practices that are likely needed for legislative purposes.
Fortify
Just as developers build robust and scalable architectures, Fortification focuses on building security into the foundation. This means teaching secure design patterns, how to secure the software supply chain (understanding dependencies, using SBOMs effectively, etc), baking in compliance requirements, and ensuring the integrity of frameworks and libraries used. It leverages solid software engineering practices to manage the complexities of building secure systems from the ground up.
This phase complements the previous two. We move from understanding the enemy and assessing our weaknesses to designing an in-depth ‘fortification’ that uses the knowledge of how attacks occur to build better, more secure solutions.
With an understanding of the practical elements of legislative requirements, this phase helps developers create new solutions and developer practices that deliver secure and compliant software and processes.
Limit
By this phase, we’ve taken the developer on a journey towards developing an appropriate and persistent security culture, one that is ingrained in their behaviour and processes. We’ve taught them to consider both technical and regulatory aspects of software development and shown them how to design safer systems.
However much we hope that the fortifications in place are sufficient, we need to consider what to do if they are not. This phase focuses on how to limit the effectiveness of a successful attack.
We cover aspects such as system isolation, RBAC, data segregation, outbound firewalls, encryption at rest, etc. We teach developers both the available tools and standard design and architecture patterns, including how to sandbox risky operations such as using untrusted code, AI models, third-party integrations, etc.
We show how to design systems to fail safely (using kill switches and circuit breakers), how to minimise sensitive data exposure across environments, and how to prevent lateral movement through strict separation of privileges.
Examine
Limiting and containing the damage caused by a cyber attack is essential, but so is being aware that the attack is happening or about to happen. In this phase, we explore the tools available for detecting attacks and teach the developer how they can assist these tools through both action and design. We show how to implement meaningful logging and telemetry, how to log unusual behaviours and code paths and how to identify and report anomalies in general.
We have a strong focus on the software supply chain, from dependency updates to the CI/CD process and beyond, as we teach developers how to monitor all developer environments for signs of intrusion or compromise.
We teach developers to look for signs of compromised open-source projects, how to identify poisoned AI models, and other more common open-source threat vectors, such as dependency confusion and typo squatting. We explore how to assess software from the initial selection to day-to-day dependency and tool updates.
eXecute
The final phase. Since security is a continuous process, developers must be prepared for real-world incidents and build their learning into their processes, connecting with the broader security activities and groups within their organisation.
Execute is about how they evolve their development processes to include the checks and balances needed, from design reviews with a security element to post-incident reviews that foster a blameless culture. We teach developers how to embed their new skills and understandings into their processes, so that they and their teams can continue to operate with a security-first mindset while still delivering value to the business.
We also introduce metrics to measure success, such as security maturity and the reduction in vulnerabilities over time. By incorporating continuous feedback loops from each phase into daily practice, developers can adapt quickly to new threats, keeping security at the heart of their development process.