Slide 1

Slide 1 text

開発生産性と Security Shift Left @uncle__ko

Slide 2

Slide 2 text

Self-introduction Developer Productivity室所属 Backend Engineerとしての経歴が長い AdTechからFinTechまでいろいろな分野の開発に従事 現在は生成AI x Developer Productivity分野で何かできなかを考えてる プライベートでは1児の父 X: @uncle__ko GitHub: @ouchi2501

Slide 3

Slide 3 text

DORAの定義するCapabilitiesにおけるSecurity Fourkeysなどを提唱しているDORA(DevOps Research and Assessment)が、組織がソフトウェアの 提供と組織のパフォーマンスの向上を促進するために もつべきものを定義していたりします https://dora.dev/capabilities/ このCapabilitiesの中にPervasive securityという項目 が定義されており、DORAもセキュリティについては重 要視していることがわかります。 https://dora.dev/capabilities/pervasive-security/

Slide 4

Slide 4 text

DX CriteriaにおけるSecurity DX Criteriaとは、日本CTO協会が策定している 2つのDX(Degital TransformationとDeveloper eXperience)を企業が推進するための評価基準 です。 よく作り込まれていて、DORAのCapabilitiesと 似たような内容も含まれていたりします。 この中でも、セキュリティシフトレフトの大切さが 書かれていたりします。 https://dxcriteria.cto-a.org/b28408f9d5bd4c32 94d7aa048e0ffdc2

Slide 5

Slide 5 text

Shift Left DORA、DX Criteriaのどちらでも重要なのはSecurityのShift Leftだと記載されています。 このご時世、サービスを作ったあとにセキュリティ対策をしないということはないと思います。年々サイバー 攻撃の件数も増加傾向にあるため、セキュリティ対策は必須としても、いままでのようにシステム開発を終 えてから脆弱性検査を行い、弱い部分が発見されたら修正手当てをしていくと、かなり非効率な部分もあ り手戻りが多くなってしまいます。 また、DevOpsの考え方も普及してきたことを考えると、デプロイサイクルが早まっているため、いままでの やり方では現状の開発手法に合わなくなってきているように思います。 ではShift Leftとはなにかというと、開発ライフサイクルの初期段階から脆弱性や課題を見つけることで、 従来のソフトウェアが完成したあとにセキュリティ課題を見つけたときの手戻りや修正コストを下げようとす る試みのことです。

Slide 6

Slide 6 text

Shift Left

Slide 7

Slide 7 text

DevSecOps このShift Leftは、DevSecOpsなどとも言われたりします。 既存のDevOpsのサイクルの中にセキュリティ対策も含めて、文字通りセキュリティチェックを Shift Leftし ていきます。 セキュリティのShift Leftに関する取り組みは下記と言われています。 - 専任のセキュリティチームによる最新動向等に基づくレビュー - 定期的な脆弱性診断の実施 - ソースコードの自動的セキュリティチェック(静的解析・動的解析) - 自動テストの中で脆弱性検査機能を含むものの適用 - 開発企画段階におけるセキュリティレビューの実施 セキュリティのShift Leftを実施していくにあたり、実際にどのような対策をしていくのがいいのかを記載し ていきます。

Slide 8

Slide 8 text

Secret Scanning パスワード、APIキー、暗号キー、アクセストークン、認証や認可に使用されるさまざまな タイプのクレデンシャル情報をGitにPushすることを防ぐためのツールです。

Slide 9

Slide 9 text

代表的なSecret Scanningツール - GitLeaks - https://gitleaks.io/index.html - GitHub Secret Scanning - https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning - Trivy - https://aquasecurity.github.io/trivy/v0.27.1/docs/secret/scanning/

Slide 10

Slide 10 text

SCA(Software Composition Analysis) ソフトウェア構成分析です。 アプリケーションのコードベース(コンテナやレジストリなどの関連するアーティファクトを 含む)を自動スキャンし、すべてのオープンソース・コンポーネントとそのライセンスおよ びセキュリティ脆弱性を特定します。

Slide 11

Slide 11 text

代表的なSCAツール - Trivy - https://trivy.dev/ - Dependabot - https://docs.github.com/ja/code-security/dependabot/working-with-dependabot - Snyk Open Source - https://snyk.io/jp/product/open-source-security-management/

Slide 12

Slide 12 text

SAST(Static Application Security Testing) SASTは脆弱性の静的解析です。 コードを静的/非実行の状態でスキャンして、セキュリティ脆弱性になるかもしれない欠 陥を検出することを目的とした脆弱性診断です。 コードの状態でスキャンするので、デプロイ前に検知して修正することが可能です。 なので、IDEのプラグインなどでcommit前のコードに対して検知もできますし、Pull Request作成時のJobとしてマージ前に検知したりも出来るかと思います。

Slide 13

Slide 13 text

代表的なSASTツール - GitHub Advanced Security - https://docs.github.com/ja/get-started/learning-about-github/about-github-advanced-security - Semgrep - https://semgrep.dev/products/semgrep-code - Snyk Code - https://snyk.io/jp/product/snyk-code/ - Trivy - https://trivy.dev/

Slide 14

Slide 14 text

DAST(Dynamic Application Security Testing) SASTは静的なコード解析でしたが、DASTは動的なので、実際に稼働しているアプリケーション に対して、悪意のある攻撃者の視点を踏まえて疑似的な攻撃(検査)リクエストを送信し、アプリ ケーションの挙動の変化から脆弱性があるかどうかを判定します。 DASTはSASTと違いブラックボックステストで実施します。攻撃者はコードの内部機能を知らな いという前提です。 プログラムの実行中にのみ現れるセキュリティ脆弱性など、 SAST では検出 不可能な脆弱性を発見します。 ただし、SASTやSCAほど簡単にCI/CDパイプラインに組み込めるわけではありません。 動いているアプリケーションに対してシナリオを実行するので、導入難易度は高めと言わざるえ ません。

Slide 15

Slide 15 text

代表的なDASTツール - Securify - https://www.securify.jp/ - GMOサイバーセキュリティ byイエラエ - https://gmo-cybersecurity.com/

Slide 16

Slide 16 text

さいごに セキュリティのShift Left/DevSecOpsの重要性や代表的な対策やツール群を紹介しま した。 最近はサイバー攻撃によるニュースを多く聞くようになってきました。他人事だと思わず に、自分たちのシステムもいつ標的にされてもおかしくないと考えたほうがよい世の中だ と思います。 セキュリティのShift Leftを積極的に行い、開発生産性も高めつつ、アプリケーションのセ キュリティも高めて、安心安全なアプリケーションをつくってほしいな思ったりしています。