Home » Security Bloggers Network » CodeSecDays: Insights and Highlights from GitGuardian’s Security Event

CodeSecDays: Insights and Highlights from GitGuardian’s Security Event

by Thomas Segura on June 20, 2024

CodeSecDays: Insights and Highlights from GitGuardian's Security Event

Last week, GitGuardian organized its yearly French security event, CodeSecDays. The event brought together many actors striving to protect digital infrastructures and featured insightful presentations and discussions on cybersecurity challenges and best practices. This article provides a recap of the key highlights from the event.

Securing Digital Supply Chains

Florent Kirchner, the French National Cybersecurity Strategy Coordinator, delivered a compelling talk titled "Securing Digital Supply Chains: Challenges, Strengths, and Opportunities." He emphasized the complexity and interdependence of modern software architectures, which rely heavily on code libraries, open-source components, and online service APIs. Kirchner highlighted the major challenge organizations face in mastering the overall security of these architectures amidst the constant evolution of dependencies.

CodeSecDays: Insights and Highlights from GitGuardian's Security Event — Florent Kirchner, French National Cybersecurity Strategy Coordinator

State of the Threat

Kirchner provided an overview of the evolving threat landscape, citing notable incidents such as the Heartbleed OpenSSL vulnerability in 2012, the Microsoft data leak of 38TB due to a misconfigured Azure bucket in 2023, and the XZ utils compromise in 2024 that resulted from a patient attacker's three years of undercover work. He emphasized the asymmetric nature of the threat, where honest mistakes can lead to an explosion of the attack surface and an increase in attackers' resources to compromise digital infrastructures.

Key Points for Reflection

Kirchner presented four key points for reflection:

Finding the needle in a haystack: Modern infrastructure is incredibly complex, and finding vulnerabilities is akin to realizing subtle inconsistencies in a constantly evolving system.
Security is still largely artisanal: Automated vulnerability scanning is still in its early stages, and ironically, security products themselves are often highly vulnerable.
The need for new tools: Securing immense and critical infrastructures requires a new type of tools.
Regulatory landscape: Regulators are stepping in, with initiatives like the Cyber Resilience Act in Europe and the US national cyber strategy authorizing class actions against digital publishers.

Kirchner concluded by discussing the importance of political impetus in establishing controlled digital technology and the French dynamic in support of European strategic autonomy.

Roundtable Discussion

A roundtable discussion featuring Camille Taste (InfoSec Manager at Kaiko), Nicolas Perraud (CISO at Upflow & SecAtScale), and Eric Fourrier, GitGuardian's CEO, explored the real meaning of "shift left" in a security context. The panelists discussed the evolution of security practices, from focusing on individual lines of code to leveraging techniques for rapid code testing and early detection of vulnerabilities.

The panelists shared insights on the importance of finding a middle ground with shared responsibility and platform engineering, rather than placing the entire responsibility solely on developers. They emphasized the effectiveness of engaging developers through exercises like CTF and pen testing to help them understand the risks, challenges, and levers of secure coding practices.

The discussion also highlighted the importance of providing developers with tools to analyze code, pull requests, and work securely and efficiently. The panelists stressed that alerting without remediation is merely noise if no action can be taken. Eric Fourrier shared GitGuardian's experience of finding 200,000 secrets at a client's organization and the need to prioritize and address the historical backlog of vulnerabilities.

Security & Velocity: Reconciling Your Security Team with the Developers' Pace

In his talk, Kayssar emphasized the distinction between security and control. He used the drinking water treatment industry as a metaphor to illustrate why relying on dams to ensure security is misguided. Just as providing a continuous, secure supply of drinking water requires safeguarding the entire pipeline, Kayssar explained that modern platform engineering allows organizations to build security throughout their software development and delivery pipelines, rather than trying to bolt it on at the end.

Software Supply Chain: Do Companies Have a Good Handle on Their Attack Surface?

Loïc discussed the widespread use of open-source code and the growing risks of sophisticated attacks targeting it. A staggering 80% of code used in production comes from external sources. The latest trends in open-source dependency attacks are particularly concerning, including malicious packages, dependency confusion, and even dependency hallucination by AI tools.

So, how can we trust the open-source dependencies we rely on? The key is to implement concrete, practical measures to safeguard your software supply chain.

End-to-End Secrets Security: Myth or Reality?

Finally, Badr Nass Lahsen and Pierre Lalanne presented the benefits of combining secrets detection with secrets management and the end-to-end security use cases that this enables.

They emphasized the importance for an enterprise to oversee the numerous machine identities and their privileges over software assets, particularly how the secrets underpinning them should be properly managed. They also discussed how to mitigate bad practices such as hard-coding secrets.

Wrapping Up and Next: CodeSecDays Virtual!

CodeSecDays was an incredible opportunity for the French AppSec community to gather and exchange insights, tackle challenges, and discover best practices for securing digital infrastructures. In the wild world of modern software architectures, events like CodeSecDays are essential for sharing knowledge and pushing the limits of what's possible in cybersecurity.

Next up, CodeSecDays is headed your way! On Wednesday, June 26th, industry leaders from Snyk, Docker, CyberArk, Chainguard, CircleCI, and more will join forces with GitGuardian for a full-day event packed with roundtables, fireside chats, and hands-on sessions designed to fortify your code against evolving threats. Check the program and register here now!

Whether you're a veteran developer, cybersecurity enthusiast, or technology decision-maker, this virtual event is your chance to level up your skills and help shape the future of secure software delivery. Don't miss out!

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Code Security for the DevOps generation authored by Thomas Segura. Read the original post at: https://blog.gitguardian.com/codesecdays-france-insights-and-highlights/

June 20, 2024June 20, 2024 Thomas Segura Conferences, GitGuardian

Thomas Segura

