Resilient Security and Supply Chain Attacks

Working in software engineering, I have grown increasingly aware of a pervasive issue in our modern programming landscape: the risk of supply chain attacks. To explore the topic, I have decided to build an experimental methodology and a prototype implementation. Constrained Supply Chain Vetting (CSCV) is a method for identifying and mitigating supply chain threats, focusing on accommodating the needs of different business units. At the center of this method lies its ability to prioritize security metrics per the specific requirements of each organizational division. The implementation of the “Pipe Lock” system exemplifies this method.

I envisioned Pipe Lock as a multifaceted security framework, harnessing static, metadata, and dynamic analysis techniques to safeguard the software ecosystems. The primary innovation is the CSCV methodology. Imagine running an organization with diverse units, each with unique priorities and security needs. CSCV works like an adaptable security shield that accommodates these individual requirements, adding a tailored touch to an organization’s security framework.

While conventional security methodologies like Software Composition Analysis (SCA), Static Application Security Testing (SAST), and Dynamic Application Security Testing (DAST) provide valuable insights, CSCV goes one step further. It identifies open-source vulnerabilities and customizes its configuration based on business intelligence. Additionally, Pipe Lock extends its reach to both proprietary and open source code, creating a wider security blanket.

So, how does Pipe Lock work? The static analysis component is like a watchdog, sniffing out known threats in packages, such as cross-site scripting and SQL injection. Then, there’s the dynamic analysis component, which examines packages’ behavior during execution, like a detective observing a suspect. The metadata analysis component provides the context, shedding light on the package’s origin and authors. Last but not least, we have third-party feedback, which essentially crowdsources intelligence, reinforcing the power of our detection mechanisms.

Still, I am aware that no solution is perfect. The Pipe Lock implementation faces the daunting task of detecting ever-evolving supply chain attacks. It also shows limited support for package managers other than RubyGems and programming languages, but I see this as an opportunity for future expansion. There are also ethical implications, such as ensuring the protective measures do not create an intrusive monitoring culture.

The Pipe Lock system is my attempt to provide an additional layer of security in an era where software supply chain attacks are on the rise. As with any experimental project, challenges are part of the journey, but I am eager to learn from them and continuously improve this system. Ultimately, the goal is to create a resilient software ecosystem where creativity thrives without fear of supply chain attacks. Combining static, metadata, dynamic analysis, and other input sources, such as third-party tools, the CSCV methodology identifies and ranks software supply chain risks while accommodating diverse business needs.

Building on related work, such as OWASP Dependency-Check, and Grafeas, Pipe Lock introduces novel features for a customizable solution. Using CUE, an open-source constraint language and API-driven architecture enable integration with many IT systems and real-time adjustments. A possible extension is integrating machine learning techniques, large language models, and natural language processing. Recent lab results and research support the potential of large language models (LLMs) in the context of code security [Large Language Models for Code: Security Hardening and Adversarial Testing]. For instance, the research presents an approach that allows controlled code generation based on a given boolean property, steering program generation toward secure or vulnerable code. By leveraging similar approaches, the Pipe Lock system could analyze code comments and documentation using large language models, revealing hidden discrepancies between the code and its description.

A Deep Dive into Linux with man7 Expert Training

Over the past few months, I had the privilege to immerse myself in Linux expert training. Guided by the expertise of Michael Kerrisk, the author of The Linux Programming Interface, I coded and philosophized my way through the first principles of the Linux world.

The first training involved the operating system architecture and low-level interfaces needed to build Linux-based systems. The five-day intensive training was an excellent opportunity to dive deep into the power of epoll, signals, Linux APIs, and multiple practical use cases, such as implementing non-blocking servers with an efficient thread count.

The second training was a journey into the depths of low-level Linux privileged applications and containers, virtualization, and sandboxing. By the end of this training, I could review Docker’s and Podman’s architecture decisions with detailed arguments (that daemon!). This intensive, four-day course was a real eye-opener. Before it, and as an example, I thought I had a low-level understanding of Linux capabilities or the UTS namespace. However, Michael’s training offered many new insights into the principles behind these features. One of the course’s highlights was building containers from scratch after understanding the workings of namespaces, cgroups, seccomp, and more.

Moreover, students get access to highly technical material and practical exercises, primarily written in C and Go but all languages that implement the relative operating system interfaces can be used. The labs were a hands-on experience, allowing me to apply the knowledge from the training and the book The Linux Programming Interface to real-world instances (spoiler: buffering is a key concept).

Completing the material on a native Linux installation or a VM solution that allows kernel settings adjustments is highly recommended but optional. I used Ubuntu 23, and VirtualBox served me well, especially for the cgroup sections.

I can’t thank Michael Kerrisk enough for this exceptional training. His book, The Linux Programming Interface, and his guidance have significantly improved my understanding and skills in Linux. I highly recommend the trainings for anyone interested in security, containers, systems programming, or any combination of these (