The changing landscape of DevSecOps part 2: challenges

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.

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.

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.

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.

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.