In part one, we brought together three of Adaptavist’s top DevSecOps experts – Principal DevOps Consultant, Peter Daugavietis, Principal DevOps Consultant Timothy Chin, and Consulting Team Lead, Jason Spriggs – to share their observations and expertise about the rise of DevSecOps, top tools and integrations.
Here, they dive a little deeper into implementation to discuss when organisations should start their DevSecOps journey, the challenges they might face, and the benefits they can look forward to.
Should organisations wait until they reach a particular level of maturity before implementing DevSecOps?
Jason: I’d say no. It’s much easier to get everyone on the same page when an organisation is smaller and make the security mindset part of your process and grow with that in mind. With SecOps, even if you aren’t at the level of DevOps readiness, start to have those conversations and make sure the right people are involved in the decision-making.
What if they don’t have CI/CD pipelines?
Peter: I don’t think it’s ever too early to start worrying about security. You definitely don’t want your company information just out there on the internet for everyone to see.
A pipeline is just an implementation of a process. So as long as you’re starting to add security in at the process layer, you’re on the right track. For an immature team, that would be a manual step on release. Once you start building pipelines and having automations in place, you can start shifting left more and more, and reaping the benefits.
Timothy: We should all start thinking about security and implement it as soon as possible, whether it’s automated or not. If you’re less mature, maybe start with an easier thing like static scanning, and as the team matures, we can bring in ephemeral environments to do automatic DAST scanning.
Jason: Just because there is a scanning tool in the pipeline that doesn't mean it has to hold up development.
Peter: Exactly. A tool like Snyk can scan your code repositories automatically and generate reports, but they’re put off to the side, so you can deal with them as and when you have time. It’s something that can be done regardless of pipeline and size. Give it access to your GitHub repositories and your GitLab repositories, and it will take care of itself.
Is there any friction between teams (developers, operations and security) while implementing DevSecOps?
Timothy: Going back to the cosmetics company, for them it’s not a problem we’ve introduced DevSecOps into the process because they don’t want to have any security issues. It boils down to a balance of whether those security issues are a blocker to teams. At the moment, we’ve made CVEs a blocker if they’re critical. The development team accepts that they have to fix that security issue before the next release.
Does the size of teams impact implementation?
Jason: Not necessarily. The two biggest contributing factors are a) the amount of industry regulation around an organisation and what guidelines it has to follow, and b) how closely tied together the engineering teams are with the security teams and the product teams. The product wants a bunch of new features, they care about going fast and making market decisions, whereas security has competing priorities. The engineering teams need to be able to weigh both of these and understand that while something security-related might not add direct market value to the business, there’s certainly business value to fixing security issues.
One of the ideas of agile is a cross-functional team. It’s much easier to have a cross-functional team with fewer people because you have a threshold you can get to, and then you have to scale. All these enterprise-level companies have teams for each piece of the puzzle, and they don’t necessarily talk to each other. The tricky part is building cross-functional teams, making sure you have everybody at the table, sharing information and getting concerns from relevant stakeholders.
The changing landscape of DevSecOps: in the land of consultancy
In this video, three of our DevSecOps wizards: Principal DevOps Consultant Peter Daugavietis, Principal DevOps Consultant Timothy Chin, and Consulting Team Lead Jason Spriggs, sit down with Adaptavist's Head of Solutions Strategy, Jobin Kuruvilla, to share their insights.
Are there any other challenges in implementing DevSecOps?
Peter: Traditionally, security and auditing were always left to the last minute, and they come running in at the end. With integration into pipelines, that’s changing. But developers don’t like stuff getting in their way when they’re on a roll, and people are naturally averse to change, so there’s always going to be a bit of a grumbling. Even if there are conflicting priorities or thought processes, it’s important to keep in mind that we’re all coming at it from a place of wanting to make things better and more secure. And changing the culture to a more collaborative, blameless environment is the best way to do this.
GitLab’s dashboard puts metrics in front of all stakeholders. What are some of the key DevSecOps metrics to pay attention to?
Peter: The simplest ones are the number of CVEs and their rating.
Timothy: All tools return a value of severity, whether it’s dependency scanning or security scanning. It then becomes a threshold, how many criticals have been fixed, reported, introduced and the same for other severities. There is a certain threshold that every company should invest in figuring out, and make sure certain numbers go up, down, or stay the same.
Finally, how are the benefits quantified in terms of cost?
Timothy: It’s important to remember cost is not only about the tools and the resources you spend learning and implementing those tools. We must also consider the cost of security incidents. Are we paying extra money for people to come in on the weekend to fix issues because we don’t have those security processes? Are regulators going to come after the organisation if they don’t meet the security requirements?
Peter: There’s reputational damage too. You’re basically buying trust insurance where you have trust in your pipelines because you can see the metrics about them and see they’re healthy. I can trust a bank to keep my money safe because they have checks and balances, they have a proven track record, and they don’t have data breaches. If that trust is ever broken, it’s next to impossible to get back. Through the judicious use of DevSecOps, you build that trust, and you build that quality.
Our experts are by your side
Want more expert advice and insight from Adaptavist? We can help you with all your security requirements, from assessing your maturity to DevSecOps consultancy, helping you protect your software, meet your business goals, and stay ahead of the curve.
