Develop fast. Stay secure. HashiTalks 2022 Sr. Solution Engineer 伊藤仁智（Masa Ito） 

Masa Ito Sr. Soluiton Engineer @unagi_ga_suki ● 2022年5月〜 Snyk ● それ以前はHashiCorpにおりました ● DevOps, DevSecOps, AppSec, DevSec, etc 

アジェンダ Snykについて簡単にご紹介 Terraform providerによるSnyk設定 DevSecOpsを支えるシフトレフトソリューション Snyk IaCで何を解析できるのか？ Terraform cloud run tasks Integration Custom RuleによるPolicy as Code ドリフト検知 Snyk 製品デモ Snyk Cloud - New CSPM solution 

アジェンダ Snykについて簡単にご紹介 Terraform providerによるSnyk設定 DevSecOpsを支えるシフトレフトソリューション Snyk IaCで何を解析できるのか？ Terraform cloud run tasks Integration Custom RuleによるPolicy as Code ドリフト検知 Snyk 製品デモ Snyk Cloud - New CSPM solution 

Snyk は 迅速な開発とセキュリティの両立を支援 顧客数 1800+ 従業員数 1450+ テスト回数 (四半期) 332M+ (3.7M/day) 資金調達総額 $850M 本社 : ボストン、米国 設立 : 2015年 PROTECTED BY SNYK 

クラウドへの変化に伴い、開発者の責任範囲が拡大 Pre-cloud IT Security - Centralized Cloud AppSec - Decentralized App code Security IT Apps (Dropbox, Email) Open Source Library Network Servers, VM’s Hardware App code Open Source Library OSS Platform / Apps Cloud / SaaS Services Containers VPC, Service Mesh Kubernetes Cloud Developers IT / Operations Dev Ops Services Growing Developer Role Shrinking IT/Ops Role 分散化するセキュリティにより、 脆弱性が今まで以上にクリティカルに Security 

クラウド時代のアプリケーション リスクの潜む場所 Open Source Libraries Containers App Code IaC 脆弱性の80%は間接的な依存関係で見つかる 数百におよぶLinuxパッケージがコンテナには含まれて おり、そこから多数の脆弱性が引き継がれる クラウドでの脆弱性発生原因 第1位は設定ミス [米国 NSA] 頻繁なデプロイ - ウォーターフォールでは追いつ けない。スキャンに何時間もかけられない コードベースの 10-20% コードベースの 80-90% 

クラウド時代のアプリケーション リスクの潜む場所 Open Source Libraries Containers App Code IaC Snyk Code Snyk IaC Snyk Open Source Snyk Container 対象：プログラミング言語 C#, Go, Java, JS, Python, PHPなど 対象：パッケージマネージャ npm, nuget, maven, pipなど 対象：コンテナイメージ DockerFile, Registry (DockerHub, ECR, ACR）, K8s連携など 対象：IaC Terraform, CloudFormation, ARM, K8s manifest など 

クラウド時代のアプリケーション リスクの潜む場所 Open Source Libraries Containers App Code IaC Snyk Code Snyk IaC Snyk Open Source Snyk Container 対象：プログラミング言語 C#, Go, Java, JS, Python, PHPなど 対象：パッケージマネージャ npm, nuget, maven, pipなど 対象：コンテナイメージ DockerFile, Registry (DockerHub, ECR, ACR）, K8s連携など 対象：IaC Terraform, CloudFormation, ARM, K8s manifest など 

CI/CD (CLI, API) Git repository (SCM) Traditional/PaaS Serverless Production Snyk IaC 実行例 Registry deploy Security gate Code (CLI, IDE) Test & fix Test, fix, monitor Kubernetes Monitor & more... Test, fix, monitor コードのチェックイン・マージ： ローカル環境で IaCのMiscofigurationや ポリシー違反を検知 継続的な自動スキャン： Git RepoにあるIaCを継続的にスキャン Provisioning： CI/CDパイプラインなどで Provisioningする際に Misconfigurationやポリシー違 反を検知 新しい脆弱性の検出時には アラート発出・JIRA Issueの自動作成 

開発者 セキュリティ担 当者 DevSecOps 開発フローにセキュリティを組み込む 開発者へのエンパワメントによりセキュアなアプリ開発を実現 SAST SCA CSPM Container Scan IaC Scan Drift scan 

VS Code IntelliJ Azure Repos GitLab Bitbucket Cloud Bitbucket Server Concourse Jenkins Azure Pipelines TeamCity Cloud Foundry VMWare Tanzu Heroku Artifactory micro focus Coding Source Control CI/CD Runtime Snyk CLI AWS Code Pipeline Kubernetes Snyk API Issue Management Eclipse Docker Hub Docker & others AWS Lambda IBM Cloud Registries Slack Jira Azure Functions BitBucket Pipelines CircleCI Snyk API GitHub GitHub Enterprise npm Enterprise Private Registry PyCharm WebStorm PhpStorm GoLand RubyMine Visual Studio 2019 Docker buildah Harbor Quay Amazon ECR Azure Container Registry Google Container Registry RedHat Openshift RiskSense Kenna Security Nucleus Security Vulcan Brinqua Fortify SSC 数多くの開発ツールと連携 Terraform Cloud GitHub Actions 

