DevSecOps: Injecting Security into CD Pipelines

Learn how DevSecOps impacts on the CD pipeline and the security posture of agile development teams.

Juni Mukherjee Juni Mukherjee

What is DevSecOps?

O termo DevSecOps é usado para descrever um ciclo de vida de desenvolvimento de software de entrega contínua focada em segurança (SDLC). DevSecOps se desenvolve com base em aprendizados e melhores práticas de DevOps geral. A aplicação de valores de DevOps à segurança de software significa que a verificação de segurança se torna uma parte ativa e integrada do processo de desenvolvimento. Tradicionalmente, e muitas vezes, infelizmente, a segurança é tratada como um sistema secundário. InfoSec geralmente interage com equipes de desenvolvimento mais para o fim do SDLC. Por mais nobres que sejam suas intenções, pode ser frustrante descobrir vulnerabilidades de segurança no fim do SDLC.

DevSecOps promotes traditional security engagement to an active process of the SDLC. General DevOps has introduced processes like continuous integration (CI) and continuous delivery (CD). These processes ensure the active testing and verification of code correctness during the agile development process. Similarly, DevSecOps injects active security audits and penetration testing into agile development. DevSecOps advocates that security should be built into the product, rather than applied to a finished product.

Key in lock | Atlassian CI/CD

Why DevSecOps?

In short: security. The need for safe and secure software is paramount, or else our technology-driven livelihoods will be at risk. Security breaches are one of the largest threats organizations and our governments face today. Several major organizations have been breached in recent times, causing huge fallouts and abrupt C-suite resignations. Failed executives make headlines as consumers continue to lose trust in the compromised service providers.

Princípios de DevSecOps incentivam a colaboração e evitam entregas com atraso aos profissionais de segurança. O valor é óbvio quando você revisa tempos de ciclo antes e depois. Antes de DevSecOps, seu produto pode ser considerado inseguro no último minuto, causando múltiplas iterações dispendiosas. Depois de DevSecOps, os padrões de ouro da segurança são inseridos em seu produto. É possível que você possa encontrar problemas inesperados no último minuto, porém, a probabilidade é muito menor.

So, the point is not as much “Why DevSecOps?” as it is how we can successfully execute in this DevSecOps era. For those entangled in traditional security measures, DevSecOps is a breath of fresh air. Solutions could vary based on your tech stack and your architecture; this is not a “one size fits all” mandate from a centralized organization.

Overall, your security posture enhances your credibility in the market, and builds trust with consumers. With that in mind, this is a good segue way to discuss how DevSecOps ties into the continuous everything paradigm.

DevSecOps and Continuous Everything

Pode haver vulnerabilidades de segurança em bibliotecas de OSS (software de código aberto) que importamos tanto quanto no código que escrevemos. Muitos desenvolvedores estão programando todos os dias, e as revisões de código manuais não são dimensionadas. É aqui que está o verdadeiro poder do DevSecOps.

DevSecOps and continuous everything are like two sides of a coin. DevSecOps works alongside the continuous everything paradigm, and brings continuity to securing our software deliverables.

Continuous delivery pipelines are implementations of the continuous everything paradigm and help validate every commit our teams make. Integrate automated security checks with the pipeline to give you early warnings, and monitor escaped security vulnerabilities relentlessly. Integrated continuous security approaches scale as your business expands.

Both unit tests and static code analysis operate closest to source code, and run checks without executing the code. Remember, the cost of a defect is low in test, medium in staging, and high in production. So, invest in security unit tests and static analyzers, since these are inexpensive and fast, and can save trouble further down the pipeline.

Implementing continuous security: unit tests

Sua primeira implementação de segurança contínua deve ser em testes de unidade de segurança.

In continuous delivery pipeline 101, we defined components as the smallest distributable and testable units. They can be validated by unit tests. Security unit tests are just as important as the other unit tests we write, but some teams still manage to overlook this category completely.

SAST

Alongside detecting violations in coding best practices, static code analyzers detect security vulnerabilities in code that you own and in (possibly insecure) libraries that you import. This is called SAST (static analysis security testing) and modern tools integrate well with the continuous delivery pipeline. Make sure you choose a SAST scanner that’s compatible with the programming language of your choice.

A word of caution: SAST can often report false positives and hence plan for a layer of persistence that helps pipelines “remember”. False positives can annoy the team to the point where they stop responding to broken pipeline notifications, and that’s dangerous. Once teams have identified an error as a false positive with proper justification, don’t let the pipeline flag it again and again. This can lead to teams disabling SAST or letting pipelines ignore SAST errors altogether.

DAST

Componentes fracamente acoplados compõem um subsistema. Subsistemas podem ser implementados e testados quanto a vulnerabilidades de segurança usando DAST (teste de segurança de análise dinâmica). Diferentemente de SAST, DAST examina um aplicativo de fora em seu estado de execução, de modo muito semelhante ao que um invasor faria. Scanners de DAST podem não ter uma dependência de linguagens específicas, uma vez que interagem com o aplicativo de fora.

The important thing is to include both SAST and DAST in your security strategy since each brings its unique benefits to the table. Integrate both approaches with the CD pipeline so that you get early feedback.

DevSecOps Is the Future of Security

In today’s world, just like quality, security is everyone’s job. Don’t let your vision be limited by a silo of self-proclaimed experts. Reactive corporations and executives that once did so face dire consequences, and are now revitalizing their security strategy with fresh budget.

Traditional security professionals operate in a silo whose capacity is limited by the number of security personnel inside that silo. Instead, embrace the agile, decentralized approach of DevSecOps, and retrain your teams to control their own destiny. Additionally, make your product development teams accountable, so that there is no mudslinging between them and the InfoSec department.

With the DevSecOps community thriving, security is not just a business priority, it is also the latest and greatest thing to integrate with the continuous delivery pipeline! Continuity, armed with security, ensures that the best days of software delivery are ahead of us.