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?

DevSecOps は、セキュリティに焦点を当てて継続的デリバリーのソフトウェア開発ライフサイクル (SDLC) を説明する用語です。DevSecOps は、一般的な DevOps の知識とベストプラクティスに基づいて構築されています。ソフトウェアセキュリティに DevOps の価値を適用することで、セキュリティ検証が開発プロセスの有効な一部分として統合されます。従来は (残念なことに)、セキュリティはセカンダリシステムとして扱われてきました。通常、情報セキュリティチームは SDLC の最終段階に近づいた頃に開発チームと関わります。彼らの志が崇高な分、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.

DevSecOps の原則は共同作業を促進し、セキュリティ専門家へのハンドオフの遅延を防ぐことです。前後のサイクルタイムの違いを見ればその価値は明らかです。DevSecOps の導入以前は、最後の最後に製品が安全ではないと見なされ、コストが倍増するイテレーションを引き起こすことがありました。DevSecOps の導入後は、製品にセキュリティのゴールドスタンダードが組み込まれます。最後の最後で予期しない問題が発生する可能性はありますが、その確率は非常に低くなるでしょう。

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

セキュリティの脆弱性は、記述されたコードの中だけでなく、インポートする OSS (オープンソースソフトウェア) ライブラリにも存在する場合があります。大勢の開発者が毎日プログラミングを行っても手動のコードレビューは成長しません。ここで 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

継続的なセキュリティの最初の実装は、単体テストのセキュリティに行う必要があります。

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

ゆるく結合したコンポーネントがサブシステムを形成します。サブシステムは DAST (動的解析セキュリティテスト) を使用してデプロイされ、セキュリティの脆弱性がテストされます。SAST とは異なり、DAST は攻撃者の手法と同様に、実行状態にあるアプリケーションを外側から観察します。DAST スキャナーは外側からアプリケーションとやり取りするため、特定の言語に依存しません。

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.