[{"data":1,"prerenderedAt":517},["ShallowReactive",2],{"/en-us/the-source/authors/josh-lemos/":3,"footer-en-us":34,"the-source-navigation-en-us":342,"the-source-newsletter-en-us":369,"josh-lemos-articles-list-authors-en-us":381,"josh-lemos-articles-list-en-us":412,"josh-lemos-page-categories-en-us":516},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"config":8,"seo":10,"content":12,"type":26,"slug":27,"_id":28,"_type":29,"title":11,"_source":30,"_file":31,"_stem":32,"_extension":33},"/en-us/the-source/authors/josh-lemos","authors",false,"",{"layout":9},"the-source",{"title":11},"Josh Lemos",[13,24],{"componentName":14,"type":14,"componentContent":15},"TheSourceAuthorHero",{"config":16,"name":11,"role":19,"bio":20,"headshot":21},{"gitlabHandle":17,"linkedInProfileUrl":18},"joshlemos","https://www.linkedin.com/in/joshlemos/","Chief Information Security Officer","Josh Lemos is the Chief Information Security Officer at GitLab Inc., where he brings 20 years of experience leading information security teams to his role. He is responsible for establishing and maintaining the enterprise vision, strategy, and program to ensure information assets and technologies are adequately protected, fortifying the Gitlab DevSecOps platform and ensuring the highest level of security for customers.",{"altText":11,"config":22},{"src":23},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463405/f4rqtiecakrekvxfhqar.jpg",{"componentName":25,"type":25},"TheSourceArticlesList","author","josh-lemos","content:en-us:the-source:authors:josh-lemos.yml","yaml","content","en-us/the-source/authors/josh-lemos.yml","en-us/the-source/authors/josh-lemos","yml",{"_path":35,"_dir":36,"_draft":6,"_partial":6,"_locale":7,"data":37,"_id":338,"_type":29,"title":339,"_source":30,"_file":340,"_stem":341,"_extension":33},"/shared/en-us/main-footer","en-us",{"text":38,"source":39,"edit":45,"contribute":50,"config":55,"items":60,"minimal":330},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":40,"config":41},"View page source",{"href":42,"dataGaName":43,"dataGaLocation":44},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":46,"config":47},"Edit this page",{"href":48,"dataGaName":49,"dataGaLocation":44},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":51,"config":52},"Please contribute",{"href":53,"dataGaName":54,"dataGaLocation":44},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":56,"facebook":57,"youtube":58,"linkedin":59},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[61,88,161,229,291],{"title":62,"links":63,"subMenu":69},"Platform",[64],{"text":65,"config":66},"DevSecOps platform",{"href":67,"dataGaName":68,"dataGaLocation":44},"/platform/","devsecops platform",[70],{"title":71,"links":72},"Pricing",[73,78,83],{"text":74,"config":75},"View plans",{"href":76,"dataGaName":77,"dataGaLocation":44},"/pricing/","view plans",{"text":79,"config":80},"Why Premium?",{"href":81,"dataGaName":82,"dataGaLocation":44},"/pricing/premium/","why premium",{"text":84,"config":85},"Why Ultimate?",{"href":86,"dataGaName":87,"dataGaLocation":44},"/pricing/ultimate/","why ultimate",{"title":89,"links":90},"Solutions",[91,96,101,106,111,116,121,126,131,136,141,146,151,156],{"text":92,"config":93},"Digital transformation",{"href":94,"dataGaName":95,"dataGaLocation":44},"/topics/digital-transformation/","digital transformation",{"text":97,"config":98},"Security & Compliance",{"href":99,"dataGaName":100,"dataGaLocation":44},"/solutions/security-compliance/","security & compliance",{"text":102,"config":103},"Automated software delivery",{"href":104,"dataGaName":105,"dataGaLocation":44},"/solutions/delivery-automation/","automated software delivery",{"text":107,"config":108},"Agile development",{"href":109,"dataGaName":110,"dataGaLocation":44},"/solutions/agile-delivery/","agile delivery",{"text":112,"config":113},"Cloud transformation",{"href":114,"dataGaName":115,"dataGaLocation":44},"/topics/cloud-native/","cloud transformation",{"text":117,"config":118},"SCM",{"href":119,"dataGaName":120,"dataGaLocation":44},"/solutions/source-code-management/","source code management",{"text":122,"config":123},"CI/CD",{"href":124,"dataGaName":125,"dataGaLocation":44},"/solutions/continuous-integration/","continuous integration & delivery",{"text":127,"config":128},"Value stream management",{"href":129,"dataGaName":130,"dataGaLocation":44},"/solutions/value-stream-management/","value stream management",{"text":132,"config":133},"GitOps",{"href":134,"dataGaName":135,"dataGaLocation":44},"/solutions/gitops/","gitops",{"text":137,"config":138},"Enterprise",{"href":139,"dataGaName":140,"dataGaLocation":44},"/enterprise/","enterprise",{"text":142,"config":143},"Small business",{"href":144,"dataGaName":145,"dataGaLocation":44},"/small-business/","small business",{"text":147,"config":148},"Public sector",{"href":149,"dataGaName":150,"dataGaLocation":44},"/solutions/public-sector/","public sector",{"text":152,"config":153},"Education",{"href":154,"dataGaName":155,"dataGaLocation":44},"/solutions/education/","education",{"text":157,"config":158},"Financial services",{"href":159,"dataGaName":160,"dataGaLocation":44},"/solutions/finance/","financial services",{"title":162,"links":163},"Resources",[164,169,174,179,184,189,194,199,204,209,214,219,224],{"text":165,"config":166},"Install",{"href":167,"dataGaName":168,"dataGaLocation":44},"/install/","install",{"text":170,"config":171},"Quick start guides",{"href":172,"dataGaName":173,"dataGaLocation":44},"/get-started/","quick setup checklists",{"text":175,"config":176},"Learn",{"href":177,"dataGaName":178,"dataGaLocation":44},"https://university.gitlab.com/","learn",{"text":180,"config":181},"Product documentation",{"href":182,"dataGaName":183,"dataGaLocation":44},"https://docs.gitlab.com/","docs",{"text":185,"config":186},"Blog",{"href":187,"dataGaName":188,"dataGaLocation":44},"/blog/","blog",{"text":190,"config":191},"Customer success stories",{"href":192,"dataGaName":193,"dataGaLocation":44},"/customers/","customer success stories",{"text":195,"config":196},"Remote",{"href":197,"dataGaName":198,"dataGaLocation":44},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":200,"config":201},"GitLab Services",{"href":202,"dataGaName":203,"dataGaLocation":44},"/services/","services",{"text":205,"config":206},"TeamOps",{"href":207,"dataGaName":208,"dataGaLocation":44},"/teamops/","teamops",{"text":210,"config":211},"Community",{"href":212,"dataGaName":213,"dataGaLocation":44},"/community/","community",{"text":215,"config":216},"Forum",{"href":217,"dataGaName":218,"dataGaLocation":44},"https://forum.gitlab.com/","forum",{"text":220,"config":221},"Events",{"href":222,"dataGaName":223,"dataGaLocation":44},"/events/","events",{"text":225,"config":226},"Partners",{"href":227,"dataGaName":228,"dataGaLocation":44},"/partners/","partners",{"title":230,"links":231},"Company",[232,237,242,247,252,257,262,266,271,276,281,286],{"text":233,"config":234},"About",{"href":235,"dataGaName":236,"dataGaLocation":44},"/company/","company",{"text":238,"config":239},"Jobs",{"href":240,"dataGaName":241,"dataGaLocation":44},"/jobs/","jobs",{"text":243,"config":244},"Leadership",{"href":245,"dataGaName":246,"dataGaLocation":44},"/company/team/e-group/","leadership",{"text":248,"config":249},"Team",{"href":250,"dataGaName":251,"dataGaLocation":44},"/company/team/","team",{"text":253,"config":254},"Handbook",{"href":255,"dataGaName":256,"dataGaLocation":44},"https://handbook.gitlab.com/","handbook",{"text":258,"config":259},"Investor relations",{"href":260,"dataGaName":261,"dataGaLocation":44},"https://ir.gitlab.com/","investor relations",{"text":263,"config":264},"Sustainability",{"href":265,"dataGaName":263,"dataGaLocation":44},"/sustainability/",{"text":267,"config":268},"Diversity, inclusion and belonging (DIB)",{"href":269,"dataGaName":270,"dataGaLocation":44},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":272,"config":273},"Trust Center",{"href":274,"dataGaName":275,"dataGaLocation":44},"/security/","trust center",{"text":277,"config":278},"Newsletter",{"href":279,"dataGaName":280,"dataGaLocation":44},"/company/contact/","newsletter",{"text":282,"config":283},"Press",{"href":284,"dataGaName":285,"dataGaLocation":44},"/press/","press",{"text":287,"config":288},"Modern Slavery Transparency Statement",{"href":289,"dataGaName":290,"dataGaLocation":44},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":292,"links":293},"Contact Us",[294,299,304,309,314,319,324],{"text":295,"config":296},"Contact an expert",{"href":297,"dataGaName":298,"dataGaLocation":44},"/sales/","sales",{"text":300,"config":301},"Get help",{"href":302,"dataGaName":303,"dataGaLocation":44},"/support/","get help",{"text":305,"config":306},"Customer portal",{"href":307,"dataGaName":308,"dataGaLocation":44},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"text":310,"config":311},"Status",{"href":312,"dataGaName":313,"dataGaLocation":44},"https://status.gitlab.com/","status",{"text":315,"config":316},"Terms of use",{"href":317,"dataGaName":318,"dataGaLocation":44},"/terms/","terms of use",{"text":320,"config":321},"Privacy statement",{"href":322,"dataGaName":323,"dataGaLocation":44},"/privacy/","privacy statement",{"text":325,"config":326},"Cookie preferences",{"dataGaName":327,"dataGaLocation":44,"id":328,"isOneTrustButton":329},"cookie preferences","ot-sdk-btn",true,{"items":331},[332,334,336],{"text":315,"config":333},{"href":317,"dataGaName":318,"dataGaLocation":44},{"text":320,"config":335},{"href":322,"dataGaName":323,"dataGaLocation":44},{"text":325,"config":337},{"dataGaName":327,"dataGaLocation":44,"id":328,"isOneTrustButton":329},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"_path":343,"_dir":9,"_draft":6,"_partial":6,"_locale":7,"logo":344,"subscribeLink":349,"navItems":353,"_id":365,"_type":29,"title":366,"_source":30,"_file":367,"_stem":368,"_extension":33},"/shared/en-us/the-source/navigation",{"altText":345,"config":346},"the source logo",{"src":347,"href":348},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750191004/t7wz1klfb2kxkezksv9t.svg","/the-source/",{"text":350,"config":351},"Subscribe",{"href":352},"#subscribe",[354,358,361],{"text":355,"config":356},"Artificial Intelligence",{"href":357},"/the-source/ai/",{"text":97,"config":359},{"href":360},"/the-source/security/",{"text":362,"config":363},"Platform & Infrastructure",{"href":364},"/the-source/platform/","content:shared:en-us:the-source:navigation.yml","Navigation","shared/en-us/the-source/navigation.yml","shared/en-us/the-source/navigation",{"_path":370,"_dir":9,"_draft":6,"_partial":6,"_locale":7,"title":371,"description":372,"submitMessage":373,"formData":374,"_id":378,"_type":29,"_source":30,"_file":379,"_stem":380,"_extension":33},"/shared/en-us/the-source/newsletter","The Source Newsletter","Stay updated with insights for the future of software development.","You have successfully signed up for The Source’s newsletter.",{"config":375},{"formId":376,"formName":377,"hideRequiredLabel":329},1077,"thesourcenewsletter","content:shared:en-us:the-source:newsletter.yml","shared/en-us/the-source/newsletter.yml","shared/en-us/the-source/newsletter",{"amanda-rueda":382,"andre-michael-braun":383,"andrew-haschka":384,"ayoub-fandi":385,"bob-stevens":386,"brian-wald":387,"bryan-ross":388,"chandler-gibbons":389,"dave-steer":390,"ddesanto":391,"derek-debellis":392,"emilio-salvador":393,"erika-feldman":394,"george-kichukov":395,"gitlab":396,"grant-hickman":397,"haim-snir":398,"iganbaruch":399,"jlongo":400,"joel-krooswyk":401,"josh-lemos":11,"julie-griffin":402,"kristina-weis":403,"lee-faus":404,"ncregan":405,"rschulman":406,"sabrina-farmer":407,"sandra-gittlen":408,"sharon-gaudin":409,"stephen-walters":410,"taylor-mccaslin":411},"Amanda Rueda","Andre Michael Braun","Andrew Haschka","Ayoub Fandi","Bob Stevens","Brian Wald","Bryan Ross","Chandler Gibbons","Dave Steer","David DeSanto","Derek DeBellis","Emilio Salvador","Erika Feldman","George Kichukov","GitLab","Grant Hickman","Haim Snir","Itzik Gan Baruch","Joseph Longo","Joel Krooswyk","Julie Griffin","Kristina Weis","Lee Faus","Niall Cregan","Robin Schulman","Sabrina Farmer","Sandra Gittlen","Sharon Gaudin","Stephen Walters","Taylor McCaslin",{"allArticles":413,"visibleArticles":515,"showAllBtn":329},[414,461,481],{"_path":415,"_dir":416,"_draft":6,"_partial":6,"_locale":7,"config":417,"seo":421,"content":426,"type":456,"slug":457,"category":416,"_id":458,"_type":29,"title":422,"_source":30,"_file":459,"_stem":460,"_extension":33,"date":427,"description":423,"timeToRead":428,"heroImage":424,"keyTakeaways":429,"articleBody":433,"faq":434},"/en-us/the-source/security/beyond-shift-left-engineering-supply-chain-safety-at-scale","security",{"layout":9,"template":418,"articleType":419,"author":27,"featured":329,"gatedAsset":420,"isHighlighted":6,"authorName":11},"TheSourceArticle","Regular","application-security-in-the-digital-age",{"title":422,"description":423,"ogImage":424,"config":425},"Beyond “shift left”: Engineering supply chain safety at scale","Learn why the traditional “shift left” approach falls short and how supply chain safety can transform your software security approach at scale.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751464122/kxhyozwsjf8ik6ssm3id.jpg",{"ignoreTitleCharLimit":329},{"title":422,"date":427,"description":423,"timeToRead":428,"heroImage":424,"keyTakeaways":429,"articleBody":433,"faq":434},"2025-03-27","3 min read",[430,431,432],"Most DevSecOps implementations are just DevOps with bolted-on security tools. True software supply chain safety requires engineering security directly into development processes, with tools serving as verification rather than primary protection.","Success in software supply chain safety depends on four pillars: infrastructure guardrails, language security features, automated dependency management, and security function abstraction through service mesh.","Align security and development team incentives through shared metrics and security champions. Focus on building systems that make secure development the path of least resistance rather than adding friction.","Your organization has probably already recognized the value of DevSecOps: removing silos between development, security, and operations teams. You’ve integrated security tools into your CI/CD pipeline, developers are scanning their code, and you have a dedicated security team reviewing findings. So why are you still struggling with security vulnerabilities, team burnout, and the constant tension between development velocity and security requirements? The truth is, most DevSecOps implementations today amount to little more than DevOps with security tools bolted on. It’s time to fundamentally change how we approach software supply chain security.\n\n## The promise and reality of the shift left\nThe journey to modern DevSecOps began with good intentions. As organizations moved to the cloud and adopted DevOps practices, security teams attempted to “shift left” by pushing security responsibilities earlier in the development cycle. However, this often meant taking the same noisy security tools - static analysis, dynamic testing, and software composition analysis - and simply making them the developers’ problem.\n\nThe results are predictable: With unrealistic security-to-developer ratios, [security teams are overwhelmed](https://about.gitlab.com/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security/) by the volume of findings from improperly tuned tools. Developers, already under pressure to deliver features quickly, face constant interruptions from release-gating security tools, with unacceptable false positive rates. The promised integration of security into development workflows has instead created new bottlenecks and friction points.\n\n## Why traditional approaches miss the mark\nThe fundamental flaw in many DevSecOps implementations is treating security as an add-on rather than a core platform engineering capability. Organizations implement basic continuous integration practices with security tools attached, but fail to address the underlying challenges:\n\n- Security tools produce overwhelming noise without proper tuning and context\n- Workflow interruptions and governance processes create frustrating slowdowns\n- Security and development teams operate in silos with misaligned incentives\n- Traditional security metrics fail to demonstrate meaningful risk reduction\n\nShifting security left isn’t enough. We need to transform how we think about security entirely.\n\n## Engineering for supply chain safety\nInstead of focusing on security as a state free from threats, we should embrace safety as our guiding principle - creating systems inherently protected from and unlikely to cause danger. **Supply chain safety** means implementing systematic safeguards throughout the software development lifecycle that protect both the code you write and the dependencies you consume. It encompasses everything from the infrastructure your applications run on to the third-party packages you integrate, ensuring that each component is verified, validated, and continuously monitored for potential risks. This approach builds on the success patterns we’ve seen in other areas of software security, like the adoption of memory-safe languages and ubiquitous Transport Layer Security (TLS) encryption.\n\nHere’s how you can implement supply chain safety effectively:\n1. **Infrastructure guardrails**: Leverage [platform engineering](https://about.gitlab.com/the-source/platform/driving-business-results-with-platform-engineering/) to create pre-hardened templates that enforce security controls by default. This ensures teams inherit security best practices without additional cognitive load.\n1. **Language and framework security**: Take advantage of built-in security features in modern programming languages and frameworks. From automated memory management to deserialization filters, these features can prevent entire classes of vulnerabilities.\n1. **Automated dependency management**: Implement dependency proxies that automatically scan, validate, and cache third-party packages. Define clear policies for package verification and maintain a curated list of approved dependencies.\n1. **Security function abstraction**: Use service mesh and security sidecars to handle cross-cutting security concerns like authentication and authorization. This removes the burden of implementing security controls from individual service code.\n\n## Making it work: The human element\nTechnical solutions alone aren’t enough - success requires addressing the human factors that often derail security initiatives. Start by aligning incentives between security and development teams through shared goals and metrics that reward software resiliency improvements. Build a network of security champions within development teams who can act as bridges between security and engineering.\n\nCreate targeted training programs that focus on the security enablement features you’ve built, demonstrating how they reduce operational burden rather than add to it. Regular cross-team collaboration ensures both groups understand and support each other’s needs.\n\n## Moving forward\nThe path to true supply chain safety requires a fundamental shift in approaching security. Instead of bolting on security tools and hoping for the best, [build security directly into your engineering processes and practices](https://about.gitlab.com/the-source/security/strengthen-your-cybersecurity-strategy-with-secure-by-design/). You should layer in security tools for assurance and verification only after establishing strong engineering foundations.\n\nStart by evaluating your current DevSecOps implementation. Are you truly integrating security into your engineering practices, or just adding security tools to your pipeline? Focus first on building the infrastructure and platform capabilities that make secure development the path of least resistance. Remember, the goal isn’t to make developers think more about security - it’s about engineering safety from the ground up to help teams build secure software naturally through well-designed systems and processes.",[435,438,441,444,447,450,453],{"header":436,"content":437},"Why isn’t “shift left” enough to improve software security?","While shifting security earlier in the development cycle is a well-intentioned step, it often results in security tools being handed off to developers without adequate tuning or context. This creates noise, slows workflows, and introduces friction rather than improving safety or resilience.",{"header":439,"content":440},"What’s the difference between software security and software safety?","Security often focuses on reacting to threats, whereas safety is about proactively designing systems that are resistant to risk by default. A safety-driven approach builds protections into the software supply chain from the ground up, not just at the edges.",{"header":442,"content":443},"How does supply chain safety improve developer experience?","Supply chain safety reduces the operational burden on developers by integrating security controls into infrastructure and workflows. Pre-hardened templates, secure-by-default configurations, and abstracted security functions reduce the need for manual intervention.",{"header":445,"content":446},"What role do development frameworks and languages play in this approach?","Modern languages and frameworks offer built-in protections, such as memory management and deserialization controls. Leveraging these features helps eliminate entire categories of vulnerabilities without needing to create custom security logic.",{"header":448,"content":449},"How can organizations reduce risk from third-party dependencies?","Using automated tools like dependency proxies and curated package lists allows teams to validate, scan, and control third-party components. This helps ensure that all integrated packages meet security standards before reaching production.",{"header":451,"content":452},"What is the importance of aligning security and development teams?","Security outcomes improve when both teams share goals, metrics, and mutual understanding. Creating a network of champions and offering enablement training helps foster collaboration and encourages adoption of secure engineering practices.",{"header":454,"content":455},"How can engineering teams get started with supply chain safety?","Begin by assessing your current workflows. Prioritize infrastructure and platform investments that embed security into the development lifecycle. Focus on creating systems that naturally support secure behavior, and use tools to reinforce, not replace, these foundations.","article","beyond-shift-left-engineering-supply-chain-safety-at-scale","content:en-us:the-source:security:beyond-shift-left-engineering-supply-chain-safety-at-scale:index.yml","en-us/the-source/security/beyond-shift-left-engineering-supply-chain-safety-at-scale/index.yml","en-us/the-source/security/beyond-shift-left-engineering-supply-chain-safety-at-scale/index",{"_path":462,"_dir":416,"_draft":6,"_partial":6,"_locale":7,"config":463,"seo":465,"content":469,"type":456,"slug":477,"category":416,"_id":478,"_type":29,"title":466,"_source":30,"_file":479,"_stem":480,"_extension":33,"date":470,"description":467,"timeToRead":471,"heroImage":468,"keyTakeaways":472,"articleBody":476},"/en-us/the-source/security/key-security-trends-for-cisos-in-2025",{"layout":9,"template":418,"articleType":419,"author":27,"featured":6,"gatedAsset":464,"isHighlighted":6,"authorName":11},"source-lp-ai-guide-for-enterprise-leaders-building-the-right-approach",{"title":466,"description":467,"ogImage":468},"Key security trends for CISOs in 2025","Explore essential security trends for 2025: how AI creates new risks and opportunities, reshapes identity management, and strengthens DevOps teams.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751464506/hyue0lgqq2lqk3arwnel.jpg",{"title":466,"date":470,"description":467,"timeToRead":471,"heroImage":468,"keyTakeaways":472,"articleBody":476},"2025-02-25","5 min read",[473,474,475],"AI adoption creates both security risks and opportunities. Organizations must track AI usage in vendor products, prepare for potential outages, and leverage AI to strengthen security controls.","Identity management needs modernization to handle complex machine-to-machine interactions, dynamic permissions, and AI system access, requiring more flexible and adaptive security tools.","AI tools can help bridge the DevOps security skills gap by automating security checks, suggesting secure code patterns, and integrating security throughout the software development lifecycle.","In 2025, many of your critical security tools will include AI models you can’t inspect or fully control. Your board is already asking how you’ll prevent the next headline-making security breach. Meanwhile, your competitors are using AI to automate security at a scale that was impossible just months ago. Evolving regulatory requirements add another layer of complexity, as new rules in the European Union and California affect how you can use AI systems.\n\nThe security landscape is rapidly evolving, but with the right approach, you can harness these challenges to build stronger defenses while protecting against new cyber threats. Here are three trends to prepare for that will dominate the enterprise security landscape this year.\n\n## 1. Vulnerabilities in proprietary LLMs\nMany vendors now use proprietary foundational large language models (LLMs) in their products, creating new risks for your organization. Most of these LLMs are black boxes - you can't see much about how they work or what safety controls they have. Security researchers have demonstrated the fragility of AI guardrails. There is a growing attack surface on the models themselves and reflectively on the products they serve.\n\nSince many products rely on the same few proprietary LLMs, an attack on one could simultaneously affect many of your systems. This concentration of risk is particularly concerning as more critical business functions depend on AI-enabled tools. You’ll need to:\n\n- Track which of your vendors use LLMs\n- Assess the security controls these vendors have in place\n- Plan for possible outages if an LLM-based service fails\n- Develop backup plans for critical AI-dependent systems\n\n> Read more: [7 questions to ask your DevOps provider to build a transparency-first AI strategy](https://about.gitlab.com/the-source/ai/building-a-transparency-first-ai-strategy-7-questions-to-ask-your-devops/)\n\n## 2. Identity management challenges\nCloud and AI systems are changing how we manage access to the systems we use every day. Your identity systems must now handle:\n\n- An increase in non-human, service-based identities\n- More machine-to-machine connections\n- Quick changes in who needs access to what\n- Complex chains of permissions between services\n- AI systems that need varying levels of data access\n\nTraditional identity and access management tools weren’t built for these challenges. You’ll need more flexible identity tools that can adapt quickly as your needs change. Consider implementing [zero-trust principles and just-in-time access](https://about.gitlab.com/the-source/security/field-guide-to-threat-vectors-in-the-software-supply-chain/) to better control these dynamic environments.\n\nSecurity teams should also develop strategies and prepare for the growing complexity of agentic AI with the same level of rigor and auditability they apply to human users. As AI systems proliferate, [tracking and securing these non-human identities](https://about.gitlab.com/blog/improve-ai-security-in-gitlab-with-composite-identities/) becomes just as important as managing human user access.\n\n## 3. Making security work in DevOps\n[In a recent survey](https://about.gitlab.com/developer-survey/), 58% of developers said they feel some degree of responsibility for application security - but finding DevOps staff with security skills remains difficult. AI-powered tools can help by:\n\n- Checking code for security vulnerabilities and potential threats early in development before they cause problems\n- Suggesting secure coding patterns\n- Setting up the right access permissions automatically\n- Automating repetitive tasks throughout the development process\n\nThese tools can help your existing security team work more efficiently. They can also help developers catch common security issues before code reaches production. This means fewer emergencies for your team and better security outcomes overall.\n\nConsider investing in tools that integrate directly into developer workflows. The easier you make it for developers to work securely, the more likely they are to do so.\n\n## Taking action: Embracing AI to secure the threat landscape\nTo stay ahead of these changes:\n\n1. Map out where AI tools touch your systems and assess the risks\n1. Update your identity management approach for cloud and AI needs\n1. Look for ways AI can strengthen your security work\n1. Keep your board informed about new AI risks and regulations\n1. Build relationships with key vendors to understand their AI security measures\n1. Train your team on AI security risks and opportunities\n\nWhile AI brings new risks, it also gives you new tools to protect your organization. Focus on using AI to strengthen your security posture while watching out for new threats. Regular reviews of your AI security stance will help you stay ahead of emerging risks.\n\n## Looking ahead\nThe security landscape will keep evolving as AI technology advances. Stay flexible and ready to adapt your security strategy as new threats and opportunities emerge. Build strong relationships across your organization - especially with legal, development, and operations teams. These partnerships will help you respond more effectively to security challenges.\n\nRemember that while the technology changes, your core mission remains the same: protecting your organization’s assets and enabling secure business operations. Use new tools and approaches where they make sense, but don’t lose sight of security basics in the rush to adopt AI.","key-security-trends-for-cisos-in-2025","content:en-us:the-source:security:key-security-trends-for-cisos-in-2025:index.yml","en-us/the-source/security/key-security-trends-for-cisos-in-2025/index.yml","en-us/the-source/security/key-security-trends-for-cisos-in-2025/index",{"_path":482,"_dir":416,"_draft":6,"_partial":6,"_locale":7,"config":483,"seo":484,"content":488,"type":456,"slug":511,"category":416,"_id":512,"_type":29,"title":485,"_source":30,"_file":513,"_stem":514,"_extension":33,"date":489,"description":486,"timeToRead":471,"heroImage":487,"keyTakeaways":490,"articleBody":494,"faq":495},"/en-us/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security",{"layout":9,"template":418,"articleType":419,"author":27,"featured":329,"gatedAsset":420,"isHighlighted":6,"authorName":11},{"title":485,"description":486,"ogImage":487},"Addressing the root cause of common security frustrations","Security frustrations are often framed as a cultural issue — but leaders also need to focus on issues like tech stack complexity and vulnerability management.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751464489/mragusmxl1wz8ozdaoml.png",{"title":485,"date":489,"description":486,"timeToRead":471,"heroImage":487,"keyTakeaways":490,"articleBody":494,"faq":495},"2024-10-29",[491,492,493],"The shift to authenticated scanning in vulnerability management heightens effectiveness but may divert engineering efforts towards non-critical tasks, creating a division between security and engineering teams.","A minimalist approach to software development can minimize dependencies, reduce scanner noise, and lighten the developer's load, contributing to improved software security.","Adopting a \"paved roads\" approach, which involves tested and assured design patterns based on repeatable use cases, can reduce the burden on engineering teams and increase security.","This year, GitLab’s [annual survey of DevSecOps professionals](https://about.gitlab.com/developer-survey/) uncovered several issues related to organizational culture that could be preventing deeper alignment between engineering and security teams. A majority (58%) of security respondents said they have difficulty getting development to prioritize remediation of vulnerabilities, and 52% reported that red tape often slows their efforts to quickly fix vulnerabilities. In addition, security respondents pointed to several specific frustrations related to their jobs, including difficulty understanding security findings, excessive false positives, and testing happening late in the software development process.\n\n[DevSecOps](/topics/devsecops/) promises better integration between engineering and security, but it’s clear that frustrations and misalignment persist. That’s because these challenges are symptoms of a larger problem with how organizations view security, as well as how teams work together and how they allocate time to security.\n\n## Escaping the vulnerability hamster wheel\n\nVulnerability scanning surfaces all potential vulnerabilities - however, just because a software package has a common vulnerability or exposure (CVE) doesn’t mean it’s reachable or exploitable. Security teams and developers alike are still triaging and filtering through vulnerability findings that have grown exponentially over the years since authenticated vulnerability scanning became the norm.\n\nThe move to authenticated scanning has improved the effectiveness of security programs in many ways, but it’s also put developers on an endless hamster wheel of fixing things that don’t matter. When teams waste their efforts on patches that don’t address an exploitable vulnerability, they are diverted from more critical tasks, such as patching vulnerable and exploitable flaws. That’s the source of much of the division between security and engineering teams today.\n\nSo, how can organizations address the root cause of these issues and promote better integration between engineering and security? Here are three ways to prevent common security frustrations at the source.\n\n### 1. Silence the noise, focus on actionable high-fidelity signals\n\nExcessive false positives were the second highest rated frustration identified by security respondents in our survey. False positives are clearly a challenge, but they are often a vulnerability management problem in disguise.\n\nIf an organization sees many false positives, that could be a sign that they haven’t done all they can to ensure their security findings are high-fidelity. Organizations should narrow the focus of their security efforts to what matters. That means traditional static application security testing (SAST) solutions are likely insufficient. SAST is a powerful tool but loses much of its value if the results are unmanageable or lack appropriate context. For SAST to be most effective, it must be used [seamlessly with other security and development tools and be accessible to developers](https://about.gitlab.com/blog/oxeye-joins-gitlab-to-advance-application-security-capabilities/).\n\nAnother issue is that most scanning tools have a very narrow context window for understanding vulnerability findings. This is one of the areas where AI can help with [AI-powered features that explain security vulnerabilities](https://about.gitlab.com/blog/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/).\n\n### 2. Minimize the tech stack, minimize the attack surface\n\nStaying focused on what matters doesn’t just apply to security testing - it should start with how an organization builds software in the first place.\n\nAlthough AI promises to help simplify software development processes, [our survey suggests that many organizations still have a long road ahead](https://about.gitlab.com/blog/3-surprising-findings-from-our-2024-global-devsecops-survey/). In fact, respondents who are using AI were significantly more likely than those not using AI to want to consolidate their toolchain, suggesting that the proliferation of different point solutions running different AI models could be adding complexity, not taking it away.\n\nThe ever-increasing complexity of organizations’ tech stacks is a major contributor to security frustrations. Some complexity is unavoidable when building large, multi-faceted software systems. However, organizations should take steps to avoid complexity resulting from suboptimal design decisions, such as difficult-to-maintain code and redundant dependencies. This unnecessary complexity creates a larger attack surface and generates more security scan findings for teams to sort through, prioritize, and address.\n\nOrganizations should approach development through the lens of software minimization - that is, being intentional about the tools they adopt and what they decide to build into their codebases. This will help minimize dependencies, improve the security of the software supply chain, reduce scanner noise, and ease the burden on developers to fix non-critical issues.\n\n### 3. Normalize paved roads\n\nSecurity testing happening too late in the software development lifecycle was another one of the top frustrations identified by our survey respondents. Teams might be frustrated when they want to ship something and it gets delayed because a vulnerability is detected late - but in many cases it might not have been possible to detect that vulnerability any earlier. What is possible, however, is operationalizing easily deployable, reusable security components, limiting the variables and potential vulnerabilities.\n\nTeams can avoid late-stage surprises by embracing [tested and assured design patterns based on repeatable use cases](https://about.gitlab.com/the-source/platform/how-devops-and-platform-engineering-turbocharge-efficiency/): the “paved roads” approach. A paved road is a recommended path, including a curated set of tools, processes, and components, that teams can follow to build secure applications more efficiently - for example, using GitOps to version and deploy well-architected and tested Infrastructure as Code that deploys at scale for all workloads.\n\nAdopting paved roads potentially removes some flexibility, but ultimately reduces the operational burden and rework on engineering teams and increases security. This needs to be a collaborative effort between security and development. Security can help to design paved roads, but engineering has to be involved to operate and maintain them as part of the codebase.\n\n## Security is a domain, not a team{class=\"no-anchor\"}\n\nWe’re already seeing security as a practice shift into engineering teams, and we can expect the boundaries between the two to continue to blur. However, with the rapid adoption of AI and the corresponding acceleration of software development - 66% of our survey respondents said they are releasing software twice as fast or faster than last year - it will be critical for organizations to establish systems and frameworks that optimize for the greatest security benefit. That’s why the idea of a cultural disconnect between development and security isn’t the whole story. Fostering a culture of collaboration is essential, but security and engineering teams must also work together to rethink foundational aspects of software development, such as optimizing existing codebases and building scalable engineering-centric solutions that can be seamlessly adopted by technical teams across the organization.",[496,499,502,505,508],{"header":497,"content":498},"What is the “paved roads” approach to security, and why is it effective?","The [\"paved roads\" or \"golden path\" approach](https://about.gitlab.com/the-source/platform/driving-business-results-with-platform-engineering/) standardizes security best practices by providing pre-approved tools, design patterns, and infrastructure configurations that teams can follow. By using reusable, well-tested security components, organizations reduce late-stage security surprises, streamline development, and ensure applications are secure by default. This approach balances flexibility with security assurance.",{"header":500,"content":501},"How does toolchain complexity contribute to security risks?","A fragmented toolchain increases security risks by creating a larger attack surface, introducing redundant dependencies, and making security oversight more difficult. Many organizations are now consolidating their tech stacks to reduce complexity and improve security outcomes. A DevSecOps platform can help unify security, development, and operations, minimizing inefficiencies and reducing security blind spots.",{"header":503,"content":504},"Why is security shifting from a separate team to an engineering practice?","Security is increasingly being embedded within development teams to align with modern DevSecOps practices. As software releases accelerate, security must be built into the development process rather than treated as an afterthought. Organizations that integrate security into engineering workflows — through automation, AI-driven insights, and security-aware coding practices — achieve stronger, more scalable security outcomes.",{"header":506,"content":507},"How can organizations reduce security-related false positives?","False positives can be minimized by refining security testing tools, ensuring they provide actionable and high-confidence findings. AI-powered vulnerability analysis can help contextualize security issues and filter out irrelevant alerts. Additionally, consolidating security tools within a DevSecOps platform can improve accuracy by correlating security data across multiple sources.",{"header":509,"content":510},"Why do security teams struggle to get vulnerabilities prioritized?","Security teams often face challenges in getting vulnerabilities addressed because developers are overwhelmed by excessive security alerts, many of which are false positives. Without clear prioritization, teams waste time fixing non-exploitable issues instead of focusing on critical vulnerabilities. A more efficient approach involves using AI-powered security tools to surface high-fidelity signals and integrating security seamlessly into development workflows.","security-its-more-than-culture-addressing-the-root-cause-of-common-security","content:en-us:the-source:security:security-its-more-than-culture-addressing-the-root-cause-of-common-security:index.yml","en-us/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security/index.yml","en-us/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security/index",[414,461,481],{"ai":355,"platform":362,"security":97},1753733241616]