Interview with Gayatri Prakash, CloudBees
Gayatri Prakash was co-founder of Neuralprints, a company that created a compliance solution which is now owned by CloudBees. That business was acquired in 2021 by CloudBees, the California-based, venture capital-owned, DevOps management specialist and Prakash now heads the CloudBees Compliance and Security platform.
It’s an increasingly important service at a time when companies are striving to find ways to more rapidly implement security and compliance change. CloudBees’ customers working in regulated markets – not least those in financial services – face a rising tide of new laws and guidelines targeted at improving IT and software risk management.
The Monetary Authority of Singapore has already written IT risk management guidelines. In Europe, the EU’s Digital Operational Resilience Act (DORA), will come into force in 2025, and will be largely mirrored by UK legislation. In the USA, among a range of other rules, the FedRAMP risk assessment framework for Cloud-based security and services is a key compliance requirement that the CloudBees platform addresses.
QA Financial spoke to Prakash about the potential for automating security and compliance in the DevOps pipeline.
Q: Let’s start with how you sold your business to CloudBees. That was a very quick turnaround because you only started working on the product in 2020.
Yes. Before that I was running my own IT services business for 13 years and services in general suffered a setback during the pandemic. During that time we saw an opportunity in this space and started work on this product. We certainly saw CloudBees as a symbiotic partner because they had access to 500-plus customers and continuous compliance goes hand in hand with build automation.
Q. What do your financial services customers need most of all?
At CloudBees my team includes product managers who are security experts with deep understanding of what it takes to demonstrate compliance in a regulated industry. They work with engineering teams to ensure that the product evolves to reflect industry trends and ensure that our out-of-the-box compliance frameworks and security policies are kept updated with both regulatory policy changes as well as security practice changes.
If you have security automated to the point where the decision makers have a clear view of the bottom-line risk, then you have a very defensible position against external threats.
Build automation is in the DNA of CloudBees. But it doesn’t matter how fast or effective your build automation is; if you have to start and stop to meet security and compliance requirements then your delivery metrics and KPIs will not be met because there are disruptive assessments involved in propagating software changes.
The financial services and banking domain is highly regulated and typically the way it works in a bank is that there will be a risk and compliance team that will read that legislation and they translate that into control requirements and then there will be individuals responsible for these controls across all the applications and services developed by the bank.
In a large bank that has thousands of applications but no automated way of measuring compliance or security, then there is no hope of the firm having a real-time view of how each of the applications and services is performing against those control requirements
Another challenge here is that regulatory policies change continuously. And not all applications may be subject to the same requirements in different geographies. It might be that in some places an app may be exempted from a specific compliance requirement, for example if it does not have a mobile component there will be no need for a MAST [mobile application security testing] scan or if it’s a low business impact application, it will not be subject to threat modelling.
Without automation and real-time dashboard, you cannot possibly attest compliance on the 5,000 applications that a large bank might need to manage. Instead, you are relying on a sampling approach, say, the 10 riskiest applications and asking for proof of all requirements before going into production. It’s a productivity drain on all fronts and does not provide clear view of the risks.
Q. But how do you prepare for something like the European DORA legislation where the requirements are not yet specific?
The first stage is automation, but it is not a silver bullet. It’s about having visibility of the current state. You need a system through which you define what good looks like in a declarative way, and then the real time assessment of the digital assets as they progress through the pipeline to see whether they conform to the policies that have been activated for the organisation.
DORA is wide-ranging – it’s about operational and digital resilience. It covers a lot of things outside the SDLC also but what is clear is that the requirements that relate to the SDLC will need to be assessed in as real time as possible, because every time a developer commits code your security posture could have been altered or your risk profile could be changed.
If we look at DORA or other regulations, such as FedRAMP or SOC 2 data management requirements for example, what you find is that there is a large subset of common controls being mandated across all of them; for example around vulnerability management, secure software development processes and so on.
If you can automate those handful of policies across all your applications and services, you can do it in such a way that it provides you with real time indicators of what is effective and what is ineffective or needs improvement across all these policies. We provide policies to provide coverage for this subset and the associated automation out of the box.
The important differentiator is that these policies are not shoe-horned in the CI/CD pipelines because that makes it difficult to scale easily across the enterprise. In our solution they sit outside of the pipeline and declare the ideal state and assess every change against that ideal state. And that allows us to get top-down visibility of security and compliance and ensure that every new pipeline that is created, is secure by default.
The great majority of our customers are also inheriting a large legacy footprint and they need a way to enforce best practices across very different pipelines. So, the solution must be something external; something that sits above all your CI/CD pipelines, interfaces across the tooling landscape, orchestrates security as per the requirements of each application and monitors the entire estate providing you clear visibility of your bottom-line risks.
Q. What about the management of third-party risk?
Third party risk management is a vast area of importance to all our financial and federal customers in the US. Given incidents like SolarWinds, this has bubbled up the priority list for both the regulators and companies. To manage the risk from third parties organisations need a clear visibility of all third party code referenced within their codebase at all times. We provide out of the box integrations to SCA [software composition analysis)]and SBOM (software bill of materials] tools, both open source and enterprise solutions. This allows us to give visibility of all direct and transitive dependencies referenced in all the artifacts in real-time, we generate an SBOM for every artifact that is built. Not only that, when there is a new zero-day threat often the most time-consuming task is to assess the blast radius of the threat across all of your applications and services, even before you prioritise the fixes, fix is usually the easy part. We provide our customers with the insight dashboards they need to search across all their assets and gauge the exposure to a zero-day vulnerability in seconds. All of this goes into building a better approach to managing third party risks.
Q. What do you have to do to make CloudBees the default choice for compliance? What else are you working on?
The biggest innovation area in 2024 will be in AI. We will be looking to leverage AI to augment our ASPM solution.
CloudBees has also developed a brand-new Cloud-native DevSecOps platform, and we are in the process of migrating all the security and compliance automation to that platform so that any component built using our platform is secure by default.
Context is everything when it comes to security. One of the reasons people struggle with security is not lack of information; it’s too much information, too many alerts and not enough time. So, how do we make sure that we’ve taken context into consideration when we flag up problems? We already have context-based risk scoring within the platform and we will be looking to augment this further with AI.
