By David Soto Dalmau (ERNI Spain)
Security is more than a checklist. This case shows how we exported a 360º approach to professional development teams, combining principles, best practices and CI/CD enforcement. Teams gained clarity, confidence and alignment, making security a natural part of software quality.
The challenge: Security knowledge without a unifying framework
In many organisations, software security initiatives grow organically. Teams receive guidance on data protection, coding standards, vulnerability management, and tooling – but often as isolated topics, disconnected from one another.
The result is familiar: developers know what tools to use and what rules to follow, yet struggle to understand how all security concerns fit together across the software lifecycle.
The core need behind this training initiative was therefore not to introduce more controls, but to establish a shared, end-to-end security model that development teams could apply consistently – from design decisions to runtime behaviour.
A 360º perspective: Security as a continuous system
From the outset, the training was designed around a single idea: Secure software is not achieved through a single practice or tool, but through the alignment of principles, behaviours and controls across the entire development lifecycle.
To make this tangible, we structured the programme as a progressive journey covering three complementary dimensions:
- Foundational security principles
- Secure development best practices
- Operational security controls
integrated into CI/CD
Each layer reinforced the next, creating a coherent and repeatable security mindset.
Foundations: The CIA triad as the security baseline
The journey started with first principles. Rather than jumping directly into tooling, the training established a common baseline using the CIA triad – Confidentiality, Integrity and Availability. This was not treated as theory, but as a practical lens through which all later decisions would be evaluated:
- What data must remain confidential?
- Which operations require integrity
guarantees? - What availability assumptions does the
system depend on?
By anchoring security discussions in CIA, teams gained a neutral, technology-agnostic way to reason about risk and impact, independent of implementation details. This foundation proved essential when later discussing trade-offs, priorities and failure scenarios.
Secure development best practices: From principles to behaviour
Building on the CIA baseline, the second part of the training focused on secure development practices, treating security as a quality attribute of software – on par with performance or reliability. Key topics included:
- Input validation as an explicit trust boundary
- Secure handling of secrets and sensitive
material - Session management and authorisation
invariants - Zero Trust principles applied at code level
The emphasis was deliberately placed on developer behaviour, not checklists. Security was framed as a set of invariants that must hold true, regardless of refactoring, feature growth or architectural evolution.
This approach helped teams recognise that many real-world incidents are not caused by exotic attacks, but by regressions – controls that once worked but were unintentionally broken by later changes.
From best practices to proof: Testing and verification
Once secure coding practices were established, the training moved to an often misunderstood area: security testing versus vulnerability scanning. A clear distinction was introduced:
- Security testing proves that controls
- work under attacker behaviour
- Vulnerability scanning detects known
risk indicators at scale
This distinction removed a common source of false confidence and set realistic expectations for each category of tool. Security testing was presented as a way to validate behaviour – negative paths, misuse cases and failure modes – while scanning was positioned as an essential but complementary source of signal.
Tooling integration: Adapting security controls to the stack
Only after principles and practices were clear did the training introduce security tooling, explicitly adapted to the technology stack in use. Rather than promoting a fixed toolchain, the focus was on:
- Why a tool exists
- Where it fits in the lifecycle
- When it should influence delivery
decisions
Static analysis, dependency scanning, SBOM generation, runtime testing, and configuration scanning were all mapped to concrete pipeline stages, emphasising consistency of intent even across heterogeneous technologies and languages.
A special focus was placed on non-negotiable risks – such as leaked secrets or critical misconfigurations – which invalidate all other security guarantees and must always result in immediate action.
Security enforced through the pipeline
The final part of the training tied everything together into a single, operational model: security enforced continuously through the delivery pipeline. From pull requests to pre-release environments, each stage was associated with:
- A specific type of security signal
- A clear decision (block, track or
proceed) - Explicit ownership
This pipeline-centric view transformed security from an abstract concern into a repeatable execution model that teams could visualise, discuss and evolve.
Outcome: Alignment, clarity and confidence
The holistic nature of the training – covering principles, practices and execution – proved to be its key strength. Development teams reported:
- A clearer understanding of why security controls exist
- Increased confidence in how to apply them
- Greater alignment between security expectations and engineering reality
Most importantly, security was no longer perceived as an external constraint, but as an integrated part of professional software engineering.
Conclusion
Exporting security best practices to professional development teams is not about transferring rules, tools or compliance requirements. It is about transferring a coherent security model that spans the entire lifecycle.
When organisations approach secure development from a 360º perspective – grounded in principles, reinforced by best practices and enforced through automation – security stops being an afterthought and becomes part of how quality software is built.
