社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
GitHub に漏れ出た内部コードを探す ~ 上場企業 3900社編 ~ - ぶるーたるごぶりん
全１回、このシリーズは今回で最後です！ TL;DR 上場企業 3900 社程に対して、すごく大雑把な「内部コード等の漏洩調査」を GitHub 上で行った 結果としては、重要度の高いものから低いものまで 10社ほどで漏洩が確認された 重要度の高いものとして、社外秘っぽそうなスプレッドシート、社員のハッシュ化パスワード(BCrypt)、 AWS Credential 等 「大雑把な」調査を行ったが、より精度の高い方法等について記事内にて触れていく 脅威インテルとか DLP みたいなエリアとかも、外部企業とかに頼るだけじゃなく「自分たちでも」頑張ってみるのがいいんだと思います GitHub Code Search ... すげえぜ！ Google Dorks ならぬ、 GitHub Dorks + GitHub Code Search でまだまだいろいろできるはず。 はじめに チャオ！ 今回は
GitHub、無料のパブリックリポジトリユーザーにも、コード内のシークレットを検知してくれる「Secret scanning」を無料提供へ
GitHub、無料のパブリックリポジトリユーザーにも、コード内のシークレットを検知してくれる「Secret scanning」を無料提供へ あるアプリケーションからデータベースやWebサービスのAPIなどにアクセスする場合、正規のアクセスであることを証明するなどの目的でIDとパスワードのセットやアクセストークンなどを必要とすることはよくあります。 こうした、いわゆるシークレットなどと呼ばれる重要な情報はコードに書くべきではありませんが、それでもしばしばパブリックリポジトリのコード中に誤って書き込まれ、公開されてしまうという事故が絶えません。 GitHubはこれまで、コード中のシークレットを検知してくれる「Secret scanning」機能を有償のユーザーに対して提供してきていました。 参考：GitHub、コード中に書いてはいけないアクセストークンを発見、通知してくれる「Secret sc
ファイルのアタッチ - GitHub Docs
さまざまな種類のファイルを issue や pull request に添付することで、情報を伝達できます。 Note: For public repositories, uploaded files can be accessed without authentication. In the case of private and internal repositories, only people with access to the repository can view the uploaded files. To attach a file to an issue or pull request conversation, drag and drop it into the comment box. Alternatively, you can click in the form
Github プルリクの添付画像はprivateでも認証なしで誰でも参照可能です
以前の現場でタイトルの事象があった。 プルリク（プルリクエスト）に修正前後の添付画像を貼ってたんだが、プライベートリポジトリでもURLを知ってれば誰でも参照可能。 ちょっと、ビックリしますよね！！ 違う現場で、プルリクに画像貼ってて、この事象を共有したのでブログにも書く。 （忘れないために） Githubのドキュメントにも書いてある ちゃんとGithubのドキュメントにも書いてあった。 しかもWarningで。 Attaching files – GitHub Docs Warning: If you add an image or video to a pull request or issue comment, anyone can view the anonymized URL without authentication, even if the pull request is i
GitHubのIssueやPull requestsにアップロードした画像の削除 - coincheck tech blog
はじめに サイバーセキュリティ推進部の吉田です。普段は、CSIRTメンバーとしてAWS環境や各種端末のモニタリング、セキュリティインシデント対応、社内からのサイバーセキュリティに関する相談対応などの業務を行っています。 2023/05/10 追記 GitHubのアップデートによって、プライベートリポジトリのIssueやPull Requestsに新たにアップロードされたファイルは、権限を持たない外部からは参照できなくなったようです。詳細につきましては、以下のGitHubのブログをご確認ください。 https://github.blog/changelog/2023-05-09-more-secure-private-attachments/ 概要 GitHubのIssueやPull requestsに添付した画像はWebにアップロードされ、パブリックなURLが割り当てられます。このURLは
GitHub の OAuth 実装の仕様違反とセキュリティ上の考慮事項 - Qiita
本稿は GitHub Docs の "Authorizing OAuth Apps" ページに書かれている情報に基づいています。英語版はこちら → "Spec Violations in GitHub OAuth Implementation and Security Considerations" 仕様違反箇所 認可リクエストの response_type リクエストパラメーターがない。当パラメーターは必須である。RFC 6749 (The OAuth 2.0 Authorization Framework) Section 4.1.1 (Authorization Request) 参照。 トークンレスポンスのデフォルトフォーマットが application/x-www-form-urlencoded のようである。フォーマットは常に application/json でなければならな
HerokuのOAuthトークン流出で、やっておくといいことリスト（コメント大歓迎）
2022年4月16日(日本時間)にアナウンスがあった、Heroku/Travis-CIのOAuthトークンの流出および悪用を受けて、ユーザーとしてやっておくといいことをまとめました。 GitHubのOrganizationのオーナー向けと個人向けで分けてあります。 追記: 複数の補足のコメントを頂き、記事にも取り込んでいます。ありがとうございます！ 注意 執筆者はGitHub, Heroku, Travis-CIの専門家ではありません。この記事は誤っている可能性があります。 この記事は現在調査中の問題について書かれています。最新情報は必ず公式サイトをご確認ください。 GitHub Heroku Travis CI インシデントの概要 GitHubがHerokuとTravis-CIのOAuthアプリケーションに発行したトークンが流出・悪用したことで、それらの連携が有効だった多くのOrgani
Public な Git リポジトリでシークレット管理をしつつ GitHub Actions で CI/CD も回す
つくったアプリケーションのソースコードは公開したい、でもシークレットはどうにかして秘匿しないといけない。継続的な運用を目指すならシークレットのデータ自体もなんとかしてリポジトリに（Repository secrets などではなくコミット対象として）含める必要がある。 …という状況を解決するために、gpg だけを使って継続的な運用を図る手段をまとめてみます。フロントエンド/バックエンドなど問わずどこでも使用できます。 Web フロントエンドなどから各種 API キーを利用する場合、リクエスト時の挙動はデベロッパーツールで全て確認できてしまう点には留意してください。 これらは API サーバー側でオリジンの制限をかけるなどの検討が必要です。 やること主な作業内容の要約は gpg を使ってプッシュする前にローカル側で暗号化をする暗号化するときに復号化のための(最強の)パスフレーズを登録するその
GitHub上のsensitive dataを削除するための手順と道のり | メルカリエンジニアリング
Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報（sensitive data）について調査を実施し、対応
LINE Pay、約13万人の決済情報が「GitHub」で公開状態に グループ会社従業員が無断アップロード
LINE Payは12月6日、13万3484アカウントの一部決済情報がソースコード共有サイト「GitHub」上で閲覧できる状態になっていたと発表した。すでに情報は削除しており、該当ユーザーへ個別に案内。現時点ではユーザーへの影響は確認されていないという。 国内ユーザーで5万1543アカウント、海外を含めると13万3484アカウントが対象。閲覧できた情報は、LINE内でユーザーを識別するための識別子（LINE IDとは異なる）、システム内で加盟店を識別する加盟店管理番号、キャンペーン情報の3点。氏名、住所、電話番号、メールアドレス、クレジットカード番号、銀行口座番号などは含まれていない。 決済情報の該当期間は、2020年12月26日から21年4月2日まで。情報が閲覧できる状態だったのは、21年9月12日午後3時13分頃から11月24日午後6時45分まで。期間中、外部からのアクセスは11件確認
githubに間違って機密データを上げてしまった時の対処 - Qiita
GitHubにAPIのキーが書かれたファイルを上げてしまったので、対処の流れを書き残しておきます。 BFGを使用する方法とfilter-branchを使用する方法があるのですが、今回は後者をやってみました。 注意 外部にキーやパスワードなどを公開してしまった事に気づいたら、まずは対象のサービスを停止させて再発行を行ってください。その後、履歴を確認し悪用された形跡が残っていないか確認してから以下の手続きを行ってください。 対処するときプルリクがあるかどうかを確認して、ある場合にはすべてマージもしくはクローズしてから行うのを推奨しています。 自分のケースでは幸い1件もなかったので、そのまま行っています。 手順 1. ローカルにリポジトリをクローンする
ソースコードの安全性を維持する新機能をリリース
私たちはお互いに深くつながり合ったコミュニティの一員であり、私たちが開発するソフトウェアは他のメンバーの作業に基づいて開発されています。新規のソフトウェアプロジェクトの99%にオープンソースコードが使用されており、膨大な量のコードの再利用によって、かつて無いほどスピーディーにソフトウェアを開発できるようになっています。一方で、このような依存関係があるため、脆弱なソフトウェアが配布されてしまうと、私たち全員がリスクにさらされます。すべての開発者が、セキュリティに配慮する開発者になるという重要性が、これまで以上に高まっています。すなわち、誰もが脆弱性情報を開示し、パッチ処理を迅速に行う責任を負っています。 GitHubは、開発者が容易にソースコードの安全性を向上できるを新たなセキュリティ機能を発表しました。 WhiteSourceのデータによるセキュリティ脆弱性アラート：GitHubは2017
Googleがオープンソース脆弱性のデータベースをPythonやGoにまで拡大
オープンソースプロジェクトにまつわる脆弱性の問題を解決するため、Googleは脆弱性データベース「Open Source Vulnerabilities(OSV)」を構築しています。2021年6月24日付けの発表で、OSVが扱うオープンソースプロジェクトの範囲がPython、Rust、Go、DWFにまで拡大することが明らかになりました。 Google Online Security Blog: Announcing a unified vulnerability schema for open source https://security.googleblog.com/2021/06/announcing-unified-vulnerability-schema.html GitHub - google/oss-fuzz: OSS-Fuzz - continuous fuzzing fo
Githubの新しいセキュリティ機能 CodeQLを使ってみる - Security Index
CodeQLは、Semmleが提供しているコードセマンティック解析に使用するツールで、脆弱性やコードの品質の可視化を行うことができます。 2019年9月18日にGithubがCodeQLを開発しているSemmleを買収し、現在「GitHub Code Scanning」(リミテッドベータ)として利用することができるようになりました。 Welcoming Semmle to GitHub - The GitHub Blog GitHub、コードの脆弱性を発見してくれる「GitHub Code Scanning」発表、修正方法のアドバイスも。GitHub Satellite 2020 － Publickey 現在でもSemmleのLGTMからCodeQLを利用することができます。 CodeQLを少し使ってみたので紹介したいと思います。 CodeQLを使ってみる Github連携 Alert :
SSH接続でGitHubにアクセスする際にセキュリティキーによる認証が利用可能に
2021年5月11日、GitHubのセキュリティエンジニアであるケビン・ジョーンズ氏が公式ブログを更新し、SSH接続の認証に物理デバイス「セキュリティキー」が利用できるようになったと発表しました。 Security keys are now supported for SSH Git operations | The GitHub Blog https://github.blog/2021-05-10-security-keys-supported-ssh-git-operations/ Googleの「Titan」やYubicoの「YubiKey」などのセキュリティキーは、外部からのアクセスから保護されている持ち運び可能な物理キーであり、コンピューターとUSBやBluetoothなどで接続して使用する、2段階認証のワンタイムパスワードなどの代替となる手段の1つです。 GitHubはこの度
About Token Scanning - User Documentation
If your project communicates with an external service, you might use a token or private key for authentication. Tokens and private keys are examples of secrets that a service provider can issue. If you check a secret into a repository, anyone who has read access to the repository can use the secret to access the external service with your privileges. We recommend that you store secrets in a dedica
GitHub、コード中に書いてはいけないアクセストークンを発見、通知してくれる「Secret scanning」機能、プライベートリポジトリで正式対応
GitHub、コード中に書いてはいけないアクセストークンを発見、通知してくれる「Secret scanning」機能、プライベートリポジトリで正式対応 GitHubは、本来ソースコード中に書くべきではないアクセストークンなどを、コードやアーカイブから発見し通知してくれるSecret scanning機能がプライベートリポジトリでも正式な機能として利用可能になったことを明らかにしました。 Check out two new ways to ship secure applications with GitHub Advanced Security! Secret scanning for private repos is now generally available, and we've released the beta of our new security overview for
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「GitHub」から非公開リポジトリなどのデータが流出 ～「npm」にも被害／「Heroku」「Travis-CI」発行のOAuthトークンが盗難・悪用される
GitHubセキュリティ Organization運用のベストプラクティス