Code Open Source Containers Infrastructure as Code Snyk products IaC 

Securing against industry best practices and CIS benchmarks https://snyk.io/security-rules 業界のベストプラクティスのルール セット (Terraform, Cloud Formation, ARM, K8s) CISベンチマークとSnykセキュリティ エンジニアによる脅威モデリング研究 のルールセットを拡張 Open Policy Agent (OPA) / Regoによるカスタムポリシー 

Snyk IaCは何を解析するのか？ 解析対象　→　.tfコンフィグもしくは.tfplan ● .tfコンフィグ (Terraform file) ○ HCL2で記述されたIaC ○ Snyk IaCはデフォルトでは実行ディレクトリ以下にある全ての .tfコンフィグを解析 ○ Moduleも含めて解析する場合は予め terraform initを実行して対象のModuleのコンフィ グをダウンロードしておく ○ 環境変数や -var で指定される変数を補間した解析は出来ない ● .tfplan ○ Terraform planのアウトプットを解析 ○ Moduleも含め全ての情報が入っている ○ 変数の補間もすでにされている ○ もっとも精度の高い解析が可能 terraform plan -out=tf.tfplan terraform show -json tf.tfplan > tfplan.json snyk iac test tfplan.json 

Terraform run tasks integration Terraform run tasksとは？ ● https://www.terraform.io/cloud-docs/workspaces/settings/run-tasks ● Terraform cloudのRun実行中に3rd partyツールのサービスなどを呼び出す仕組み Snyk integrationとは？ ● Terraform planが成功した後、RunTaskによりSnykの解析が走る ● Tfplanに対して解析するので精度の高い解析が可能 ● Snyk解析結果に応じてTerraform Runの制御が可能 PLAN POLICY COST RUN TASK APPLY Terraform Run 

Terraform run tasks integration Terraform cloud Snyk App 

IaC Custom rules ★ Business/Enterprise機能 Snyk IaCに独自のカスタムルールを追加し、 包括的なセキュリティフィードバックを一箇所で提供 

Usecases ○ Snykはデフォルトのルールセットだけでも数百を超える設定ミスやセキュリティルールを解析し ます ■ https://snyk.io/security-rules/ ○ ただ、上記以外の会社独自のルールであったり、非機能要件などのチェックをすることで更なる コンプライアンスの強化をしたいケースもあります。 ■ 間違ったRegionにデプロイしようとしていないか？ ■ 環境に応じたインスタンスやスペックが守られているか？ ■ かならず規定の時間内にデプロイが実行されているか？ ■ 特定のTagがきちんと付いているか？（”Owner”, “TTL”, “Billing” など） ■ 会社規定のコンテナレジストリのものを使っているか？ ■ などなど ○ バラバラでチェックするのではなく、一つの場所で全て解析したい ○ こういった期待に沿うのが SnykのCustom Ruleになります 

SDKのインストール SDKのインストール ● Npm、prebuild, Dockerイメージなどもあります SDKはルール作成に必要なステップ全てをサポートします brew tap snyk/tap && brew install snyk-iac-rules Local環境でRule の作成＆Test Container registryへ Pushし、Snyk platform 全体へ適用 

Parsing resource "aws_redshift_cluster" "example" { cluster_identifier = "tf-redshift-cluster" database_name = "mydb" node_type = "dc1.large" cluster_type = "single-node" } example.tf apiVersion: v1 kind: Pod metadata: name: example spec: containers: - name: example image: example:latest securityContext: privileged: true } example.yml { "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "example" }, "spec": { "containers": [{ "image": "example:latest", "name": "example", "securityContext": { "privileged": true } }] } } output { 　　"resource": { 　　　　"aws_redshift_cluster": { "example": { 　　"cluster_identifier": "tf-redshift-cluster", 　　"cluster_type": "single-node", 　　"database_name": "mydb", 　　node_type": "dc1.large" } 　　　　} 　　} } output 

Parsing resource "aws_redshift_cluster" "example" { cluster_identifier = "tf-redshift-cluster" database_name = "mydb" node_type = "dc1.large" cluster_type = "single-node" } example.tf apiVersion: v1 kind: Pod metadata: name: example spec: containers: - name: example image: example:latest securityContext: privileged: true } example.yml { "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "example" }, "spec": { "containers": [{ "image": "example:latest", "name": "example", "securityContext": { "privileged": true } }] } } output { 　　"resource": { 　　　　"aws_redshift_cluster": { "example": { 　　"cluster_identifier": "tf-redshift-cluster", 　　"cluster_type": "single-node", 　　"database_name": "mydb", 　　node_type": "dc1.large" } 　　　　} 　　} } output RegoにおけるNotation input.resource.aws_redshift_cluster.example.node_type RegoにおけるNotation input.spec.containers[0].securityContext.privileged 

