How DevSecOps can make your ISO 27001 based ISMS more mature


ISO 27001 details the general requirements for information security, but before we get into the details let us start with a slightly overdrawn picture of Information Security. Why? Because it is a strange thing. Nearly everybody knows it. Most people already came into touch with it directly or indirectly. They tell you how important it is and how bad it would be if a cyber-attack happens. But on the other hand, Security Officers trying to implement security measures, often have to deal with pushbacks:

  • The “security-guys” are always blocking or slowing down the most profitable projects for the business side.
  • The developers and system administrators only see the additional workload added to their jobs due to security.
  • It seems a kind of sport to circumvent security measures in the most creative way for many end-users.

How practical security can be

We don’t want to be a doom-monger, it’s not always as bad as we just described it, but people working in Information Security might recognize some of the above stories for a longer time. Complaining is not the reason for this article; it explains how practical security can be implemented in a very early software development stage using DevSecOps.

At the same time, it relates to the more theoretical and compliance-orientated Information Security Management Systems (ISMS) most companies have in place today. There are several ideas on how to combine both approaches. We will focus on a relatively new one: OWASP DSOMM, the DevSecOps Maturity Model from the Open Web Application Security Project.

ISO 27001: well known and widely used

Let’s start with ISO 27001, the Information Security Standard most of our customers’ ISMS is based on. While ISO 27001 defines the general requirements, the associated ISO 27002 gives a detailed list of required and recommended documents. It measures controls from organizational topics like a well-defined Information Security Organization over processes (on-/offboarding, incident response, supplier management), up to detailed requirements like a password policy or a well-defined roles and responsibilities matrix.

What is really needed

People complain about the ISO-Standard requirements and controls because it changes their daily business; it’s too high-level. Many want to have precise requirements they can use and implement directly, but unfortunately, the pure ISO 27001 / 27002 is not working on that level. A mapping between the high-level and the low-level practical implementation for day-to-day operations is needed.

Therefore, we focus on one new mapping-idea: one part of the requirements listed in ISO 27002 is a “documented system development process” (section A.14). This is where DevSecOps and the OWASP DevSecOps Maturity Model (DSOMM) come into play.

Why DevSecOps makes sense for your organization

DevOps (combination software development – “Dev”; and IT operations “Ops”) is also well-known in the software development industry for years. Its target is to shorten the systems development life cycle and provide continuous delivery with high software quality. Such software development based on DevOps is often implemented within the framework of agile approaches like Scrum or Kanban, as both ideas aim at the same target: short life cycles and continuous delivery.

DevSecOps (DevOps with deeply integrated security – “Sec”) was added to DevOps later, as people realized that implementing security already in an early development stage has several advantages. Possible security issues are recognized early, and a fix is unnecessary during or in a late development stage. As a rule of thumb, the later you identify a security issue within the software life cycle, the more expensive it will be to fix it.

Identifying security issues

Relative costs to fix bugs, based on time of detection

Taking care of security bugs already during the development phase (requirements, architecture, coding, integration, component testing) could save plenty of resources – time and budget, as well as poor team motivation.

Coming back to the initial pushbacks security officers have to face, DevSecOps would satisfy several parties:

  1. Firstly, the business-side
    1. gets no (or at least less) late “blockers” from security
    2. gets lower costs as well as more in-time- and in-budget-projects due to early bug fixing
  2. Secondly, the developers and system administrators
    1. have to deal with fewer security issues during test and implementation, which could save plenty of time
    2. automatically educate themselves to do it in the same and more secure way in future projects, as the overall process was more straightforward and less frustrating

As just described, performing software development with the DevSecOps approach has many advantages. The problem is how we can use this rather practical and development orientated approach as input for an ISO 27001 based ISMS, for example:

  • how to store secrets,
  • how to handover confidential parameters, or
  • how to do an inventory of running artifacts, and so on.

This approach does not handle these topics on such a detailed level. The input is necessary to document and prove what is done to reach specific ISO 27002 controls. Anybody ever taking part in an ISO 27001 based audit knows how important such information is and how focused most auditors are on the SoA (Statement of Applicability). The SoA documents exactly such links between an ISO 27002 control and the technical or organizational measure a company has implemented to address it.

Combining them: the OWASP DSOMM approach

The project team of OWASP DSOMM recognized this need as well. Relatively recent, a mapping from the DSOMM topics to the ISO 27002 controls has been added. Some of our clients working by DevSecOps use this mapping already. The ISMS-maintainer can directly map the measures performed during DevSecOps to the corresponding ISO 27002 controls as listed in the SoA. Most DSOMM mappings refer to A.14 (documented system development process) and some to controls like A.12 (operations, backups, monitoring, etc.), so the coverage is already relatively wide.

So using the new DSOMM-ISO27701-mapping could be a bridge between the high-level ISMS and the low-level software development process. We highly recommend discussing this topic between the product- and risk-owners of the development-teams and the Information Security Officers (CISO). It’s one step closer to more mature and secure software. At the same time, also one step closer to a mature ISMS.


Are you doing software development in your company, either for self-use or as a product for others? Do you care about Information Security, not only in theory but also on a practical level? Well, then you definitely should take a closer look at DevSecOps in general, especially if your development teams work agile already. We at CISO AG help you automate the core security tasks and implement them into your DevOps workflow.