SOSS Community Day India

In this session, I will demonstrate how to build security into the DNA of your open source project from day one, using industry-tested tools and automation. You'll learn how to implement a comprehensive security strategy leveraging popular open source security tools including GitHub's CodeQL for advanced vulnerability detection, OpenSSF Scorecard for automated security best practices assessment, and key supply chain security frameworks. Through live demonstrations, we'll walk through setting up automated security scanning pipelines that catch vulnerabilities early and maintain high security standards without burdening developers.

Growth of software supply chain attacks has propelled a deeper look into security of CI/CD. Build environments are prone to secrets/sensitive data exfiltration attacks. Covering here, the learnings around building BOLT(https://github.com/koalalab-inc/bolt), an Open-source tool which secure CI runtime(For GitHub Actions). Taking inspiration from Runtime security, enabling a firewall on buildtime/CI runtime(Egress-filter as CI is a traffic source) should be good start. Complexity 1: IP-based rules won't work. A lot of internet traffic is behind CDNs/WAFs, so egress-filter will require domain-name based filtering. Complexity 2: CI runtime has outbound traffic to multi-tenant systems like github/dockerhub/jfrog etc. This demands deep SSL based inspection capabilities in egress control. Solution: TLS interception+eBPF Linux kernel supports eBPF which provides a way to tap into SSL traffic without the need to decrypt traffic. Such a solution does not add any overhead for developers and is efficient. Covering implementation complexity of eBPF probing for various different kind of SSL libraries to make the solution comprehensive for all kinds of CI pipelines.

The Software Supply Chain encompasses all components, libraries, tools, systems, and processes involved in a software artifact. To support effective risk management and to reduce attack vector while creating a software artifact, SBOM (Software Bill Of Materials) and VEX (Vulnerability Exploitability eXchange) documents can be used. An SBOM is a comprehensive list that details all components, libraries, and dependencies within a software package. Meanwhile, VEX serves as a communication standard for vulnerabilities in a software component. Correlating SBOM and VEX data enables to choose high-quality components and ultimately reducing the attack vectors. In this session, we will discuss the significance of SBOM (Software Bill of Materials) and VEX (Vulnerability Exploitability eXchange) documents to mitigate the dependency threats. Additionally, we’ll look at how trustification.io (a foundation of the Red Hat Trusted Profile Analyzer) provides developers with easy access to curated builds and hardened open-source libraries that have been verified and attested through provenance checks. Open Source Project: Trustify (https://github.com/trustification/trustify)

Containers have revolutionised SDLC but we still build them on Linux distributions designed for physical/virtual machines. The mismatch between single-process containers and full-system distros creates security risks. Minimal base containers are the solution, building them presents unique challenges & this talk presents suggestion around common problems building Secure base containers 1. Container-first Design: a. Traditional distros mark packages(like shell & coreutils) as essential based on machine runtime but real world containers don’t need that. b. Implement installation scripts to avoid unnecessary dependencies 2. Container build enhancements: a. Creating FROM SCRATCH images is tough, bootstrapping with package manager leads to cyclic or installation script dependencies. b. Support for rapid rebuild cycles. 3. Metadata framework: a. Current minimisation approaches miss out on metadata causing container scanning mismatches 4. Porting existing packages: a. The universe covered by existing distros is vast. it makes sense to create tools to transform those packages into self contained binaries that don’t require any package outside of runtime dependencies

The rise of open-source large language models (LLMs) like GPT, BERT, and T5 has greatly enhanced natural language processing. However, these models face significant security challenges due to their vulnerability to adversarial attacks. This abstract examines the susceptibility of open-source LLMs to OWASP Top 10 risks, including model inversion, data poisoning, insecure deployment, and adversarial examples. While open-source LLMs democratize AI, their transparent architecture can expose sensitive data. Model inversion can extract proprietary information, and data poisoning can corrupt outputs with malicious data. Insecure deployment without encryption or authentication leads to data breaches, while adversarial examples exploit model weaknesses. To strengthen these models, implementing differential privacy, adversarial training, and rigorous data validation is crucial. Adopting security best practices, such as penetration testing and real-time monitoring, along with fostering a security-aware community, is essential. By addressing these vulnerabilities, organizations can enhance the robustness and security of open-source LLMs, ensuring safe deployment and trust in AI applications.