Ruleの作成 ● RuleはRego（ “ray-go”と発音）で記述します ○ https://www.openpolicyagent.org/docs/latest/policy-language/ package rules deny[msg] { resource := input.resource.aws_redshift_cluster[name] not resource.tags.owner msg := { "publicId": "my_rule", "title": "Missing an owner from tag", "severity": "medium", "msg": sprintf("input.resource.aws_redshift_cluster[%s].tags", [name]), "issue": "", "impact": "", "remediation": "", "references": [], } } example.rego Rule条件を記述 この例では： 「ownerというTagがついているかどうか？」 Ruleに当てはまった場合の挙動 deny | allow 検知した場合に Snyk IaCで扱う際の Attributes name変数にRuleに当てはまった Resource名 が返る 

Custom ruleを適用してみる ● Custom ruleのBundle作成 ● Custom rule実行に必要なものが全て Bundleされたbundle.tar.gz が作成される ● Custom ruleで解析してみる snyk-iac-rules build snyk iac test --rules=bundle.tar.gz 

Terraform Drift detection Managedリソースのドリフト検知と Unmanagedリソースの状態を把握 

Managed (ドリフト)検知とUnmanaged検知 Managed (ドリフト)検知 ● Stateファイルと実際のインフラのドリフトを検知・報告 Unmanaged検知 ● Terraformで定義されていない（ Stateファイルに存在しない）リソースを検知・報告 Terraform Cloudで管理しているリソースのドリフト検知 snyk iac describe --drift snyk iac describe --only-unmanaged snyk iac describe --drift \ --from="tfstate+tfcloud://ws-bS3c8FFMf2KkFmwe" \ --tfc-token="=GUYddVLQ.atlasv1.D5K・・・" \ --tfc-endpoint="https://app.terraform.io/api/v2" 

Cloud infra Resource B Resource A Resource C Resource D Resource E Managed (ドリフト)検知 1 State file Cloud infra Resource B’ Resource A Resource C Resource D Resource E 2 State file modify Cloud infra Resource B’ Resource A Resource C Resource D Resource E delete 3 State file Resource Bに変更がありますよ Resource Dが無いですよ Cloud infra Resource B Resource A Resource C Resource D Resource E 4 State file Stateとインフラが Sync Stateとインフラが Out-of-Sync ドリフト検知により差分を検出 アラートをあげる ドリフト内容に合わせて適切なアク ションを行う ・Stateのアップデート ・Terraform Apply ・要らないものは Configから削除 ・など 復旧 ● Consoleからの手作業での変更 ● CfnやARMなど別のIaCによる変更 ● CLIによる変更 ● Lambdaなどによる動的な変更 ● Ansibleなどからの変更 ● などなど 

UnManaged検知 Cloud infra Resource B Resource A Resource C Resource D Resource E State file 1 既存のインフラ Terraform以外で作成された リソース など Unmanagedの検知をもとに： ● 不要なリソースの判別 ● IaCでManageするように修正 ● TerraformにImport ● など Resource G Resource F Resource H Resource I Resource J Resource L Resource K Resource M Resource N Resource O Resource Q Resource P Resource R Resource S Resource T State file 2 State file 3 Managed Managed Manageだが ドリフト発生 Unmanaged Resource P~TはUnmanageですよ 全体の75％はTerraformでManageされてますよ。 100%を目指しましょう！ 15個がManagedで5個がUnmanagedですよ 1つのResourceにドリフトが発生してますよ 

Managed (ドリフト)検知とUnmanaged検知 Managed (ドリフト)検知 Unmanaged検知 

Terraformのドリフト検知との（大雑把な）違い Terraform Cloud Snyk Managedリソースのドリフト ほぼ同じ機能を提供 State fileへの修正 󰢏 Refresh相当 Importの実施 🙅 State fileの管理 󰢏 Workspaceで安全に管理 🙅 State fileの指定が必要 たくさんのStateに分割されている場合は結構 大変かも・・・ 必要なCredential権限 Terraform実行時の権限が必要 （将来的には対応されそう） Least Privileged Read-onlyのクレデンシャルでOK Terraform管理外のリソース検知 （Unmanaged） 🙅 Data source使えばリストアップは可能 󰢏 アカウントに存在するリソースのリストアップ （例：既存のリソース） 全体に占める割合の表示 実行タイミング Daily いつでも 

Value Proposition ● コスト削減 ○ すべてのルールを手作業でチェックする時間を省くことができます。 ● リスクの低減 ○ プロビジョニングごとに分析を実施することで、リスクを低減します。 ● 生産性の向上 ○ 開発者は、インフラストラクチャへの変更をより自信を持って適用することができます。 Happy snyking! 

● Developer First- bring production insights left to improve the developer experience with ○ Security issue context ○ Actionable fix advice ● Holistic application view - enable developers to take ownership of their application security from writing IaC files in their IDE to the real-time state of the cloud ● Faster remediation - close the feedback loop between cloud and production security insights and developer workflows ● Reduce the most risk- prioritize issues based on risk, not just finding the most amount of issues Snyk IaC + Cloud Code to cloud, and back to code Coming soon! 

お問合せやセミナーの案内はこちら https://snyk.io/jp 無料トライアルもあります 

絶賛人採用中 特にSolution Engineer募集中！ https://snyk.io/jobs/solutions-engineer-12/ ありがとうございました！