Datadogの調査レポートから見る、DevSecOpsの適用に向けた実態

何千ものコンテナイメージを分析した結果、コンテナイメージが小さいほど脆弱性が少ないことがわかり、含まれているサードパーティのライブラリが少ないためと考えられるという。

平均して、100MB未満のコンテナイメージには4.4個の高度な脆弱性またはクリティカルな脆弱性があり、250MBから500MBのイメージには42.2個、それより大きいイメージには約80個の脆弱性がある。コンテナ化された環境において軽量なイメージを使用することが、攻撃対象領域を最小限に抑えるための重要な手法であることを示しているとのことだ。

5つ目はIaCの採用について。1990年代にCFEngine、Puppet、Chefなどのプロジェクトで導入されたIaCは、クラウド環境をプロビジョニングするための標準として急速に広まっている。

AWS(Amazon Web Services)は、Terraform、CloudFormation、Pulumiなど、少なくとも1つの一般的なIaC技術を通じて、71%以上の組織がIaCを使用しているが、Google Cloudでは 55%と低くなっており、Azureに関してはアクティビティログがHTTPユーザーエージェントを記録しない。

AWSとGoogle Cloud全体では、Terraformが最も人気のあるテクノロジーで、クラウド固有のIaCツールであるCloudFormationやGoogle Deployment Managerよりも一般的となっている。
DevSecOpsを適用していくには？

6つ目はクラウドデプロイにまつわるものだ。クラウドの本番環境では、通常はCI/CDパイプラインがインフラストラクチャとアプリケーションへの変更をデプロイする責任を持ち、パイプラインで行われる自動化はIaCツールやクラウドプロバイダ固有のツールを使用したスクリプトによって行われる。

自動化により、エンジニアは本番環境に常に特権アクセスする必要がなくなり、デプロイが適切に追跡され、ピアレビューされるようになるが、クラウドコンソールから手動でアクションを実行するクリック運用(ClickOps)は、AWSの少なくとも38%の組織がすべてのAWSアカウントでClickOpsを使用していたことを確認した。

AWS Management Consoleを介してワークロードをデプロイしたり、センシティブなアクションを手動で実行したりしたことを意味し、これには本番環境での操作も含まれる。