Governance, Risk and Compliance in DevSecOps

Onkar Dhane
Sep 7, 2018 · 6 min read

DevSecOps-Spectrum: Holistic view of DevSecOps framework to solve Risk Assessment, Governance and Security Policy problems in DevSecOps

This is a 2 part series of DevSecOps-Spectrum. In part 1 I will cover what are the over looked challenges in DevSecOps and why you need DevSecOps-Spectrum

Many organizations are moving towards DevSecOps and why not? As organizations are fined millions of dollars because of security breaches. A lot of organization are already using DevOps to build software with pace but got themselves in a situation. Yes, you’r right “those over smart security guys” are to blame for the slow delivery. Often Security is looked as barriers by development team. Only time when Security team is at importance ..

“Call Security Team… We have been Hacked”

What exactly is DevSecOps?

I see many terminologies that are used in context of “Security in DevOps”, those are DevSecOps, DevOpsSec, SecDevOps, Rugged DevOps! Well here is what I think of DevSecOps.

“An approach to build a secure software with pace and an ecosystem built on automation.”

No technical jargon ? C’mon you must have missed something. Unfortunately this is current state of industry looking forward to jump the hype train. Whenever DevSecOps is being discussed everybody starts talking about CICD, SAST, DAST, IAST,OAST, RASP and many more security jargon that most of the developers and IT guys don’t even understand. Why DevSecOps has became a tool thingy and less Process Oriented, Security policy driven framework which solves the problems and does not complicate things.

Ideally Security is an integral part of DevOps but due to lack of security knowledge devops teams struggle to implement DevSecOps. Even after training DevOps guys to use a lot of security tools, organizations are still facing problems incorporating security into pipeline or as I say not able to reduce the overall risk by implementing security ecosystems?

Challenges in implementing DevSecOps from Basic to Advanced DevSecOps pipelines.

Challenges faced by Basic DevSecOps implementation

  1. Tools, tools, tooools ( CICD, SAST, DAST, OAST, IAST, RASP “Add your acronym here” ) A lot of tools != More Security.
  2. Limited or no insight into DevSecOps pipeline(How’s this thing working?)
  3. Using combination of manual and automated processes, making more complex system than ever before (Its automated but first I need to do x thing)
  4. Nobody is willing to take responsibility (who’s the admin again?)
  5. Security findings/vulnerabilities management still follow old processes(Share VA reports with Developers)
  6. False Positives

DevSecOps story ahead . . .

Dev 1: Here is the report from our fancy overrated SAST tool from DevSecOps pipeline.

