Security shift left DevSecOps, SecDevOps …

DevSecOps is a culture, practices and tools which aim to shift security left from early stages and during the entire Software Development Lifecycle.

Okey, We all know that security is important, but why bother shifting Security left instead of doing it at the end of the cycle as we usually do?

• It helps everyone in the team understand security requirements, think, design with security in mind and collaborate proactively with security teams
• Vulnerabilities are identified at early stages: Cost and impact on companies’ reputation is much higher if issues are detected on production or lately.
• Security checks are automated to prevent or reduce human errors
• Collaboration and communication between teams are improved which speeds up the delivery iterations.

DevSecOps Culture:

When implementing DevSecOps culture we should break the silos between Development, Security and Operations teams and make them collaborate and share responsibility to achieve a common goal (building and delivering value to end-users).

In addition, all stakeholders should be aware of the impacts and risks of security vulnerabilities with general awareness sessions. And more detailed training should be set up for each role within the team (common security features and requirements for product owners, common security vulnerabilities, how to fix them and secure programming for tech teams …)

DevSecOps Practices:

- Knowledge

The organization should encourage everyone to deliver open security dojos and sharing sessions.

Detailed Training should be scheduled and provided by internal and external experts in different security areas.

Security awareness is not limited to tech teams; business teams should be well trained to take security into account when expressing their needs and testing the increments and delivered product.

- Process Guardrails

Some interesting checks could be set during SDL process:

• In the Definition of ready, it would be interesting to check that access controls, resource ownership and security specifications are provided. And maintaining a list of common security user stories and risky feature will be very helpful.
• Code review practice should consider security concerns. We will discuss different tools in the next section, but they should be there as complement to human checks.
• In the Definition of done, we should check that security tools (SAST, Dependency check …) didn’t raise any vulnerabilities, and all security risks are mitigated.

- Security Champion

In the beginning of DevSecOps implementation it’s interesting to have a role of security champion. A security champion is a tech team member having security skills and real interest on different security challenges, its role mainly is to smoothly bridge the gaps Dev-Sec and Sec-Ops. The successful DevSecOps implementation is the vanishment of this role and at the same time everyone is becoming a security champion.

- Observability

Observability pillars should be enhanced with security aspects (Security logs, metrics, and data analysis/visualization)

DevSecOps Tools

Tools help automate security checks to avoid or reduce human errors. Some tools are used on developers’ machines, others on the pipeline at different stages and others on deployment environments.

Owasp web site is a great index of different tools, and every organization should choose the rights tools according to their own specifications.

https://owasp.org/www-community/Free_for_Open_Source_Application_Security_Tools

Hereinafter some good open source alternatives to commercial tools:

SonarLint

SonarQube (SAST is performed in addition to code quality)

OWASP ZAP one of the most popular web apps security scanning (DAST)

Dependency check (An implementation example in the pipeline will be detailed in the next article)

Dependency Track (An implementation example in the pipeline will be detailed in the next article)

NPM Audit Resolver (js dependency scanning tool)

Clair for docker images scanning

And

Security doesn’t end with development lifecycle; security audits and checking for vulnerable and out-dates dependencies should continue.