Why Security Engineer Need “Shift-Left” to DevSecOps?

“Because the only difficult thing about DevSecOps is to pronounce it” — DSO LATAM 2020

If you were currently doing or trying to do DevOps adoption, the next step you need to think is how to make your CI/CD pipeline secure. It’s not only the DevOps team need to aware about security. Hence DevSecOps promote “Security” is everyone responsibility, and it just starts at the beginning of the product/application planning. Let’s see the common pitfall in an organization regarding security and compliance below;

1.Company:

Failure to recognise Cybersecurity basics:

• Relying on antivirus as a single security layer.
• Failing to encrypt sensitive data which is an open invitation for attackers.

Lack of Cybersecurity Policy:

• Cybercriminals aren’t only targeting companies in the finance or tech sectors. They’re threatening every single company out there.
• Hence, Security standards are a must for any company.

Not Enough IT Security Management:

• Most critical cybersecurity alerts may get missed, and successful attacks may not be eliminated in time to minimize damage.

2.Application Developer

Uses Open-Source library which has a lot of security bug risks:

• Most developers use open-source software or libraries. Not all open-source components are not created equally; some of them remain vulnerable from the start while others get worse over time.

They don’t have formal Application security training:

• Most developers don’t have basic Cybersecurity and always put security measure to either internal or external security engineer team to access their apps.

Lacks a recovery plan for vulnerability risks:

• Most of the time, when something terrible happens in the Production environment, they clueless and don’t know who or how can they resolve the security issue.

3. Application / Information Security Engineer

Not involved in product design/development:

• In DevOps or Agile team structure, they either different team or external consultant and with DevOps approach they most all the time not involved from the beginning of the product design/development.

The last person to handle security and compliance issues:

• Their involvement always at the last of the process or whenever the team has a security issue.

Cannot compete with Agility and Speed of DevOps team; added to the pain due to lack of CI/CD knowledge:

• With DevSecOps CI/CD pipeline, most of AppSec/InfoSec not familiar with Continuous Integration (CI) Tool and made them hard to collaborate with the DevOps team.

If we are looking back to the Traditional Security Testing approach, it always has done between Release and Deploy state, or it will be done after we deployed our code in the Production environment;

Nowadays, we have the solution for all problems I mentioned in early slides, and we can use DevSecOps and Shift-Left approach.

First, What is Shift-Left?

Now, let us see what DevSecOps is?

Why should we transform to DevSecOps & Shift-Left?

There are five(5) practices or areas in DevSecOps ;

There are five(5) practices or areas in DevSecOps ;

The 1st practice is People,

• To start your DevSecOps journey, you have to convince your Senior Management. Security Champion need to play a vital role to make everyone streamline with the shared goal on the security part.

2nd is process

• In general, different teams within an organization execute various tasks, with DevSecOps, everyone works on commonly agreed-upon processes and executing them to strengthen the extent of security in development.

3rd practice is Shift-Left

• As I mentioned earlier, this approach gives you the advantage of detecting your security issues and fix them faster.

4th is Automation

• Automation is a crucial feature of DevSecOps to match the speed of security with your product delivery in a CI / CD environment; security automation is a must.
• Choosing and continuing learning with the right security automation tool is key to the success of your company’s products.

5th or The last DevSecOps practise, Practice Secure Coding

• Due to Dev, IT Ops and Security work in silos, hence organization can invest in sending them to training and upskilling them with DevSecOps. With training, everyone will implement/secure coding code in their works.

Now I like to discuss the DevSecOps approach, here the overall DevSecOps stages with DevSecOps technique that we can apply;

1.Developer

· Pre-Commit Hooks IDE Plugin — Scan all credential and sensitive data in Developer machine before commit/push it to Source Code Management

2.Source Code

· Secrets Management — For scan all the token/password in your code repository.

3.Pre-Build

· OAST / Software Component Analysis (SCA) — for Open-Source Dependency Security test

· Static Analysis Security Test (SAST) — Or known as White Box Security Test and it scans through your code. It represents how the developer approach.

4.Post-Build

· Dynamic Analysis Security Test (DAST) — Or known as Black Box Security Test, and it represents how outside hacker approach.

5.Artefact

· Artifact Security Scan — It used to detect security vulnerabilities and licenses in your artefact components or binary.

6.Production

· Compliance As a Code (CaC) — All text compliance policy converted into automation code and using Infrastructure as a Code(IaC) tool to verify your application.

· Inspec by Chef — supports all major operating systems, allowing you the freedom to run compliance and security tests anywhere.

· Alert & Monitoring — the analytic tool used to issue the alert when the security issue detected in your application

Using the right automated tools that help secure your product across the CI/CD, the development teams will power up to meet release deadlines with high-value deliverables without the need for security to send them back to the developer team when they are approaching the finish line.

Developer:

1. Talisman
2. SonarCloud

- scan through sensitive/secret in developer machine

Source Code

1. Git-secret
2. Trufflehog
3. Git-Hound

- scan your code repository for secret, token, password

Pre-Build

1. Retire.js — Java
2. Safety — Python

Post-Build

1. Bandit — Python
2. Checkmarx
3. Nikto
4. OWASP — ZAP
5. NMAP

Artefact

1. JFrog — Artifactory
2. Sonartype Nexus

Production

1. Inspec

Vulnerability Management

1. DefectDojo
2. Archery

Here an example of DevSecOps Workflow:

1. On Developer — Once they commit/push a code change, Talisman will scan and validates the outgoing changeset for things that look suspicious — such as authorization tokens and private keys. Once all ok, your code pushed to GitHub as your source code management.
2. When there is Pull Request(PR) created in your GitHub, SonarCloud will be triggered and analyze your Pull Request codes. SonarCloud will come up with Code Analysis such Security issue like bug, vulnerability, code coverage & duplications.
3. Once PR has done, GitHub will trigger auto-build to Continuous Integration(Jenkins/Azure DevOps/Circle-CI) Server/Tool or also know as CI pipeline.
4. We do the Software Component Analysis(SCA) and Static Analysis Security Test(SAST), for example, using Pyhton -Safety to scan the Open-Source or Dependency. Once done, we can create an artefact or docker image. Lastly, in the CI pipeline, we stored artefact to Artifact Management.
5. On the DockerHub, we use JFrog Artifactory to scan through all layers of a Docker Image.
6. On Test, Staging & Production environment, we can use the Dynamic Analysis Security Test (DAST) such as NIKTO, NMAP, SSLyze, OWASP-ZAP baseline and INSPEC by Chef for server hardening. We also can publish all the security issue to Defect Dojo for remediation and fix action.

Here some tips on how you can start your DevSecOps journey;

Conclusion

I think that every company/Security Engineers must make an effort to “Shift-Left” to a DevSecOps culture or methodologies and come up with a multidisciplinary security team. Approaching “Security As a Code”, moving security practices to the left and educating software developers on critical testing and security practices are essential aspects to engage security as part of the DevOps process. The key is to be ready to start, to encourage experimentation, to be willing to fail, to learn and to move forward one step at a time.