7.2 C
Tuesday, April 23, 2024

DevSecOps: Why You Should Put “Sec” in DevOps.

In a short period of time, a span of less than a decade the IT infrastructures have undergone huge changes. We see more shared resources, on-premise infrastructures turning into hybrid environments or migrating completely to the cloud. IT has become more demanding in terms of speed and efficiency while management is demanding less costs.


Why You Should Put "Sec" in DevOps.

The ability to deploy from entire new IT environments to servers, networks, databases and applications has become the norm. DevOps is well known to most pros and organizations. DevOps materialize this ability and the principle of application development and IT Operations under one roof and shorten the systems development life cycle through continuous delivery/integration.

- Advertisement -


The ideal practice would be that security is an integral part of the entire application development. Security should be built-in and not around the application its components and the data.

In DevOps you aim to automate as many parts of the application development as possible.

The same applied to DevSecOps but security audit is included.

security audit


When we say “built-in” what exactly do we mean? How can we accomplish the seamless integration of security into DevOps?

Cloud Security Alliance (CSA) has published a document to define six focus areas of DevSecOps critical to implementing and integrating DevSecOps into an organization.

  1. Pillar 1: Collective Responsibility
    Security is not something ephemeral whose progress and contribution cannot be measured. Each person in the organization has their own security responsibility and must be aware of their own contribution to the organization’s security stance.
  2. Pillar 2: Collaboration and Integration
    Without pan-organization collaboration around implementing security, success is going to be limited. Security can only be achieved only through collaboration, not confrontation. A security aware and collaborative culture is necessary for the members of all functional teams to report potential anomalies. The human factor is often the weakest link; in fact, or indeed, and remember that most security incidents are caused by simple human error.
  3. Pillar 3: Pragmatic Implementation
    Since every software lifecycle is different in terms of structure, processes and overall maturity, there is no one-size-fits-all set of tools to implement DevSecOps. organizations often end up procuring procure tools and point solutions that are hard to deploy, harder to operationalize and eventually do not provide actionable insights that can help mitigate the true security risks. Organizations need to take a holistic view of the software lifecycle, their security needs, and the future state they want in order to choose platform solutions that offer a high degree of integrability.
  4. Pillar 4: Bridging Compliance and Development
    The key to addressing this gap between compliance and development is to identify applicable controls, translating them to appropriate software measures and identifying inflection points within the software lifecycle where these controls can be automated and measured to improve the quality of risk mitigation and therefore compliance.
  5. Pillar 5: Automation
    Without automated quality checks, manual coding can easily result in poor performing and insecure software that needs rework. In addition, manual and poorly-timed testing reduces the chance that vulnerabilities will be identified before deployment. Manual deployment and patching practices can result in insecure software from being released to production. Automated security practices are the core of process efficiency because they can reduce manual processes, increasing efficiency and reducing rework.
  6. Pillar 6: Measure, Monitor, Report and Action
    Without actionable metrics, progress cannot be measured and failures cannot be detected in a timely manner. Some of the most critical metrics to monitor in a DevSecOps environment are deployment frequency, vulnerability patch time, percentage code automatically tested, and automated tests per application. The results during software development as well as post-delivery must be measured, monitored, reported and acted upon by the right people at the right time (continuously) for DevSecOps to succeed.

You can read the full CSA document here

Website | + posts

Dimitris is an Information Technology and Cybersecurity professional with more than 20 years of experience in designing, building and maintaining efficient and secure IT infrastructures.
Among others, he is a certified: CISSP, CISA, CISM, ITIL, COBIT and PRINCE2, but his wide set of knowledge and technical management capabilities go beyond these certifications. He likes acquiring new skills on penetration testing, cloud technologies, virtualization, network security, IoT and many more.


Also Read