.svg "bjss_logo_25_Blue&Navy (RGB)"){kind=logo}
DevSecOps and the need to 'shift left'
DevSecOps is a combination of teamwork-based development and security practices that are turned into repeatable, testable, and measurable components. The process is accomplished using a methodology called ‘Security as Code’ (SaC), a way of writing code to ensure security is kept up-to-date and any issues are detected earlier and faster.
Whereas traditional DevOps integrates and automates software development (Dev) and IT operations (Ops) to improve and speed up development processes, DevSecOps adds security into the mix.
Rather than a siloed security team bearing total responsibility for an organisation’s cyber defences, each delivery team is accountable for ensuring their software is secure.
Bringing together teams ranging from developers and security researchers, to architects and business analysts, sits at the heart of the DevSecOps movement.
DevSecOps also requires that security be introduced and tested much earlier in the project lifecycle, or, further to the left. To ‘shift left’ has become an underpinning mantra that reinforces the message that true security requires much more than retrofitting firewalls.
The DevSecOps Manifesto
So that DevSecOps can be implemented in full, a manifesto has been compiled which outlines some simple aims for organisations to work towards:
- Leaning in over always saying “no”
- Data & Security Science over fear, uncertainty, and doubt
- Open contribution and collaboration over security-only requirements
- Consumable security services with APIs over mandated security controls and paperwork
- Business-driven security scores over rubber-stamped security
- Red and blue team exploit testing over relying on scans and theoretical vulnerabilities
- 24/7 proactive security monitoring over reacting to an incident
- Shared threat intelligence over keeping info to ourselves
- Compliance operations over clipboards and checklists.
Embedding Security and Freeing Teams
At BJSS, we know that for security to perform at its optimal level, it must be automated through the development lifecycle. This recognition powers our people-centric DevSecOps approach, with security seamlessly weaved into the delivery process.
That automation should sit at the core of our people-centric approach might seem contradictory. However, by automating processes, we ensure repeatable, high-quality results that free teams to focus on more mission-critical tasks, confident that security is embedded into the entire development process.
BJSS weaves security into development processes in several ways:
- Infrastructure as Code (IaC) uses coding tools to store information about the infrastructure, leaving automated systems to then make any future changes.
- Immutable Components are used where possible to eliminate the need for traditional configuration management.
- Threat Modelling is used as a structured process to detect, analyse, and mitigate potential risks, threats, and vulnerabilities, and create a prioritised view of these items. This helps remediate issues as early as possible.
- Development Tooling is designed to run continuously within the developer’s Integrated Development Environment (IDE) and on centralised build infrastructure. These tests include analysing the source code using SAST tools and introducing regression tests that would fail if security assumptions change.
- Build beyond the rapid feedback during development. Slower, more thorough security testing should be added to build processes such as scanning third party dependencies for known vulnerabilities.
- Test after the application is deployed into a lower environment. DAST tools can be used for vulnerability scanning with blackbox methodologies. RASP runtimes can be tested for coverage checks and other tools, and user journeys can be tested with simple or advanced fuzzing.
- After deployment, continuous vulnerability scanning, automated pen testing and even automated chaos testing can be applied. Metrics such as rate of authentication and authorisation failures should be incorporated into monitoring and alerting systems.
- Peer reviews and version control audits are then performed continually to ensure optimum service quality.
Total consistency is maintained throughout the journey, from design to deployment, to creating feedback loops. Test environments are kept identical to ensure accuracy of results, and all processes are designed to be repeatable and auditable.
BJSS and DevSecOps
For an organisation to remain protected against modern threats, all stakeholders must understand the organisation's risks, security posture, and why security processes are critical for business continuity.
BJSS is committed to helping organisations internalise the importance of security, come to view it as far more than a simple checklist, and to recognise that the parts of the organisation that cannot be seen and cannot be protected.
Armed with a robust DevSecOps security strategy, you will identify and address threats and issues before they become a problem.
With automation becoming a key pillar of the security strategy, the responsibility of all infrastructure might lie with the dedicated engineers, but the responsibility of security as a process lies with every member of the organisation. The stakeholders will make sure the right time, budget and resources are allocated to create these security processes.
Security is a people problem. Training and developing the right culture will help shape long term strategy and improve security posture from the ground up. Security should be everyone’s responsibility.
Learn the impact of improving your DevSecOps approach by booking a 30-minute session with BJSS' Managed Security Services Team here.