Dev 2: Thanks, I will prepare remediation plan but … umm.. you sure these 8276 vulnerabilities are genuine and unique? :(

Dev 1: I dunno! The report is from rainbow shitting thing we got here. (off course talking about Immature DevSecOps implementation)

Challenges faced by Advanced DevSecOps pipelines

  1. Governance — It still tops the list of challenges faced in every mature DevSecOps implementation. Once you are done with the setting up a pipeline, teams are now left with governance part. How do you fail a pipeline based on custom criteria? Many plugins provides standard a way to fail a pipeline based on vulnerability count/severity. This works for small organizations with no critical business but for financial, health and government domains, they have to follow certain standards and policies. Manually coding these policies is cumbersome tasks and you should refrain yourselves from creating a lot of security policies to avoid policy abomination. It becomes more difficult to manage these policies
  2. Release Management — This is again one of major challenges in DevSecOps. Due to “wall of compliance” between DevOps and Security Release Management is suffered. DevOps teams look at security as a barrier instead of guard-rails because security slows down the pipeline. Even after integrating Security Tools, (SAST/DAST/IAST) Release Manager has to comply with the standard processes. Release Manager is involved into decision making whether to push the build to production. Release Manager must take into consideration Financial,Reputation, Operational, Compliance, Technological Impact & DevSecOps Reports. Unfortunately this activity is performed manually due to risk and its nature even after integrating a lot of tools like ARAs (Application Release Automation) organizations don’t trust automated releases or Continuous Deployment to be specific. A lot of pipeline follow Continuous Delivery but hesitate to follow Continuous Deployment and the reason lies in combined approach (Risk + Release Management + Governance).
  3. Risk Score system — Still a lot of organizations are using an excel sheet to calculate Risk Score. This is absurd driving whole organization based on an excel sheet! meh ! They are backed with state of the art “excel macros”. The reason behind using excel sheet is the organization policies, structure and nature of business, it varies from business to business and no tool can satisfy all the needs of an organization so they ditch GRC tools and see what works for them. Instead of ditching GRC tools organization now can create custom wrappers, expose APIs and embrace GRC tools. We will discuss the details in Part2. When you present a risk assessment report do you really think Managers/Leads are the right persons to accept or reject the risk. Most of the time the risk acceptance is forced down to the developers and its the right choice in my opinion. Developers/security guys understand nature and impact of the risk yet most of DevSecOps pipeline needs Risk Acceptance from Product Managers/Leads.
  4. Collaboration among teams — Organizations create Silos to serve the requirements which creates issues in DevSecOps. Organization still follows email communication in devops. Why to use email communication when you can automate the collaboration and decision making.
  5. DevSecOps as Code — DevSecOps pipelines follows EAC (Everything As Code) approach. If your organization is planning to deploy component of DevSecOps manually, you probably will end up with problems in future. Versioning is important to maintain code, both for Developing an application as well as infrastructure. DevSecOps is continuously changing field and every day there are new technologies. The pipelines should not be rigid to change but should be flexible enough to embrace the change and new technologies otherwise you would be thrown out of the market.
  6. Automated Threat Modeling & Challenges — Threat Modeling is undoubtedly an important part of SecOps. It is the driving factor to create abuse stories and identify attack vectors and in turn helps identify and reduce the risks. Unfortunately this activity can not be automated after some point. It needs humans to identify contexts and think out of the box. Similar like Pen Testing, Automated Threat Modeling can be implemented but to some extent and it needs manual review for now unless someone comes with Machine Learning approach in Threat Modeling which can exceed human efforts with accuracy.
  7. Security Stories — Usually Requirements & changes are mapped to user stories but rarely integrated with Business Impact Analysis, Initial Security Assessment. Automated Threat Modeling creates a ground to write detailed abuse stories but integrating those stories and considering driving factors in DevSecOps is a troublesome task.
  8. Compliance & Audits — DevSecOps is really helping organization to stay Compliant. DevSecOps with Manual compliance activity and Auditing is more time consuming and most of the time creates confusion. If the DevSecOps pipeline does not integrate proper compliance tools and Centralized dashboard to store and process audit trails from different stages in DevSecOps then nobody will understand a thing and will actually creates chaos disrupting the processes. Fortunately If you implement the DevSecOps pipeline considering above scenarios then not only it solves audit and compliance problems but also helps sharing insight into DevSecOps.

So.. How do you solve these problems?

Lets dig in..

“To integrate, or not to integrate, that is the question:”

Whether to integrate DevSecOps into current Processes, Governance model or Integrate Processes, Governance models into DevSecOps?

Ideal approach would be to integrate processes and Governance model into DevSecOps however integrating custom processes and governance models is a tedious task, that is why I have created DevSecOps-Spectrum which clearly draws the boundaries and touches all the components in an organization.

DevSecOps beyond SAST and DAST

SAST/DAST/IAST/RASP tools do provide security to DevOps pipeline but what about other stages in SDLC like Risk Assessment, Compliance, Governance, Release Management. These stages are also affected by Security outcomes and if you keep these stages out of DevSecOps pipeline you probably fall in the category of Semi-DevSecOps and if we follow Maturity models like OWASP DSOMM then you would be DSOMM Level 1/2.

Well There are GRC tools available in the market only challenge is to how do you integrate and let pipeline take decisions based out of it. ( DevSecOps Spectrrum helps solve those)

DevSecOps-Spectrum: A framework to solve Risk Assessment, Governance and Security Policy problems in DevSecOps . . .Contd

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade