[{"data":1,"prerenderedAt":744},["ShallowReactive",2],{"/ja-jp/blog/categories/security-labs":3,"navigation-ja-jp":22,"banner-ja-jp":443,"footer-ja-jp":453,"security-labs-category-page-total-items-ja-jp":689,"security-labs-category-page-featured-ja-jp":690,"security-labs-category-page-1-ja-jp":724},{"id":4,"title":5,"body":6,"category":6,"config":7,"content":12,"description":6,"extension":15,"meta":16,"navigation":9,"path":17,"seo":18,"slug":6,"stem":20,"testContent":6,"type":6,"__hash__":21},"blogCategories/ja-jp/blog/categories/security-labs.yml","Security Labs",null,{"template":8,"isCustomCategory":9,"slug":10,"hide":11},"BlogCategory",true,"security-labs",false,{"name":13,"description":14},"セキュリティリサーチ","Learn about cybersecurity trends, best practices, and third-party threats to secure your code and digital infrastructure.","yml",{},"/ja-jp/blog/categories/security-labs",{"title":13,"description":19},"Browse articles related to セキュリティリサーチ on the GitLab Blog","ja-jp/blog/categories/security-labs","-X8QcedzdzVRaFBAA3gmxbVhS6zVmEJT1EYG7gUnsgc",{"logo":23,"freeTrial":28,"sales":33,"login":38,"items":43,"search":363,"minimal":396,"duo":413,"switchNav":422,"pricingDeployment":433},{"config":24},{"href":25,"dataGaName":26,"dataGaLocation":27},"/ja-jp/","gitlab logo","header",{"text":29,"config":30},"無料トライアルを開始",{"href":31,"dataGaName":32,"dataGaLocation":27},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":34,"config":35},"お問い合わせ",{"href":36,"dataGaName":37,"dataGaLocation":27},"/ja-jp/sales/","sales",{"text":39,"config":40},"サインイン",{"href":41,"dataGaName":42,"dataGaLocation":27},"https://gitlab.com/users/sign_in/","sign in",[44,73,175,180,283,344],{"text":45,"config":46,"menu":48},"プラットフォーム",{"dataNavLevelOne":47},"platform",{"type":49,"columns":50},"cards",[51,57,65],{"title":45,"description":52,"link":53},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":54,"config":55},"プラットフォームを探索",{"href":56,"dataGaName":47,"dataGaLocation":27},"/ja-jp/platform/",{"title":58,"description":59,"link":60},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":61,"config":62},"GitLab Duoのご紹介",{"href":63,"dataGaName":64,"dataGaLocation":27},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":66,"description":67,"link":68},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":69,"config":70},"詳細はこちら",{"href":71,"dataGaName":72,"dataGaLocation":27},"/ja-jp/why-gitlab/","why gitlab",{"text":74,"left":9,"config":75,"menu":77},"製品",{"dataNavLevelOne":76},"solutions",{"type":78,"link":79,"columns":83,"feature":154},"lists",{"text":80,"config":81},"すべてのソリューションを表示",{"href":82,"dataGaName":76,"dataGaLocation":27},"/ja-jp/solutions/",[84,109,132],{"title":85,"description":86,"link":87,"items":92},"自動化","CI/CDと自動化でデプロイを加速",{"config":88},{"icon":89,"href":90,"dataGaName":91,"dataGaLocation":27},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[93,97,100,105],{"text":94,"config":95},"CI/CD",{"href":96,"dataGaLocation":27,"dataGaName":94},"/ja-jp/solutions/continuous-integration/",{"text":58,"config":98},{"href":63,"dataGaLocation":27,"dataGaName":99},"gitlab duo agent platform - product menu",{"text":101,"config":102},"ソースコード管理",{"href":103,"dataGaLocation":27,"dataGaName":104},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":106,"config":107},"自動化されたソフトウェアデリバリー",{"href":90,"dataGaLocation":27,"dataGaName":108},"Automated software delivery",{"title":110,"description":111,"link":112,"items":117},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":113},{"href":114,"dataGaName":115,"dataGaLocation":27,"icon":116},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[118,122,127],{"text":119,"config":120},"アプリケーションセキュリティテスト",{"href":114,"dataGaName":121,"dataGaLocation":27},"Application security testing",{"text":123,"config":124},"ソフトウェアサプライチェーンの安全性",{"href":125,"dataGaLocation":27,"dataGaName":126},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":128,"config":129},"ソフトウェアコンプライアンス",{"href":130,"dataGaName":131,"dataGaLocation":27},"/ja-jp/solutions/software-compliance/","software compliance",{"title":133,"link":134,"items":139},"測定",{"config":135},{"icon":136,"href":137,"dataGaName":138,"dataGaLocation":27},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[140,144,149],{"text":141,"config":142},"可視性と測定",{"href":137,"dataGaLocation":27,"dataGaName":143},"Visibility and Measurement",{"text":145,"config":146},"バリューストリーム管理",{"href":147,"dataGaLocation":27,"dataGaName":148},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":150,"config":151},"分析とインサイト",{"href":152,"dataGaLocation":27,"dataGaName":153},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":155,"type":78,"items":156},"GitLabが活躍する場所",[157,163,169],{"text":158,"config":159},"エンタープライズ",{"icon":160,"href":161,"dataGaLocation":27,"dataGaName":162},"Building","/ja-jp/enterprise/","enterprise",{"text":164,"config":165},"スモールビジネス",{"icon":166,"href":167,"dataGaLocation":27,"dataGaName":168},"Work","/ja-jp/small-business/","small business",{"text":170,"config":171},"公共部門",{"icon":172,"href":173,"dataGaLocation":27,"dataGaName":174},"Organization","/ja-jp/solutions/public-sector/","public sector",{"text":176,"config":177},"価格",{"href":178,"dataGaName":179,"dataGaLocation":27,"dataNavLevelOne":179},"/ja-jp/pricing/","pricing",{"text":181,"config":182,"menu":184},"リソース",{"dataNavLevelOne":183},"resources",{"type":78,"link":185,"columns":189,"feature":269},{"text":186,"config":187},"すべてのリソースを表示",{"href":188,"dataGaName":183,"dataGaLocation":27},"/ja-jp/resources/",[190,223,241],{"title":191,"items":192},"はじめに",[193,198,203,208,213,218],{"text":194,"config":195},"インストール",{"href":196,"dataGaName":197,"dataGaLocation":27},"/ja-jp/install/","install",{"text":199,"config":200},"クイックスタートガイド",{"href":201,"dataGaName":202,"dataGaLocation":27},"/ja-jp/get-started/","quick setup checklists",{"text":204,"config":205},"学ぶ",{"href":206,"dataGaLocation":27,"dataGaName":207},"https://university.gitlab.com/","learn",{"text":209,"config":210},"製品ドキュメント",{"href":211,"dataGaName":212,"dataGaLocation":27},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":214,"config":215},"ベストプラクティスビデオ",{"href":216,"dataGaName":217,"dataGaLocation":27},"/ja-jp/getting-started-videos/","best practice videos",{"text":219,"config":220},"インテグレーション",{"href":221,"dataGaName":222,"dataGaLocation":27},"/ja-jp/integrations/","integrations",{"title":224,"items":225},"検索する",[226,231,236],{"text":227,"config":228},"お客様成功事例",{"href":229,"dataGaName":230,"dataGaLocation":27},"/ja-jp/customers/","customer success stories",{"text":232,"config":233},"ブログ",{"href":234,"dataGaName":235,"dataGaLocation":27},"/ja-jp/blog/","blog",{"text":237,"config":238},"リモート",{"href":239,"dataGaName":240,"dataGaLocation":27},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":242,"items":243},"つなげる",[244,249,254,259,264],{"text":245,"config":246},"GitLabサービス",{"href":247,"dataGaName":248,"dataGaLocation":27},"/ja-jp/services/","services",{"text":250,"config":251},"コミュニティ",{"href":252,"dataGaName":253,"dataGaLocation":27},"/community/","community",{"text":255,"config":256},"フォーラム",{"href":257,"dataGaName":258,"dataGaLocation":27},"https://forum.gitlab.com/","forum",{"text":260,"config":261},"イベント",{"href":262,"dataGaName":263,"dataGaLocation":27},"/events/","events",{"text":265,"config":266},"パートナー",{"href":267,"dataGaName":268,"dataGaLocation":27},"/ja-jp/partners/","partners",{"config":270,"text":273,"image":274,"link":278},{"background":271,"textColor":272},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":275,"config":276},"ソースプロモカード",{"src":277},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":279,"config":280},"最新情報を読む",{"href":281,"dataGaName":282,"dataGaLocation":27},"/ja-jp/the-source/","the source",{"text":284,"config":285,"menu":287},"会社情報",{"dataNavLevelOne":286},"company",{"type":78,"columns":288},[289],{"items":290},[291,296,302,304,309,314,319,324,329,334,339],{"text":292,"config":293},"GitLabについて",{"href":294,"dataGaName":295,"dataGaLocation":27},"/ja-jp/company/","about",{"text":297,"config":298,"footerGa":301},"採用情報",{"href":299,"dataGaName":300,"dataGaLocation":27},"/jobs/","jobs",{"dataGaName":300},{"text":260,"config":303},{"href":262,"dataGaName":263,"dataGaLocation":27},{"text":305,"config":306},"経営陣",{"href":307,"dataGaName":308,"dataGaLocation":27},"/company/team/e-group/","leadership",{"text":310,"config":311},"チーム",{"href":312,"dataGaName":313,"dataGaLocation":27},"/company/team/","team",{"text":315,"config":316},"ハンドブック",{"href":317,"dataGaName":318,"dataGaLocation":27},"https://handbook.gitlab.com/","handbook",{"text":320,"config":321},"投資家向け情報",{"href":322,"dataGaName":323,"dataGaLocation":27},"https://ir.gitlab.com/","investor relations",{"text":325,"config":326},"トラストセンター",{"href":327,"dataGaName":328,"dataGaLocation":27},"/ja-jp/security/","trust center",{"text":330,"config":331},"AI Transparency Center",{"href":332,"dataGaName":333,"dataGaLocation":27},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":335,"config":336},"ニュースレター",{"href":337,"dataGaName":338,"dataGaLocation":27},"/company/contact/#contact-forms","newsletter",{"text":340,"config":341},"プレス",{"href":342,"dataGaName":343,"dataGaLocation":27},"/press/","press",{"text":34,"config":345,"menu":346},{"dataNavLevelOne":286},{"type":78,"columns":347},[348],{"items":349},[350,353,358],{"text":34,"config":351},{"href":36,"dataGaName":352,"dataGaLocation":27},"talk to sales",{"text":354,"config":355},"サポートを受ける",{"href":356,"dataGaName":357,"dataGaLocation":27},"https://support.gitlab.com","support portal",{"text":359,"config":360},"カスタマーポータル",{"href":361,"dataGaName":362,"dataGaLocation":27},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":364,"login":365,"suggestions":372},"閉じる",{"text":366,"link":367},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":368,"config":369},"GitLab.com",{"href":41,"dataGaName":370,"dataGaLocation":371},"search login","search",{"text":373,"default":374},"提案",[375,377,382,384,388,392],{"text":58,"config":376},{"href":63,"dataGaName":58,"dataGaLocation":371},{"text":378,"config":379},"コード提案（AI）",{"href":380,"dataGaName":381,"dataGaLocation":371},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":94,"config":383},{"href":96,"dataGaName":94,"dataGaLocation":371},{"text":385,"config":386},"GitLab on AWS",{"href":387,"dataGaName":385,"dataGaLocation":371},"/ja-jp/partners/technology-partners/aws/",{"text":389,"config":390},"GitLab on Google Cloud",{"href":391,"dataGaName":389,"dataGaLocation":371},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":393,"config":394},"GitLabを選ぶ理由",{"href":71,"dataGaName":395,"dataGaLocation":371},"Why GitLab?",{"freeTrial":397,"mobileIcon":401,"desktopIcon":406,"secondaryButton":409},{"text":29,"config":398},{"href":399,"dataGaName":32,"dataGaLocation":400},"https://gitlab.com/-/trials/new/","nav",{"altText":402,"config":403},"GitLabアイコン",{"src":404,"dataGaName":405,"dataGaLocation":400},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":402,"config":407},{"src":408,"dataGaName":405,"dataGaLocation":400},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":191,"config":410},{"href":411,"dataGaName":412,"dataGaLocation":400},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":414,"mobileIcon":418,"desktopIcon":420},{"text":415,"config":416},"GitLab Duoの詳細について",{"href":63,"dataGaName":417,"dataGaLocation":400},"gitlab duo",{"altText":402,"config":419},{"src":404,"dataGaName":405,"dataGaLocation":400},{"altText":402,"config":421},{"src":408,"dataGaName":405,"dataGaLocation":400},{"button":423,"mobileIcon":428,"desktopIcon":430},{"text":424,"config":425},"/switch",{"href":426,"dataGaName":427,"dataGaLocation":400},"#contact","switch",{"altText":402,"config":429},{"src":404,"dataGaName":405,"dataGaLocation":400},{"altText":402,"config":431},{"src":432,"dataGaName":405,"dataGaLocation":400},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":434,"mobileIcon":439,"desktopIcon":441},{"text":435,"config":436},"価格ページに戻る",{"href":178,"dataGaName":437,"dataGaLocation":400,"icon":438},"back to pricing","GoBack",{"altText":402,"config":440},{"src":404,"dataGaName":405,"dataGaLocation":400},{"altText":402,"config":442},{"src":408,"dataGaName":405,"dataGaLocation":400},{"title":444,"button":445,"config":450},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":446,"config":447},"6月10日のGitLab Transcendに申し込む",{"href":448,"dataGaName":449,"dataGaLocation":27},"/ja-jp/releases/whats-new/#sign-up","transcend event",{"layout":451,"icon":452,"disabled":11},"release","AiStar",{"data":454},{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":680},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":457,"config":458},"ページのソースを表示",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"このページを編集",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"ご協力をお願いします",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,523,576,619,646],{"title":176,"links":479,"subMenu":494},[480,484,489],{"text":481,"config":482},"プランの表示",{"href":178,"dataGaName":483,"dataGaLocation":461},"view plans",{"text":485,"config":486},"Premiumを選ぶ理由",{"href":487,"dataGaName":488,"dataGaLocation":461},"/ja-jp/pricing/premium/","why premium",{"text":490,"config":491},"Ultimateを選ぶ理由",{"href":492,"dataGaName":493,"dataGaLocation":461},"/ja-jp/pricing/ultimate/","why ultimate",[495],{"title":34,"links":496},[497,499,501,503,508,513,518],{"text":34,"config":498},{"href":36,"dataGaName":37,"dataGaLocation":461},{"text":354,"config":500},{"href":356,"dataGaName":357,"dataGaLocation":461},{"text":359,"config":502},{"href":361,"dataGaName":362,"dataGaLocation":461},{"text":504,"config":505},"ステータス",{"href":506,"dataGaName":507,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":509,"config":510},"利用規約",{"href":511,"dataGaName":512,"dataGaLocation":461},"/terms/","terms of use",{"text":514,"config":515},"プライバシーに関する声明",{"href":516,"dataGaName":517,"dataGaLocation":461},"/ja-jp/privacy/","privacy statement",{"text":519,"config":520},"Cookie 優先設定",{"dataGaName":521,"dataGaLocation":461,"id":522,"isOneTrustButton":9},"cookie preferences","ot-sdk-btn",{"title":74,"links":524,"subMenu":533},[525,529],{"text":526,"config":527},"DevSecOpsプラットフォーム",{"href":56,"dataGaName":528,"dataGaLocation":461},"devsecops platform",{"text":530,"config":531},"AI支援開発",{"href":63,"dataGaName":532,"dataGaLocation":461},"ai-assisted development",[534],{"title":535,"links":536},"トピック",[537,541,546,551,556,561,566,571],{"text":94,"config":538},{"href":539,"dataGaName":540,"dataGaLocation":461},"/ja-jp/topics/ci-cd/","cicd",{"text":542,"config":543},"GitOps",{"href":544,"dataGaName":545,"dataGaLocation":461},"/ja-jp/topics/gitops/","gitops",{"text":547,"config":548},"DevOps",{"href":549,"dataGaName":550,"dataGaLocation":461},"/ja-jp/topics/devops/","devops",{"text":552,"config":553},"バージョン管理",{"href":554,"dataGaName":555,"dataGaLocation":461},"/ja-jp/topics/version-control/","version control",{"text":557,"config":558},"DevSecOps",{"href":559,"dataGaName":560,"dataGaLocation":461},"/ja-jp/topics/devsecops/","devsecops",{"text":562,"config":563},"クラウドネイティブ",{"href":564,"dataGaName":565,"dataGaLocation":461},"/ja-jp/topics/cloud-native/","cloud native",{"text":567,"config":568},"コーディングのためのAI",{"href":569,"dataGaName":570,"dataGaLocation":461},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":572,"config":573},"エージェント型AI",{"href":574,"dataGaName":575,"dataGaLocation":461},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":577,"links":578},"ソリューション",[579,582,584,589,593,596,599,602,604,606,609,614],{"text":119,"config":580},{"href":114,"dataGaName":581,"dataGaLocation":461},"Application Security Testing",{"text":106,"config":583},{"href":90,"dataGaName":91,"dataGaLocation":461},{"text":585,"config":586},"アジャイル開発",{"href":587,"dataGaName":588,"dataGaLocation":461},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":590,"config":591},"SCM",{"href":103,"dataGaName":592,"dataGaLocation":461},"source code management",{"text":94,"config":594},{"href":96,"dataGaName":595,"dataGaLocation":461},"continuous integration & delivery",{"text":145,"config":597},{"href":147,"dataGaName":598,"dataGaLocation":461},"value stream management",{"text":542,"config":600},{"href":601,"dataGaName":545,"dataGaLocation":461},"/ja-jp/solutions/gitops/",{"text":158,"config":603},{"href":161,"dataGaName":162,"dataGaLocation":461},{"text":164,"config":605},{"href":167,"dataGaName":168,"dataGaLocation":461},{"text":607,"config":608},"公共機関",{"href":173,"dataGaName":174,"dataGaLocation":461},{"text":610,"config":611},"教育",{"href":612,"dataGaName":613,"dataGaLocation":461},"/ja-jp/solutions/education/","education",{"text":615,"config":616},"金融サービス",{"href":617,"dataGaName":618,"dataGaLocation":461},"/ja-jp/solutions/finance/","financial services",{"title":181,"links":620},[621,623,625,627,630,632,634,636,638,640,642,644],{"text":194,"config":622},{"href":196,"dataGaName":197,"dataGaLocation":461},{"text":199,"config":624},{"href":201,"dataGaName":202,"dataGaLocation":461},{"text":204,"config":626},{"href":206,"dataGaName":207,"dataGaLocation":461},{"text":209,"config":628},{"href":211,"dataGaName":629,"dataGaLocation":461},"docs",{"text":232,"config":631},{"href":234,"dataGaName":235,"dataGaLocation":461},{"text":227,"config":633},{"href":229,"dataGaName":230,"dataGaLocation":461},{"text":237,"config":635},{"href":239,"dataGaName":240,"dataGaLocation":461},{"text":245,"config":637},{"href":247,"dataGaName":248,"dataGaLocation":461},{"text":250,"config":639},{"href":252,"dataGaName":253,"dataGaLocation":461},{"text":255,"config":641},{"href":257,"dataGaName":258,"dataGaLocation":461},{"text":260,"config":643},{"href":262,"dataGaName":263,"dataGaLocation":461},{"text":265,"config":645},{"href":267,"dataGaName":268,"dataGaLocation":461},{"title":284,"links":647},[648,650,652,654,656,658,660,664,669,671,673,675],{"text":292,"config":649},{"href":294,"dataGaName":286,"dataGaLocation":461},{"text":297,"config":651},{"href":299,"dataGaName":300,"dataGaLocation":461},{"text":305,"config":653},{"href":307,"dataGaName":308,"dataGaLocation":461},{"text":310,"config":655},{"href":312,"dataGaName":313,"dataGaLocation":461},{"text":315,"config":657},{"href":317,"dataGaName":318,"dataGaLocation":461},{"text":320,"config":659},{"href":322,"dataGaName":323,"dataGaLocation":461},{"text":661,"config":662},"Sustainability",{"href":663,"dataGaName":661,"dataGaLocation":461},"/sustainability/",{"text":665,"config":666},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":667,"dataGaName":668,"dataGaLocation":461},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":325,"config":670},{"href":327,"dataGaName":328,"dataGaLocation":461},{"text":335,"config":672},{"href":337,"dataGaName":338,"dataGaLocation":461},{"text":340,"config":674},{"href":342,"dataGaName":343,"dataGaLocation":461},{"text":676,"config":677},"現代奴隷制の透明性に関する声明",{"href":678,"dataGaName":679,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":681},[682,684,687],{"text":509,"config":683},{"href":511,"dataGaName":512,"dataGaLocation":461},{"text":685,"config":686},"Cookieの設定",{"dataGaName":521,"dataGaLocation":461,"id":522,"isOneTrustButton":9},{"text":514,"config":688},{"href":516,"dataGaName":517,"dataGaLocation":461},3,{"id":691,"title":692,"authorSlugs":693,"authors":695,"body":697,"category":10,"categorySlug":10,"config":698,"content":701,"date":705,"description":710,"extension":15,"externalUrl":6,"featured":9,"heroImage":702,"isFeatured":9,"meta":711,"navigation":9,"path":712,"publishedDate":705,"rawbody":713,"seo":714,"slug":700,"stem":719,"tagSlugs":720,"tags":722,"template":699,"updatedDate":704,"__hash__":723},"blogPosts/ja-jp/blog/automated-detection-testing-framework.yml","GitLab CI/CDとDuoで自動検知テストフレームワークを構築する",[694],"evan-baltman",[696],"Evan Baltman","セキュリティ運用センター（SOC）において健全なアラートシステムを維持する上で、誤検出のチューニングは課題の半分にすぎません。見落とされがちなもう一方の課題は、めったに発火しない重要な検知ルールが、誰にも気づかれないまま完全に機能しなくなっていないかを確認することです。\n\nGitLabでは、Signals Engineeringチームが自社インフラ上で実際の悪意ある行動をシミュレートすることで検知テストを実施しています。ログソースからインジェスション、SIEMへの取り込み、そしてSOARによるアラートルーティングまで、検知がエンドツーエンドで機能することを検証するためです。これは商用のBreach and Attack Simulation（BAS）ツールと同じアプローチですが、それらのツールは高価で汎用的であり、私たちの検知スタックに特化したものではありません。そこで私たちは、Weekly Attack Testing for Continuous Health、略して**WATCH**と名付けた完全自動化フレームワークを自社で構築しました。\n\n本記事では、このフレームワークを開発した背景、その仕組み、そして自社環境での活用方法についてご説明します。\n\n##  検知の検証におけるギャップ\n\nログスキーマの変更、SIEMのアップデート、パイプラインの設定ミスなど、検知がサイレントに失敗する原因は無数に存在します。一方、期待通りに発火するパターンはただひとつです。こうした現実を踏まえると、結論は明らかです。「既存の検知を意図的にトリガーしてみよう！」ただし、すぐに次の疑問が浮かびます。「どうやって検知をトリガーするのか？」「どのくらいの頻度で行うべきか？」\n\n検知をトリガーする方法のひとつは、悪意ある行動をシミュレートするログをSIEMに再投入するという「合成アプローチ」です。そして、検知ルールが偽の問題を検知してアラートを発するかどうかを確認します。ただしこのアプローチには、「実世界」のシナリオで検知が機能することを証明できないという問題に加え、アラートライフサイクルの中でも特にエラーが発生しやすいログインジェスション（ログソースからSIEMまでの経路）の検証ができないという欠点があります。\n\n以前、私たちは[GitLab Universal Automated Response and Detection（GUARD）システム](https://about.gitlab.com/blog/automating-cybersecurity-threat-detections-with-gitlab-ci-cd/)がDetections as Code（DaC）パイプラインを通じて検知の作成とデプロイを自動化する方法、そしてSOARを通じてアラートのルーティングとトリアージを行う方法についてご紹介しました。DaCパイプラインはエラーなしに検知を*デプロイできる*ことの検証問題を解決しましたが、対象とする行動が実際に発生した際にその検知が*発火するか*という問いには答えられていません。\n\nWATCHはそのギャップを埋めます。検知が機能しているという確信を与えてくれる継続的な検証レイヤーです。\n\n## WATCHの仕組み\n\n大まかに言えば、WATCHはステージング環境でスクリプト化された攻撃シミュレーションを実行し、期待されるアラートがセキュリティ監視スタック全体に伝播することを検証します。検知ルールを管理するSIEM、アラートルーティングを担うSOAR、そしてチームが検知の健全性を監視するダッシュボードに至るまでを確認します。\n\nWATCHテストのライフサイクルは次のとおりです。\n\n1. **スケジューリング**: 毎週、スケジュールされたGitLab CI/CDパイプラインがすべてのアクティブなテストを検出し、週全体にわたってランダムな時間スロットに振り分けます。ランダム化は重要です。テストが予測可能なタイミングで発火すると、テスト活動と実際の脅威を区別しやすくなり、タイミングに敏感な検知の問題をマスクしてしまう可能性があるためです。\n2. **事前通知**: テスト実行前に、WATCHは専用の「WATCH Heads Up」ストーリーを通じてSOARに通知し、トリガーが期待される検知を登録します。これにより、SOARが次に何が来るかを把握できるよう、追跡可能なレコードが作成されます。\n3. **実行**: テストがシミュレートされた悪意ある行動を実行します。たとえば、管理者アカウントのパスワードをリセットしたり、ステージング環境に対して不審なAPI呼び出しを行ったりします。\n4. **検知**: SIEMがステージング環境からのアクティビティログを処理し、対応する検知ルールを（うまくいけば）発火させます。\n5. **相関分析**: SOARにアラートが届くと、「これはWATCHテストか？」のチェックが行われ、各アラートが登録済みのテストに対応するかどうかを3つの要素で照合します。テスト実行からアラート到着までの時間ウィンドウ、アクターのID（IPアドレスまたはユーザー名）、そして発火した検知のルールIDです。これにより、WATCHが生成したアラートがSIRTへの実際のインシデントとしてエスカレーションされることなく、パイプライン全体の検証が可能になります。\n6. **検証**: フォローアップのパイプラインステージが、期待されるすべての検知が発火したかどうかを確認し、検知のステータスメタデータを更新し、更新された結果をGitLab Pagesダッシュボードにデプロイします。いずれかの検知が発火しなかった場合、チームのSlackチャンネルに通知が送られます。\n\n## GitLab CI/CDでWATCHを使う\n\nWATCHは3つのパイプラインステージにわたるオーケストレーションのバックボーンとしてGitLab CI/CDを活用しています。\n\n**schedule_pipelines**ステージは毎週実行され、テストの配布を担います。すべてのアクティブなテストを検出し、グループに振り分け、週全体にわたってランダムな時間帯に実行するようスケジュールされたパイプラインを作成します。スケジュールされた各パイプラインには、実行すべきテストを指定する`TESTS_TO_RUN`変数が付与されます。\n\n**run_tests**ステージでは実際の攻撃シミュレーションが行われます。そのパイプライン実行に割り当てられたテストを実行し、実行統計を`detection_status.json`に保存し、アラートの相関分析がダウンストリームで行えるようSOARのレコードIDを記録します。\n\n**pages**ステージは検証とレポートを担います。SOARに問い合わせてアラートが生成され適切にルーティングされたことを確認し、検証結果で検知メタデータを更新し、最新のテスト結果をGitLab Pagesダッシュボードにデプロイします。\n\n以下は、WATCHパイプライン用のGitLab CI/CD `gitlab-ci.yml`設定ファイルのテンプレートです。\n\n```\nspec:\n  inputs:\n    weekly_scheduling:\n      type: boolean\n      default: false\n      description: \"Enable weekly scheduling of detection tests.\"\n    update_pages:\n      type: boolean\n      default: false\n      description: \"For triggering the update of GitLab Pages dashboard.\"\n\n---\n\n# Specify the Docker image to use for the job\nimage: python:3.12\n\nstages:\n  - schedule_pipelines\n  - run_tests\n  - pages\n\n# Job to manage scheduled pipelines (runs when weekly_scheduling input is true)\nmanage_scheduled_pipelines:\n  stage: schedule_pipelines\n  script:\n    - pip install -r requirements.txt\n    - python scripts/manage_scheduled_pipelines.py\n  rules:\n    - if: $TESTS_TO_RUN == null && $CI_PIPELINE_SOURCE == \"schedule\" && [[ inputs.weekly_scheduling ]] == true\n      when: on_success\n    - when: never\n\n# Job to run detection tests, save tines_record_id to detection_status.json, and commit\nrun_detection_tests:\n  stage: run_tests\n  script:\n    - pip install -r requirements.txt\n    - python main.py --prod --save-stats --scheduled-tests\n  rules:\n    - if: $TESTS_TO_RUN\n      when: on_success\n    - when: never\n\n# Job to verify alerts, update detection_status.json, commit, and deploy pages\npages:\n  stage: pages\n  script:\n    - pip install -r requirements.txt\n    - python scripts/verify_and_update_detections.py --tines-api-key ${TINES_API_KEY}\n    - mkdir -p public/data\n    - cp detection_status.json public/data/\n    - cp -r static/* public/\n  pages: true  # Required for GitLab 17.9+ to trigger Pages deployment\n  artifacts:\n    paths:\n      - public\n  rules:\n    - if: $TESTS_TO_RUN == null && [[ inputs.update_pages ]] == true\n      when: on_success\n    - when: never\n```\n\n## GitLab Duoを使ったテストの作成\n\nWATCHの設計における優先事項のひとつは、Signals EngineeringまたはSIRTチームの誰でも新しいテストを追加できるようにすることでした。このフレームワークは`BaseSecurityTest`抽象クラスを提供しており、テストIDの生成、アクターIDの管理、SOARとの連携といった定型作業をすべて処理します。これにより、テスト作成者はテスト環境のセットアップ、シミュレートされた悪意ある行動の実行、後処理の3点にのみ集中できます。\n\n```py\nclass BaseSecurityTest(ABC):\n\n    def __init__(self, config = {}, test_id: Optional[str] = None):\n        self.test_id = test_id or str(uuid.uuid4())\n        self.test_name = self.__class__.__name__\n        self.expected_detections = {}\n        self.actor_id = config.get('gitlab', {}).get(\n            'default_actor_id',\n            \"sirt_detection_test_user_\" + self.test_id[:8]\n        )\n        self.isActive = True\n        self.test_run_time = 300\n        self.config = config\n\n    @abstractmethod\n    def setup(self) -> bool:\n        \"\"\"Prepare test environment and resources\"\"\"\n\n    @abstractmethod\n    def execute(self) -> Dict[str, Any]:\n        \"\"\"Execute the malicious behavior simulation\"\"\"\n\n    @abstractmethod\n    def cleanup(self) -> bool:\n        \"\"\"Clean up test environment and resources\"\"\"\n```\n\n重要な設定は`expected_detections`ディクショナリです。これは、トリガーが期待されるSIEMのルール名を、アクターIDと期待されるアラート到着時刻にマッピングします。新しいテストは、`tests/`ディレクトリ内に`BaseSecurityTest`をサブクラス化したPythonファイルを作成し、シミュレートする行動を定義して、トリガーが期待される検知を宣言するだけです。テストランナーは次回のスケジュール実行時に自動的にそれを検出します。\n\nこの低摩擦なインターフェースが重要なのは、チームが実際にテストを書いてくれなければ、検知テストという取り組み自体が成立しないからです。テストの追加にパイプライン内部の全体像の理解が必要になれば、誰もやらなくなります。setup、execute、cleanupを実装し、期待される検知を宣言するというシンプルな仕様は、WATCHテストを[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)（GitLabのAIアシスタント）との相性を高めます。Duoにベースクラスと「特定のグループから大量のプロジェクトをクローンするテストを作って」「GraphQLを使ってこのプロジェクトのCI変数をすべて取得するテストを作って」「これらのプロジェクトを同じ命名規則にリネームして」といったプロンプトを与えると、Duoはフレームワークに直接プラグインできる動作するWATCHテストをスキャフォールドします。これにより、障壁がさらに下がります。エンジニアは「この検知をテストしたい」という考えから、Duoが実装作業の大半を担った状態で動作するテストまで、一気に進むことができます。\n\nPro Tip: GitLab Duoをさらに効果的に活用するために、私は[Duo Agent Skills](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/customize/agent_skills/)を活用しました。これは、テストの作成のような定型作業の標準と手順を定義するのに最適です。プロジェクトディレクトリには`skills/WATCH-test-creator`というフォルダがあり、SKILL.mdに優れたテストの条件、使用できるヘルパー関数、プロジェクトの目的が記述されています。上記のようなプロンプトを入力した直後にこのファイルが読み込まれるため、Duoに対して「あなたが何をしているのか、どうやればいいのか」を毎回説明し直す必要がなくなります。何より重要なのは、結果が一貫して高品質になることです。以下はそのファイルの抜粋です。\n\n````text\n---\nname: WATCH-test-creator\ndescription: Create WATCH (Orchestrated Offensive Penetration Simulator) security detection tests that simulate malicious behavior on GitLab infrastructure to validate SIEM detection rules and alerting pipelines.\n---\n\n## WATCH Test Creator\n\nYou are an expert at writing security detection tests for the WATCH framework. WATCH tests simulate malicious activities on GitLab-owned infrastructure to verify that the SecOps security monitoring stack (Elastic SIEM, Tines SOAR, alerting rules) properly detects and responds to threats.\n\n### Architecture Overview\n```\nProject Root\n├── core/\n│   ├── base_test.py          # Abstract base class all tests inherit from\n│   ├── test_runner.py         # Auto-discovers and executes tests\n│   └── webhook_manager.py     # Tines/SOAR notification integration\n├── tests/\n│   ├── gitlab/                # GitLab-specific detection tests\n│   └── gcp/                   # GCP-specific detection tests\n├── utils/\n│   ├── gitlab_helper.py       # GitLab API wrapper (users, projects, tokens, webhooks, OAuth)\n│   └── crypto_utils.py        # Password generation utility\n├── config/\n│   ├── settings.py            # Config loader (reads YAML + GITLAB_ADMIN_PAT env var)\n│   └── environments/\n│       ├── dev.yaml           # Local GDK config\n│       └── prod.yaml          # Production staging.gitlab.com config\n├── main.py                    # Entry point with CLI args\n└── detection_status.json      # Test results and detection metadata\n```\n\n````\n\n## テストダッシュボードによる可視性の向上\n\n![テストダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1777574679/ylrc96iip682sinfg7zi.png)\n\nWATCHはまた、[GitLab Pages](https://docs.gitlab.com/ja-jp/user/project/pages/)を通じて2つのインタラクティブなダッシュボードをデプロイし、チームが検知の健全性をリアルタイムで把握できるようにしています。\n\n* **検知ステータスダッシュボード**は、すべての検知ルールと現在のテスト状況の概要を提供します。各検知の発火回数、現在の合否状態、検知のアクティブ期間といったメトリクスが含まれます。テーブルはフィルタリングとソートが可能で、エンジニアはどの検知に注意が必要かをすぐに特定できます。\n* **テスト実行ダッシュボード**は、テストIDごとにグループ化され、検知カバレッジの内訳を含む個々のテスト実行の詳細なビューを提供します。アラート伝播時間を示すタイムライン可視化も含まれており、テスト実行からアラート到着までの所要時間や、SIEMの対応するアラートへの直接リンクを確認できます。\n\nこれらのダッシュボードは、以前は手動でパイプラインログやSIEMクエリを掘り起こして検知の健全性を確認していた作業を置き換えました。\n\nGUARDの他の部分と同様に、WATCHはGitLabをそのプラットフォームとして全面的に活用しています。\n\n* **GitLab CI/CDパイプラインとスケジュールパイプライン**が、週次スケジューリングから実行、ダッシュボードのデプロイまで、テストライフサイクル全体をオーケストレーションします。\n* **パイプラインインプット**により、ステージを個別にトリガーできるため、すべてのテストを再実行することなく、検証ステップだけ、あるいはダッシュボード更新だけを実行することができます。\n* **CI/CD変数**が、TinesおよびGitLabステージング環境へのアクセスに必要なAPIキーを安全に保管します。\n* **GitLab Pages**が、追加のインフラ不要でWATCHダッシュボードをホストします。別途ホスティングの管理も、追加のデプロイツールも必要ありません。\n* テストはGitLabプロジェクト内のPythonファイルに過ぎないため、DaCを通じた検知ルールと同様に、**バージョン管理、マージリクエストレビュー、コードオーナーシップ**の恩恵を受けます。\n\n## WATCHでプロアクティブな姿勢を維持する\n\nWATCHを構築したことで、チームの検知品質に対する姿勢が事後対応型からプロアクティブ型へと変わりました。WATCH導入以前は、検知の不具合はインシデントが発生して期待されるアラートが届かないときに初めて露見していました。これは、ギャップを発見するには最悪のタイミングです。今では検知の健全性について定期的な更新を受け取ることができ、実際に何かが起きる*前*に不具合を把握できます。新たな検知を開発しても、それが壊れたまま放置されることはないという安心感が生まれました。\n\nWATCHのもうひとつのメリットは、レッドチームがフラッシュオペレーションを実施した際に使用した戦術・技術・手順（TTP）を記録できることです。検知を実装してペンテスト作業の事後分析を行った後、WATCHを使ってそれらの検知を検証するためにTTPを再実行することができます。本質的に、WATCHは検知のアトミックテストを再実行可能なTTPにします。\n\n## WATCHを試す\n\nSOCを運営しSIEMの検知を頼りに脅威を捕捉しているなら、問うべきは「検知が壊れるかどうか」ではなく、「壊れたときに気づけるかどうか」です。この問いに答えるために商用BASプラットフォームは必要ありません。サンドボックス環境、CI/CDパイプライン、そして攻撃シミュレーションをスクリプト化するためのフレームワークがあれば、大きく前進できます。\n\n[GitLab Ultimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)に登録して、独自の検知テストフレームワークを構築してみてください。",{"featured":9,"template":699,"slug":700},"BlogPost","automated-detection-testing-framework",{"heroImage":702,"body":697,"authors":703,"updatedDate":704,"date":705,"title":692,"tags":706,"description":710,"category":10},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772195014/ooezwusxjl1f7ijfmbvj.png",[696],"2026-05-01","2026-04-30",[707,708,709],"security","security research","features","GitLabのSignals Engineeringチームが構築したWATCHフレームワークを通じて、セキュリティ監視パイプラインを継続的に検証する方法をご紹介します。",{},"/ja-jp/blog/automated-detection-testing-framework","seo:\n  config:\n    noIndex: false\n  title: GitLab CI/CDとDuoで検知テストを自動化する\n  description: GitLabのSignals\n    Engineingチームが構築したWATCHフレームワークを通じて、セキュリティ監視パイプラインを継続的に検証する方法をご紹介します。セキュリティ運用センター（SOC）の検知品質を維持するための実践的アプローチです。\n  ogImage: https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1772195014/ooezwusxjl1f7ijfmbvj.webp\ncontent:\n  heroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1772195014/ooezwusxjl1f7ijfmbvj.png\n  body: >-\n    セキュリティ運用センター（SOC）において健全なアラートシステムを維持する上で、誤検出のチューニングは課題の半分にすぎません。見落とされがちなもう一方の課題は、めったに発火しない重要な検知ルールが、誰にも気づかれないまま完全に機能しなくなっていないかを確認することです。\n\n\n    GitLabでは、Signals Engineeringチームが自社インフラ上で実際の悪意ある行動をシミュレートすることで検知テストを実施しています。ログソースからインジェスション、SIEMへの取り込み、そしてSOARによるアラートルーティングまで、検知がエンドツーエンドで機能することを検証するためです。これは商用のBreach and Attack Simulation（BAS）ツールと同じアプローチですが、それらのツールは高価で汎用的であり、私たちの検知スタックに特化したものではありません。そこで私たちは、Weekly Attack Testing for Continuous Health、略して**WATCH**と名付けた完全自動化フレームワークを自社で構築しました。\n\n\n    本記事では、このフレームワークを開発した背景、その仕組み、そして自社環境での活用方法についてご説明します。\n\n\n    ##  検知の検証におけるギャップ\n\n\n    ログスキーマの変更、SIEMのアップデート、パイプラインの設定ミスなど、検知がサイレントに失敗する原因は無数に存在します。一方、期待通りに発火するパターンはただひとつです。こうした現実を踏まえると、結論は明らかです。「既存の検知を意図的にトリガーしてみよう！」ただし、すぐに次の疑問が浮かびます。「どうやって検知をトリガーするのか？」「どのくらいの頻度で行うべきか？」\n\n\n    検知をトリガーする方法のひとつは、悪意ある行動をシミュレートするログをSIEMに再投入するという「合成アプローチ」です。そして、検知ルールが偽の問題を検知してアラートを発するかどうかを確認します。ただしこのアプローチには、「実世界」のシナリオで検知が機能することを証明できないという問題に加え、アラートライフサイクルの中でも特にエラーが発生しやすいログインジェスション（ログソースからSIEMまでの経路）の検証ができないという欠点があります。\n\n\n    以前、私たちは[GitLab Universal Automated Response and Detection（GUARD）システム](https://about.gitlab.com/blog/automating-cybersecurity-threat-detections-with-gitlab-ci-cd/)がDetections as Code（DaC）パイプラインを通じて検知の作成とデプロイを自動化する方法、そしてSOARを通じてアラートのルーティングとトリアージを行う方法についてご紹介しました。DaCパイプラインはエラーなしに検知を*デプロイできる*ことの検証問題を解決しましたが、対象とする行動が実際に発生した際にその検知が*発火するか*という問いには答えられていません。\n\n\n    WATCHはそのギャップを埋めます。検知が機能しているという確信を与えてくれる継続的な検証レイヤーです。\n\n\n    ## WATCHの仕組み\n\n\n    大まかに言えば、WATCHはステージング環境でスクリプト化された攻撃シミュレーションを実行し、期待されるアラートがセキュリティ監視スタック全体に伝播することを検証します。検知ルールを管理するSIEM、アラートルーティングを担うSOAR、そしてチームが検知の健全性を監視するダッシュボードに至るまでを確認します。\n\n\n    WATCHテストのライフサイクルは次のとおりです。\n\n\n    1. **スケジューリング**: 毎週、スケジュールされたGitLab CI/CDパイプラインがすべてのアクティブなテストを検出し、週全体にわたってランダムな時間スロットに振り分けます。ランダム化は重要です。テストが予測可能なタイミングで発火すると、テスト活動と実際の脅威を区別しやすくなり、タイミングに敏感な検知の問題をマスクしてしまう可能性があるためです。\n\n    2. **事前通知**: テスト実行前に、WATCHは専用の「WATCH Heads Up」ストーリーを通じてSOARに通知し、トリガーが期待される検知を登録します。これにより、SOARが次に何が来るかを把握できるよう、追跡可能なレコードが作成されます。\n\n    3. **実行**: テストがシミュレートされた悪意ある行動を実行します。たとえば、管理者アカウントのパスワードをリセットしたり、ステージング環境に対して不審なAPI呼び出しを行ったりします。\n\n    4. **検知**: SIEMがステージング環境からのアクティビティログを処理し、対応する検知ルールを（うまくいけば）発火させます。\n\n    5. **相関分析**: SOARにアラートが届くと、「これはWATCHテストか？」のチェックが行われ、各アラートが登録済みのテストに対応するかどうかを3つの要素で照合します。テスト実行からアラート到着までの時間ウィンドウ、アクターのID（IPアドレスまたはユーザー名）、そして発火した検知のルールIDです。これにより、WATCHが生成したアラートがSIRTへの実際のインシデントとしてエスカレーションされることなく、パイプライン全体の検証が可能になります。\n\n    6. **検証**: フォローアップのパイプラインステージが、期待されるすべての検知が発火したかどうかを確認し、検知のステータスメタデータを更新し、更新された結果をGitLab Pagesダッシュボードにデプロイします。いずれかの検知が発火しなかった場合、チームのSlackチャンネルに通知が送られます。\n\n\n    ## GitLab CI/CDでWATCHを使う\n\n\n    WATCHは3つのパイプラインステージにわたるオーケストレーションのバックボーンとしてGitLab CI/CDを活用しています。\n\n\n    **schedule_pipelines**ステージは毎週実行され、テストの配布を担います。すべてのアクティブなテストを検出し、グループに振り分け、週全体にわたってランダムな時間帯に実行するようスケジュールされたパイプラインを作成します。スケジュールされた各パイプラインには、実行すべきテストを指定する`TESTS_TO_RUN`変数が付与されます。\n\n\n    **run_tests**ステージでは実際の攻撃シミュレーションが行われます。そのパイプライン実行に割り当てられたテストを実行し、実行統計を`detection_status.json`に保存し、アラートの相関分析がダウンストリームで行えるようSOARのレコードIDを記録します。\n\n\n    **pages**ステージは検証とレポートを担います。SOARに問い合わせてアラートが生成され適切にルーティングされたことを確認し、検証結果で検知メタデータを更新し、最新のテスト結果をGitLab Pagesダッシュボードにデプロイします。\n\n\n    以下は、WATCHパイプライン用のGitLab CI/CD `gitlab-ci.yml`設定ファイルのテンプレートです。\n\n\n    ```\n\n    spec:\n      inputs:\n        weekly_scheduling:\n          type: boolean\n          default: false\n          description: \"Enable weekly scheduling of detection tests.\"\n        update_pages:\n          type: boolean\n          default: false\n          description: \"For triggering the update of GitLab Pages dashboard.\"\n\n    ---\n\n\n    # Specify the Docker image to use for the job\n\n    image: python:3.12\n\n\n    stages:\n      - schedule_pipelines\n      - run_tests\n      - pages\n\n    # Job to manage scheduled pipelines (runs when weekly_scheduling input is true)\n\n    manage_scheduled_pipelines:\n      stage: schedule_pipelines\n      script:\n        - pip install -r requirements.txt\n        - python scripts/manage_scheduled_pipelines.py\n      rules:\n        - if: $TESTS_TO_RUN == null && $CI_PIPELINE_SOURCE == \"schedule\" && [[ inputs.weekly_scheduling ]] == true\n          when: on_success\n        - when: never\n\n    # Job to run detection tests, save tines_record_id to detection_status.json, and commit\n\n    run_detection_tests:\n      stage: run_tests\n      script:\n        - pip install -r requirements.txt\n        - python main.py --prod --save-stats --scheduled-tests\n      rules:\n        - if: $TESTS_TO_RUN\n          when: on_success\n        - when: never\n\n    # Job to verify alerts, update detection_status.json, commit, and deploy pages\n\n    pages:\n      stage: pages\n      script:\n        - pip install -r requirements.txt\n        - python scripts/verify_and_update_detections.py --tines-api-key ${TINES_API_KEY}\n        - mkdir -p public/data\n        - cp detection_status.json public/data/\n        - cp -r static/* public/\n      pages: true  # Required for GitLab 17.9+ to trigger Pages deployment\n      artifacts:\n        paths:\n          - public\n      rules:\n        - if: $TESTS_TO_RUN == null && [[ inputs.update_pages ]] == true\n          when: on_success\n        - when: never\n    ```\n\n\n    ## GitLab Duoを使ったテストの作成\n\n\n    WATCHの設計における優先事項のひとつは、Signals EngineeringまたはSIRTチームの誰でも新しいテストを追加できるようにすることでした。このフレームワークは`BaseSecurityTest`抽象クラスを提供しており、テストIDの生成、アクターIDの管理、SOARとの連携といった定型作業をすべて処理します。これにより、テスト作成者はテスト環境のセットアップ、シミュレートされた悪意ある行動の実行、後処理の3点にのみ集中できます。\n\n\n    ```py\n\n    class BaseSecurityTest(ABC):\n\n        def __init__(self, config = {}, test_id: Optional[str] = None):\n            self.test_id = test_id or str(uuid.uuid4())\n            self.test_name = self.__class__.__name__\n            self.expected_detections = {}\n            self.actor_id = config.get('gitlab', {}).get(\n                'default_actor_id',\n                \"sirt_detection_test_user_\" + self.test_id[:8]\n            )\n            self.isActive = True\n            self.test_run_time = 300\n            self.config = config\n\n        @abstractmethod\n        def setup(self) -> bool:\n            \"\"\"Prepare test environment and resources\"\"\"\n\n        @abstractmethod\n        def execute(self) -> Dict[str, Any]:\n            \"\"\"Execute the malicious behavior simulation\"\"\"\n\n        @abstractmethod\n        def cleanup(self) -> bool:\n            \"\"\"Clean up test environment and resources\"\"\"\n    ```\n\n\n    重要な設定は`expected_detections`ディクショナリです。これは、トリガーが期待されるSIEMのルール名を、アクターIDと期待されるアラート到着時刻にマッピングします。新しいテストは、`tests/`ディレクトリ内に`BaseSecurityTest`をサブクラス化したPythonファイルを作成し、シミュレートする行動を定義して、トリガーが期待される検知を宣言するだけです。テストランナーは次回のスケジュール実行時に自動的にそれを検出します。\n\n\n    この低摩擦なインターフェースが重要なのは、チームが実際にテストを書いてくれなければ、検知テストという取り組み自体が成立しないからです。テストの追加にパイプライン内部の全体像の理解が必要になれば、誰もやらなくなります。setup、execute、cleanupを実装し、期待される検知を宣言するというシンプルな仕様は、WATCHテストを[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)（GitLabのAIアシスタント）との相性を高めます。Duoにベースクラスと「特定のグループから大量のプロジェクトをクローンするテストを作って」「GraphQLを使ってこのプロジェクトのCI変数をすべて取得するテストを作って」「これらのプロジェクトを同じ命名規則にリネームして」といったプロンプトを与えると、Duoはフレームワークに直接プラグインできる動作するWATCHテストをスキャフォールドします。これにより、障壁がさらに下がります。エンジニアは「この検知をテストしたい」という考えから、Duoが実装作業の大半を担った状態で動作するテストまで、一気に進むことができます。\n\n\n    Pro Tip: GitLab Duoをさらに効果的に活用するために、私は[Duo Agent Skills](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/customize/agent_skills/)を活用しました。これは、テストの作成のような定型作業の標準と手順を定義するのに最適です。プロジェクトディレクトリには`skills/WATCH-test-creator`というフォルダがあり、SKILL.mdに優れたテストの条件、使用できるヘルパー関数、プロジェクトの目的が記述されています。上記のようなプロンプトを入力した直後にこのファイルが読み込まれるため、Duoに対して「あなたが何をしているのか、どうやればいいのか」を毎回説明し直す必要がなくなります。何より重要なのは、結果が一貫して高品質になることです。以下はそのファイルの抜粋です。\n\n\n    ````text\n\n    ---\n\n    name: WATCH-test-creator\n\n    description: Create WATCH (Orchestrated Offensive Penetration Simulator) security detection tests that simulate malicious behavior on GitLab infrastructure to validate SIEM detection rules and alerting pipelines.\n\n    ---\n\n\n    ## WATCH Test Creator\n\n\n    You are an expert at writing security detection tests for the WATCH framework. WATCH tests simulate malicious activities on GitLab-owned infrastructure to verify that the SecOps security monitoring stack (Elastic SIEM, Tines SOAR, alerting rules) properly detects and responds to threats.\n\n\n    ### Architecture Overview\n\n    ```\n\n    Project Root\n\n    ├── core/\n\n    │   ├── base_test.py          # Abstract base class all tests inherit from\n\n    │   ├── test_runner.py         # Auto-discovers and executes tests\n\n    │   └── webhook_manager.py     # Tines/SOAR notification integration\n\n    ├── tests/\n\n    │   ├── gitlab/                # GitLab-specific detection tests\n\n    │   └── gcp/                   # GCP-specific detection tests\n\n    ├── utils/\n\n    │   ├── gitlab_helper.py       # GitLab API wrapper (users, projects, tokens, webhooks, OAuth)\n\n    │   └── crypto_utils.py        # Password generation utility\n\n    ├── config/\n\n    │   ├── settings.py            # Config loader (reads YAML + GITLAB_ADMIN_PAT env var)\n\n    │   └── environments/\n\n    │       ├── dev.yaml           # Local GDK config\n\n    │       └── prod.yaml          # Production staging.gitlab.com config\n\n    ├── main.py                    # Entry point with CLI args\n\n    └── detection_status.json      # Test results and detection metadata\n\n    ```\n\n\n    ````\n\n\n    ## テストダッシュボードによる可視性の向上\n\n\n    ![テストダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1777574679/ylrc96iip682sinfg7zi.png)\n\n\n    WATCHはまた、[GitLab Pages](https://docs.gitlab.com/ja-jp/user/project/pages/)を通じて2つのインタラクティブなダッシュボードをデプロイし、チームが検知の健全性をリアルタイムで把握できるようにしています。\n\n\n    * **検知ステータスダッシュボード**は、すべての検知ルールと現在のテスト状況の概要を提供します。各検知の発火回数、現在の合否状態、検知のアクティブ期間といったメトリクスが含まれます。テーブルはフィルタリングとソートが可能で、エンジニアはどの検知に注意が必要かをすぐに特定できます。\n\n    * **テスト実行ダッシュボード**は、テストIDごとにグループ化され、検知カバレッジの内訳を含む個々のテスト実行の詳細なビューを提供します。アラート伝播時間を示すタイムライン可視化も含まれており、テスト実行からアラート到着までの所要時間や、SIEMの対応するアラートへの直接リンクを確認できます。\n\n\n    これらのダッシュボードは、以前は手動でパイプラインログやSIEMクエリを掘り起こして検知の健全性を確認していた作業を置き換えました。\n\n\n    GUARDの他の部分と同様に、WATCHはGitLabをそのプラットフォームとして全面的に活用しています。\n\n\n    * **GitLab CI/CDパイプラインとスケジュールパイプライン**が、週次スケジューリングから実行、ダッシュボードのデプロイまで、テストライフサイクル全体をオーケストレーションします。\n\n    * **パイプラインインプット**により、ステージを個別にトリガーできるため、すべてのテストを再実行することなく、検証ステップだけ、あるいはダッシュボード更新だけを実行することができます。\n\n    * **CI/CD変数**が、TinesおよびGitLabステージング環境へのアクセスに必要なAPIキーを安全に保管します。\n\n    * **GitLab Pages**が、追加のインフラ不要でWATCHダッシュボードをホストします。別途ホスティングの管理も、追加のデプロイツールも必要ありません。\n\n    * テストはGitLabプロジェクト内のPythonファイルに過ぎないため、DaCを通じた検知ルールと同様に、**バージョン管理、マージリクエストレビュー、コードオーナーシップ**の恩恵を受けます。\n\n\n    ## WATCHでプロアクティブな姿勢を維持する\n\n\n    WATCHを構築したことで、チームの検知品質に対する姿勢が事後対応型からプロアクティブ型へと変わりました。WATCH導入以前は、検知の不具合はインシデントが発生して期待されるアラートが届かないときに初めて露見していました。これは、ギャップを発見するには最悪のタイミングです。今では検知の健全性について定期的な更新を受け取ることができ、実際に何かが起きる*前*に不具合を把握できます。新たな検知を開発しても、それが壊れたまま放置されることはないという安心感が生まれました。\n\n\n    WATCHのもうひとつのメリットは、レッドチームがフラッシュオペレーションを実施した際に使用した戦術・技術・手順（TTP）を記録できることです。検知を実装してペンテスト作業の事後分析を行った後、WATCHを使ってそれらの検知を検証するためにTTPを再実行することができます。本質的に、WATCHは検知のアトミックテストを再実行可能なTTPにします。\n\n\n    ## WATCHを試す\n\n\n    SOCを運営しSIEMの検知を頼りに脅威を捕捉しているなら、問うべきは「検知が壊れるかどうか」ではなく、「壊れたときに気づけるかどうか」です。この問いに答えるために商用BASプラットフォームは必要ありません。サンドボックス環境、CI/CDパイプライン、そして攻撃シミュレーションをスクリプト化するためのフレームワークがあれば、大きく前進できます。\n\n\n    [GitLab Ultimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/)に登録して、独自の検知テストフレームワークを構築してみてください。\n  authors:\n    - Evan Baltman\n  updatedDate: 2026-05-01\n  date: 2026-04-30\n  title: GitLab CI/CDとDuoで自動検知テストフレームワークを構築する\n  tags:\n    - security\n    - security research\n    - features\n  description: GitLabのSignals\n    Engineeringチームが構築したWATCHフレームワークを通じて、セキュリティ監視パイプラインを継続的に検証する方法をご紹介します。\n  category: security-labs\nconfig:\n  featured: true\n  template: BlogPost\n  slug: automated-detection-testing-framework\n",{"config":715,"title":716,"description":717,"ogImage":718},{"noIndex":11},"GitLab CI/CDとDuoで検知テストを自動化する","GitLabのSignals Engineingチームが構築したWATCHフレームワークを通じて、セキュリティ監視パイプラインを継続的に検証する方法をご紹介します。セキュリティ運用センター（SOC）の検知品質を維持するための実践的アプローチです。","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1772195014/ooezwusxjl1f7ijfmbvj.webp","ja-jp/blog/automated-detection-testing-framework",[707,721,709],"security-research",[707,708,709],"Rq7jKWDbZ02EuHyO11JSG-qVTLjEJBJffBGn8vH2_10",[725,734],{"content":726,"config":732},{"title":727,"heroImage":728,"category":10,"description":729,"authors":730},"3月のサプライチェーン攻撃から学ぶパイプラインセキュリティ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772630163/akp8ly2mrsfrhsb0liyb.png","2026年3月、Trivy・Checkmarx KICS・LiteLLM・axiosが次々と侵害されました。GitLabの集中管理されたパイプライン実行ポリシーが、これらのサプライチェーン攻撃パターンをどのように検出・ブロックできるかをご紹介します。",[731],"Grant Hickman",{"externalUrl":-1,"slug":733},"pipeline-security-lessons-from-march-supply-chain-incidents",{"content":735,"config":742},{"title":736,"heroImage":737,"category":10,"description":738,"authors":739},"GitLabがnpmサプライチェーンへの大規模攻撃を発見","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665667/Blog/Hero%20Images/built-in-security.jpg","攻撃を引き起こすマルウェアには、ユーザーデータを破壊する「デッドマンスイッチ」が含まれています。",[740,741],"Michael Henriksen","Daniel Abeles",{"externalUrl":-1,"slug":743},"gitlab-discovers-widespread-npm-supply-chain-attack",1777934869674]