7 Beliefs about DevSecOps that are just not true
DevSecOps has increasingly been adopted in response to digital change. It empowers teams to believe security isn’t self-serving and can be used to directly benefit business goals. Teams are realising they are able to embed security whilst deploying applications at speed, automating operational tasks and gain better security insight into their changes. I have realised for many in this journey, the implementation of DevSecOps comes in different shapes and sizes. I have equally seen this journey misunderstood. Here are 7 practices that I’m seeing / hearing that are simply just not true.
1. DevSecOps is a tool / pipeline / panacea
Teams are forcing blueprints, failing to recognise some of their decisions are leading to overspending. I see the panacea view come out in 3 different guises; a) the silver bullet architecture, b) the DevSecOps pipeline and c) the assumption it’s exclusively tooling.
I am sometimes asked “create a best practice DevSecOps architecture”... and that’s without any root cause analysis - understanding of business / security / product challenges, digital ecosystem, risk appetite, threat exposure, business constraints and broad goals. There are levels of enforcement you need to apply based on the risk of your ecosystem for this to effectively work.
Another example is “implement me a DevSecOps pipeline…”. Pipeline security is really important, but there’s the implicit assumption DevSecOps starts and ends at the pipeline, which is far from the truth. The pipeline is a resource much like your containers, APIs and cloud services. Equally, building a separate pipeline can go against product team goals and securing your existing CI/CD pipelines might be a better way of embedding security.
DevSecOps is far from just a set of tools and we can easily forget the softer glue that binds it all together:
Supporting processes like threat modelling to review solution designs and scope security user stories.
Ways of working like embedding security champions to evangelise security at scale, raise issues and remediate vulnerabilities.
Cultural goals and measuring the success of security by being able to continue to release early and often, whilst burning down cyber risk and vulnerabilities.
Effective Governance that is reportable and has the intelligence to realise controls that require mandating v.s. Controls that are optional enhancements.
Removing time consuming security work for developers by enabling hardened templates and resources to be available (frictionless security).
2. You can just hire DevSecOps engineers and leave them to it
The sentiment I completely understand, you have a challenge and in this case it’s securing products, so lets hire some experts to help fix it - makes sense!
However, this direct approach is like running a restaurant and hiring more chefs because customer demand is really high – sure this works in the short-term but you’ll begin to realise scalability issues - your kitchen isn’t big enough and you now need to more dishwashers, waiters, real-estate etc. The operational impact on your teams and finances is higher and you risk suffering in the long-term for short-term gain.
Stepping away from the analogy and take this to your IT ecosystem. Be more strategic and think longer-term – what can you do now and how does that impact the big picture. If you perceiver with hiring DevSecOps engineers you will begin to realise challenges in:
Standardising security across different projects becomes a challenge as each engineer will have their own opinion / method.
Having equal commitment on security from all your product teams.
High expenditure as DevSecOps engineers can be expensive to hire.
3. Companies have sufficiently prioritised DevSecOps
Not something I always hear, but a behaviour I typically see with the procurement of tooling. You don’t need to blow the budget by buying the best tools - in any case an open-source code scanner or a cheaper licensing package is enough to tell you about the vulnerabilities you need to fix. But the moment you need more insight, is when this quickly becomes more difficult to address and expensive, which is often informed by the risk profile of your product. For example you might need compliance views, attack path mapping, remediation suggestions, trend analysis across projects, visibility of the latest zero-day, reporting capabilities, automated responses etc.
If you haven’t correctly prioritised DevSecOps time, people and budget, you will be spinning wheels trying to achieve simple tasks without moving the dial on the security posture of your products. This can be a slippery slope.
4. Centralising my DevSecOps team is the best approach
This really requires root cause analysis of where your challenges actually exist and whether you have the budget to build a DevSecOps team. You must also be conscious the moment you begin to build a centralised DevSecOps team - you create the culture that security is someone else’s problem.
Typically a vulnerability in code belongs to an application / infrastructure owned by a product / platform team. Inherently the product owner / team should be the one responsible for remediating the vulnerability - not security. You can look at this in the same vein as deployment, integration, testing - the product team are usually responsible for these and security should be no different.
This is the operating model space and although I have a strong opinion, there is no blueprint to follow - it’s all about organisational best fit. If you have testing teams, deployment teams and integrations teams - then there certainly is a fit for a group of security engineers responsible for DevSecOps… but you have to accept there’s a cultural anti-pattern you will feed of "DevSecOps being the security team’s problem".
5. Your DevSecOps staff need to be full-stack security experts
What DevSecOps full-stack means is the ability to securely design and implement across containers, multi-source code, multi-cloud, sec-ops, IaC, pipelines, and now machine learning. These people are expensive, and you while you can afford one or two full-stack experts today, you are running the risk of single dependencies if they leave and scalability issues when you need to grow. This is a model better suited to a start-up that needs to get running fast.
Your DevSecOps staff approach should be segmented and closer aligned to the following:
Broad security architects that inform design decision making and connect with your enterprise and leadership.
Hands-on infrastructure / platform engineers that are deep cloud and infra specialists with experience in OS, IaC and containers.
Hands-on source code experts with limited to specific languages and ability to configure git repos and pipelines.
Hands-on security operation engineers with SIEM engineering experience that connect into your SOC and are able to effectively onboard logs from your platforms.
6. DevSecOps doesn’t apply to SaaS
… and it actually doesn't for all SaaS platforms. Your O365 setup and payroll SaaS apps don’t necessarily involve a workflow where you build and deploy. However if your SaaS ecosystem has platforms (like Salesforce and ServiceNow) where you design, configure, build, integrate plugins and connectors, deploy to live environments and monitor - DevSecOps practices should apply during:
Design: threat modelling, risks reviews, scoping security user stories.
Build: SaaS platforms are configurable via both an interface and code - based on how you are building, native configuration review and code scans apply.
Deploy: your integrations (connectors / APIs), secrets / keys and environment separation / variables.
Monitor: detection, alerting and response during nefarious activity either natively or forwarded to your SIEM / SOC.
Yes we are doing DevSecOps here without containers, images, cloud compute, serverless functions. Call it DevSecOps-lite but the principles still apply!
7. You can just ‘add-on’ security
Bolting security on is an option but doesn’t even give you half of the benefits of DevSecOps. Something we have general consensus on across the security industry, but I do lose count of the amount of times I speak to businesses that fall into this trap. The common pitfalls are:
SAST and cloud scanning only in production.
Lack of environment segregation to test security changes before deploying to production.
Lack of SAST, SCA, cloud security scanning hygiene to separate vulnerabilities in dev to prod.
Over-reliance on penetration testing to inform security design decisions.
Security checklists and standards replacing product based threat modelling.
You need supporting processes, design-led thinking, leadership buy-in, people fulfilling roles, measurable security activities, security effort calculated across your value stream, governance structures, escalation points and a real understanding of the critical components of your service/application/platform.