What You Need to Scale AppSec Thomas Segura - Content Writer @ GitGuardian Author Bio Thomas has worked both as an analyst and as a software engineer consultant for various big French companies. His passion for tech and open source led him to join GitGuardian as technical content writer. He focuses now on clarifying the transformative changes that cybersecurity and software are going through. Website:https://www.gitguardian.com/ Twitter handle: https://twitter.com/GitGuardian Linkedin: https://www.linkedin.com/company/gitguardian Introduction Security is a dilemma for many leaders. On the one hand, it is largely recognized as an essential feature. On the other hand, it does not drive business. Of course, as we mature, security can become a business enabler. But the roadmap is unclear. With the rise of agile practices, DevOps and the cloud, development timeframes have been considerably compressed, but application security remains essentially the same. DevSecOps emerged as an answer to this dilemma. Its promise consists literally in inserting security principles, practices, and tools into the DevOps activity stream, reducing risk without compromising deliverability. Therefore there is a question that many are asking: why isn't DevSecOps already the norm? As we analyzed in our latest report DevSecOps: Protecting the Modern Software Factory, the answer can be summarized as follows: only by enabling new capacities across Dev, Sec and Ops teams can the culture be changed. This post will help provide a high-level overview of the prerequisite steps needed to scale up application security across departments and enable such capabilities. From requirements to expectations Scaling application security is a company-wide project that requires thorough thinking before an y decision is made. A first-hand requirement is to talk to product and engineering teams to understand the current global AppSec maturity. The objective at this point is to be sure to have a comprehensive understanding of how your products are made (the processes, tools, components, and stacks involved). Mapping development tools and practices will require time to have the best visibility possible. They should include product development practices and the perceived risk awareness/appetite from managers. One of your objectives would be to nudge them so they take into account security in every decision they make for their products, and maybe end up thinking like adversaries. You should be able to derive security requirements from the different perceptual risks you are going to encounter. Your job is to consolidate these into a common set for all applications, setting goals to align the different teams collaborating to build your product(s). Communicating transparently with all relevant stakeholders (CISO, technical security, product owner, and development leads) about goals and expectations is essential to create a common ground for improvement. It will be absolutely necessary to ensure alignment throughout the implementation too. Open and accessible guardrails Guardrails are the cornerstone of security requirements. Their nature and implementation are completely up to the needs of your organization and can be potentially very different from one company to the other (if starting from scratch, look no further than the OWASP Top10). What is most important, however, is that these guardrails are open to the ones that need them. A good example of this would be to centralize a common, security-approved library of open-source components that can be pulled from by any team. Keep users' accessibility and useability as a priority. Designing an AppSec program at scale requires asking “how can we build confidence and visibility with trusted tools in our ecosystem?”. For instance, control gates should never be implemented without considering a break-glass option (“what happens if the control is blocking in an emergency situation?”). State-of-the-art security is to have off-the-shelf secure solutions chosen by the developers, approved by security, and maintained by ops. This will be a big leap forward in preventing vulnerabilities from creeping into source code. It will bring security to the masses at a very low cost (low friction). But to truly scale application security, it would be silly not to use the software engineer's best ally: the continuous integration pipeline. Embed controls in the CI/CD AppSec testing across all development pipelines is the implementation step. If your organization has multiple development teams, it is very likely that different CI/CD pipelines configurations exist in parallel. They may use different tools, or simply define different steps in the build process. This is not a problem per se, but to scale application security, centralization and harmonization are needed. As illustrated in the following example CI/CD pipeline, you can have a lot of security control steps: secrets detection, SAST, artifact signing, access controls, but also container or Infrastructure as Code scanning (not shown in the example) (taken from the DevSecOps whitepaper) The idea is that you can progressively activate more and more control steps, fine-tune the existing ones and scale both horizontally and vertically your “AppSec infrastructure”, at one condition: you need to centralize metrics and controls in a stand-alone platform able to handle the load corresponding to your organization’s size. Security processes can only be automated when you have metrics and proper visibility across your development targets, otherwise, it is just more burden on the AppSec team's shoulders. In turn, metrics and visibility help drive change and provide the spark to ignite a cultural change within your organization. Security ownership shifts to every engineer involved in the delivery process, and each one is able to leverage its own deep (yet partial) knowledge of the system to support the effort. This unlocks a world of possibilities: most security flaws can be treated like regular tickets, rule sets can be optimized for each pipeline based on criticality, capabilities or regulatory compliance, and progress can be tracked (saved time, avoided vulnerabilities etc.). In simpler terms, security can finally move at the DevOps speed. Conclusion Security can’t scale if it’s siloed, and slowing down the development process is no longer an option in a world led by DevOps innovation. The design and implementation of security controls are bound to evolve. In this article, we’ve depicted a high-level overview of the steps to be considered to scale AppSec. This starts with establishing a set of security requirements that involve all the departments, in particular product-related ones. From there it becomes possible to design guardrails to make security truly accessible with a mix of hard and soft gates. By carefully selecting automated detection and remediation that provide visibility and control, you will be laying a solid foundation for a real model of shared responsibility for security. Finally, embedding checks in the CI/CD system can be rolled out in multiple phases to progressively scale your security operations. With automated feedback in place, you can start incrementally adjusting your policies. A centralized platform creates a common interface to facilitate the exchange between application security and developer teams while enforcing processes. It is a huge opportunity to automate and propagate best practices across teams. Developers are empowered to develop faster with more ownership. When security is rethought as a partnership between software-building stakeholders, a flywheel effect can take place: reduced friction leads to better communication and visibility, automating of more best practices, easing the work of each other while improving security with fewer defects. This is how application security will finally be able to scale through continuous improvement.

thomas-segura has 62 posts and counting.See all posts by thomas-segura