😽

Security for Developersと言うAWSのワークショップに参加したメモ。

2023/02/14に公開

晴れた日曜の午後、リモート開催の勉強会に参加した際の備忘録。
https://s-jaws.doorkeeper.jp/events/149297

当日は配信をながら聞きさせてもらい、ワークショップ自体は下記ページを見つつ後日に自分1人で実施した。
https://catalog.workshops.aws/sec4devs/ja-JP

ワークショップ前提

  • 開発パイプライン(CI/CD)のセキュリティをどのようにシフトレフトするか、と言う実装ベースの話題が焦点なので実際に使うAWSサービスの説明はない(少しだけ補足はある)
  • CDKを使って構築&デプロイを繰り返すため、CDKの基礎は分かっているとなお勉強になる
  • 作業環境はCloud9前提になっているものの、サンプルアプリの言語はPython + venvなのでそれに対応した開発環境+AWSプロファイルがあればローカル環境でも可能
    • 自分の場合、pipenv + AWS SSOのローカル開発環境を使って作業した
  • 構築スタックにはCode**系以外にもNAT Gateway, ECS, EC2など色々含むため、起動しっぱなしで数日に分けて実施するとぼちぼち課金される...
    • 自分の場合、平日(の夜)2日に分けて実施したので1日あたり$3~$4の費用が発生した

個人的なワークショップのまなび

SAST, SCA, DASTといった全く頭に入らない略称が意味するセキュリティテストのアプローチを知った。システム構成やNWのセキュリティではなくアプリケーションのセキュリティなので、実際のアプローチは実装言語に依存するけれど、CI/CD(開発パイプライン)に欲しいステップは変わらないかもしれない。

ref: SASTとSCA:両方が必用な理由
https://www.synopsys.com/blogs/software-security/ja-jp/why-use-sast-and-sca/

ワークショップで使うSAST, SCA, DAST

Broken Authentication and Session Management

認証機能はフレームワーク(またはIDaaS)を積極的を使った方が良いなー、と再認識させられた。肝心なことを理解していないとフレームワーク使っても脆弱性は発生するが、フレームワークの使い方が悪いケースであればZAPで検知できる可能性は高い。

参考: Broken user authentication| APIs and the OWASP Top 10 guide
https://support.f5.com/csp/article/K35215914

Discussion

ログインするとコメントできます