GitHub - betterleaks/betterleaks: A Better Secrets Scanner built for configurability and speed
Betterleaks is a tool for detecting secrets like passwords, API keys, and tokens in git repos, files, and whatever else you wanna throw at it via stdin. If you wanna learn more about how the detection engine works check out this blog: Regex is (almost) all you need. Betterleaks development is supported by Aikido Security ➜ ~/code(master) betterleaks git -v ○ ○ ● ○ Betterleaks v1.0.0 Finding: "expo
Nx の攻撃から学べること #s1ngularity | blog.jxck.io
Intro Nx リポジトリが攻撃を受け、広範囲にわたるインシデントが発生した。 今回の事例は、GitHub Actions を中心に複数のステップが組み合わさった攻撃であり、過去に何度も発生してきた攻撃と本質的には変わらない。 しかし、途中で AI が何度か登場するため「AI が書いたコードをマージしたから」などといった表面的な反応もあるが、実態はそこまで単純な話でもない。 また、「自分のプロジェクトは Nx を使っていないから関係ない」とも言えない攻撃であるため、特にフロントエンドエンジニアは全員注意と確認が必要となる。 この攻撃が何だったのか、そこから学べることは何なのか、解説する。 Nx Incident 今回のインシデントについては、既に公式の Advisory が出ている。ニュース系の記事も多々あるが、一次情報は以下となる。 Malicious versions of Nx a
GitHub Actions の定期実行ワークフローを「時間通り」に実行する
schedule イベントを用いた、GitHub Actions のワークフローの定期実行は時間通りに実行されないがちです。この問題を解決するため、ワークフローファイルにアノテーションという形で cron 式を記述すると、自動的にその cron 式が示す時間に workflow_dispatch する社内システム兼 GitHub App を作りました。cronium（/krɒnɪəm/）と呼んでいます。Chromium じゃないよ。 本稿の構成は次の通りです。まず、cronium を作るに至った背景を説明し、問題を解決するアイディアを紹介します。次に、ユーザーはどのような体験を得られるのかを示すため、cronium の使い方を簡単に説明します。そして、cronium がどのように作られているのか、どうしてそのように作ったのかを解説し、最後に今後の展望を述べて本稿を閉じます。 背景 GitH
pnpm workspace を利用したモノレポで「この PR の影響を受けるパッケージ」をフィルタする
3行まとめ pnpm の --filter オプションにはパッケージ名だけでなく git の commit や branch も渡すことができる pnpm ls --filter をうまく使えば「main branch からの diff の影響を受けるパッケージ」の一覧を取り出せる ドキュメントや help をちゃんと見ると、意外と知らないことが書いてある モチベーション LayerX のバクラク事業部では Webapp（Web Frontend アプリケーション）のモノレポ化を進めており、1つのリポジトリに複数の Next.js アプリケーションが存在します。 そこで悩ましいのが CI でのテストなどの実行です。 そのまま全件実行すると時間が長くなっていく e.g. アプリAのコードしか変更してないのに、アプリBのテストも実行されてしまうと時間もお金も無駄にかかる 何もしないとプロダクト
CodSpeedによる継続的ベンチーマーク
CodSpeedは継続的ベンチマークを行うためのサービスです。CodSpeedを使うことで、ベンチマークを自動で実施し可視化できます。CodSpeedは、ベンチマークの結果を比較できるため、コードの変更によるパフォーマンスの変化を追跡できます。 対応言語はRustとPython及びNode.jsです。この記事ではRustを使う場合を説明します。 PublicなOSSプロジェクトでは無料で使えます。Privateなリポジトリを使う場合は有料です。 CodSpeedの概略 自分のプロジェクトへの導入方法の前に、私が導入したプロジェクトで何ができるのかを説明します。これは私が練習でSATソルバーを書いているプロジェクトです。まずGitHubのリポジトリ毎にCodSpeed側にもページが作成されます。このページはログインせずに見ることができます。 Overview まずデフォルトブランチの履歴毎に
プルリクエスト時にラベルから自動でチェックリストを作成・更新するGitHub Actionを作成した
今回はPull Requestを読み取ってこんな感じのチェックリストを自動生成する kasaikou/pr-checklist-action というGitHub Actionを作成したのでその紹介をする記事です。 TL;DR プルリクエストテンプレートにチェックリストを入れがちだけど、知見が溜まっていくに従ってチェック項目が増えていくのはつらいよ そこで、設定されたラベルをもとにチェックリストを自動作成する GitHub Actions を作ったよ actions/labeler と併用することでラベル設定のめんどくささは actions/labeler が解決するから、それに相乗りするだけでいいよ 基本的にはチェックリスト用のコメントが作成されるけれど、少しテンプレートを変更することで今までのプルリクエストテンプレートっぽいチェックリストを作成することもできるよ 背景とかコンセプト 個人
GitHub Actionsの脅威検知ツール tracee-action を触ってみる
はじめに こんにちは、セキュリティエンジニアのJJ (yuasa)です。今回はGitHub Actionsのワークフローにおける脅威検知ツールであるtracee-actionを触り、検知ルールの書き方について見ていきます。なお、tracee-actionは2024年7月時点で本番環境での利用は想定されていない点にご注意ください。 This project is not production ready. We are experimenting with it to test and demostrate Tracee capabilities. tracee-action tracee-actionはTraceeを用いてGitHub Actionsのワークフローにおける脅威を検知します。TraceeはeBPFを用いてLinuxランタイム上でのシステムコールを検出することができるツールです
GitHub Actionsにおける脅威と対策まとめ
はじめに こんにちは、サイボウズ24卒の@yuasaです。 サイボウズでは開発・運用系チームに所属する予定の新卒社員が研修の一環として、2週間を1タームとして3チームの体験に行きます。新卒社員の私が生産性向上チームの体験に行った際に、チーム内でGitHub Actionsを利用する際の脅威と対策について調査を行い、ドキュメント化した上で社内への共有を行いました。本記事では、そのドキュメントの一部を公開します。 対象読者 本記事の主な対象読者としては、以下のような方を想定しています。 GitHub Actionsを組織で利用しているが、特にセキュリティ対策を実施していない方 GitHub Actionsを組織で利用しており、部分的にセキュリティ対策を実施しているが、対策が十分かどうか分からない方 本記事がGitHub Actionsのセキュリティ対策を検討する上で参考になれば幸いです。 本記
GitHub Actions に Arm64 ランナーが来たので Docker のマルチプラットフォームイメージをビルドしてみる
GitHub Actions に Arm64 ランナーが来たので Docker のマルチプラットフォームイメージをビルドしてみる 2024/06/03 に GitHub Actions に Arm64 ランナーが追加されました。 現在はパブリックベータで、Team と Enterprise Cloud プランでのみ利用可能です。料金は x64 の同性能のランナーより 37% 安く、電力効率が高いため二酸化炭素排出量削減にもつながるとのことです。 この記事では、新しく追加された Arm64 ランナーを使って Docker のマルチプラットフォームイメージをビルドしてみます。 マルチプラットフォームイメージとは？ マルチプラットフォームイメージとは、複数の異なる CPU アーキテクチャ（場合によっては異なる OS）のイメージを 1 つのイメージとして扱えるようにまとめたものです。マルチプラット
リリース時にのみ行う処理はできるかぎり減らす - プログラムモグモグ
GitHub Actionsなどでテストやリリースを自動化していると、様々なトリガーによって異なる処理を行うことはよくあることです。 例えばpushのトリガーではテストやlintを行い、tagをpushしたときはクロスビルドしてリリースする、などです。 これらの処理は内容も頻度も異なるので、ワークフローのファイルを分けることはよくあることだと思います。 私もかつてはこのようにトリガーや実行したい頻度が異なるのだから分けるのは自然なことだと考えていました。 一つのワークフローの中でトリガーによって処理を分岐させるとワークフローが複雑になるし、面倒なことが多いからです。 しかし、最近はリリース時の処理をテストと同じワークフローにまとめる方が良いと考えるようになりました。 リリースする時になって初めて動く処理が多いほど、リリースのワークフローが壊れるリスクが高まるからです。 GitHub Act
pull_request_target で GitHub Actions の改竄を防ぐ
本記事では GitHub Actions で pull_request event の代わりに pull_request_target を用い、 workflow の改竄を防いでより安全に CI を実行する方法について紹介します。 まずは前置きとして背景や解決したいセキュリティ的な課題について説明した後、 pull_request_target を用いた安全な CI の実行について紹介します。 本記事では OSS 開発とは違い業務で private repository を用いて複数人で開発を行うことを前提にします。 長いので要約 GitHub Actions で Workflow の改竄を防ぎたい GitHub の branch protection rule や codeowner, OIDC だけでは不十分なケースもある pull_request event の代わりに pull_r
mainブランチよりも古いブランチでCIを実行できなくしたい - くりにっき
たまにやりたくなるやつメモ モチベーション 実際のスクリプト おまけ：実際にGitLab CIで動かしてるやつ 2024/06/28 22:06追記：GitHub Actionsの場合の注意点 モチベーション CIでTerraformを動かしていると mainブランチを自動apply PRとかでマージ前に挙動を確認したい場合はPRに出ているブランチを手動apply というワークフローを作ることがよくあるんですが、最新のmainブランチよりも古いブランチをapplyした時にapply済の構成が巻き戻って事故になるため、そうならないように防止したかったというやつです。 実際のスクリプト どのCIで動かすかによって多少は変わってくると思うけどだいたいこれで動くと思います。 default_branch=`git remote show origin | grep 'HEAD branch:' |
GitHub - nektos/act: Run your GitHub Actions locally 🚀
"Think globally, act locally" Run your GitHub Actions locally! Why would you want to do this? Two reasons: Fast Feedback - Rather than having to commit/push every time you want to test out the changes you are making to your .github/workflows/ files (or for any changes to embedded GitHub actions), you can use act to run the actions locally. The environment variables and filesystem are all configure
複数のアプリのバージョンを一箇所で集中管理してCIから一括バージョンアップできるようにした - くりにっき
モチベーション リポジトリ 動いてる風景 対応形式 仕組み 各リポジトリに適用してるItamaeのレシピファイル こだわりポイント CI用にGitHub Appを作った モチベーション dependabotだとライブラリの自動バージョンアップはできるのだが、RubyやGoなどのランタイムのバージョンまでは対応してないので一箇所で管理できるようにしたかった 実は一箇所で管理すること自体は既に https://github.com/sue445/ci-config-itamae でやってたのだが、手元に動かす方式だと忘れるのでCIで動かすようにしたかった CI化は割とすぐに終わったのだが、パブリックリポジトリの設定とプライベートリポジトリの設定が混在してたのでこのリポジトリもプライベートリポジトリでずっと運用していた。しかしリポジトリの数が多すぎて*1 ActionsのQuotaを使い切りそう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
garnix | the nix CI
Testing LLM-enabled applications through evaluations :: CircleCI Documentation
【個人開発】キリ番を祝ってくれるGithub Actionsをリリースしました🎉【Go】 - Qiita
Improving GitHub Deployments with Merge Queue
GitHub - changesets/action
package-manager-best-practices/published/npm.md at main · ossf/package-manager-best-practices
