セキュリティのシフトレフトはコード化とlaCによって前進する
ソフトウェアテストに関するバグ修正の相対的コストは、開発フェーズが後工程になればなるほど指数関数的に増えていく。逆に言えば、早いタイミングで修正しておけば、簡単に修正することができる。それを示したのが、以下の図である。
設計時の修正コストを1とすると、コーディングのタイミングではそれが5倍になる。統合テストのタイミングでは10倍。受け入れテストになると15倍、リリース後だと30倍になるというわけだ。
セキュリティや脆弱性に関しても、同様の傾向があると相澤氏は指摘する。
「セキュリティのシフトレフト、つまり早いタイミングに開発の上流側でテストを行い、脆弱性対策をとることでコストが削減できる。さらに、生産性向上や迅速な開発が実現できるのです」（相澤氏）
セキュリティのシフトレフトは、本番もしくはクラウドランタイムで行ってきた作業を上流側で行う。つまり、CI/CDでスキャンを行うキットと連携し、コーディングのタイミングで実行すればコストが下がり、効率的になるというのだ。
「シフトレフトを行う場合、脆弱性をスキャンして修正するのは開発者です。そこでこのプロセスを、SnykではDeveloper Securityという言葉で提唱しています」（相澤氏）
ここで相澤氏は視聴者に向けて、2つの質問を投げかける。
- laC（Infrastructure as Code）はセキュリティツールか？
- laCツールを導入すれば、シフトレフトは実現できるか？
これには正解があるわけではなく、あくまでも認識であると前置きしながら、相澤氏の回答は以下である。
1の回答：セキュリティツールと言ってよい
laCとは、これまでGUIやCLIで設定していたものをコード化することであり、laCのソースファイルは一般的にテンプレートと呼ばれている。つまり、「再現性を高める」「ミスを減らす」効果を求めて使っている人が多く、コードで管理していれば、問題が発生したときも後で確認することができる。セキュリティを高めるという意味では、laCはセキュリティツールと言えるのではないだろうか。
2の回答：実現するわけではない
laCは、シフトレフトを実現するための必要条件。セキュリティのシフトレフトをする上では、まずコード化されていなければコード化する必要がある。つまり、コード化することによって、本番に適用する前にスキャンすることができるというわけだ。
では、脆弱性スキャナーにはどのようなものがあるのか。相澤氏はクラウド時代のアプリケーションに潜むリスクを、氷山に例えて説明した。
まず、表層となる一番上のアプリケーションのコード、2番目が上のカスタムコードから呼び出されるオープンソースのライブラリ。そしてモダンなアプリケーションの場合、これらはコンテナとしてパッケージ化されるコードが3番目。それらをクラウドにデプロイするときにインフラとなるInfrastructure as Code（laC）が4番目となる。
これらのコードベースにはすべて脆弱性が混入されるリスクがあり、スキャンする対象となる。さらに、オープンソースで提供、または無償で使えるツールも紹介された。
例えば、アプリケーションのカスタムコードでは、Snyk Code、GitHub CodeQL、SonarQubeなど。オープンソースのライブラリであれば、Snyk Open Source、OWASP Dependency-Check、GitHub Dependabot。コンテナはSnyk Container、Aqua Trivy、AWS ECR Basic Scanning。laCについては、Snyk Infrastructure as Code、Bridgecrew checkov、Aqua Trivyなどである。
「シフトレフトはTest early, test often。スピードに加え、頻繁に行うということを考えると、自動化するツールを導入することは非常に大事です」（相澤氏）
