Resilient Security and Supply Chain Attacks

Software supply chain attacks have become an increasingly common source of risk in modern software systems. To explore mitigation strategies, I developed an experimental methodology and prototype focused on identifying and prioritizing supply chain threats while accounting for differing security requirements across organizational units.

A central premise of this work is that supply chain risk should not be evaluated uniformly across an organization. Different teams and products operate under distinct constraints, risk tolerances, and business impacts. To address this, security policies and risk thresholds are defined using CUE, an open-source constraint language, enabling declarative, fine-grained control over how risk signals are evaluated and enforced per organizational unit.

The system combines multiple analysis techniques to assess both open-source and proprietary dependencies:

Static analysis detects known vulnerability patterns and suspicious constructs in dependencies, such as unsafe APIs and injection primitives.

Dynamic analysis monitors runtime behavior to identify anomalous actions, including unexpected network activity or filesystem access.

Metadata analysis evaluates dependency provenance, maintainer history, release cadence, and repository signals.

External intelligence sources incorporate vulnerability databases and community-driven indicators.

Outputs from these components are aggregated and evaluated against CUE-defined constraints rather than fixed global rules. This allows risk scoring and enforcement decisions to be adjusted dynamically based on business context, such as deployment environment, data sensitivity, or regulatory requirements.

The current implementation focuses on a limited set of languages and package managers to enable controlled experimentation. Expanding ecosystem support and improving detection of novel or rapidly evolving attacks remain open challenges. Ethical considerations, particularly around runtime monitoring and developer trust, must also be addressed to avoid overly intrusive security controls.

This work builds on existing systems such as OWASP Dependency-Check and Grafeas, but differs in its use of constraint-based policy evaluation and an API-driven architecture designed for integration with CI/CD pipelines and governance systems. Because policies are expressed declaratively in CUE, they can be validated, composed, and updated in real time without redeploying analysis components.

As a possible extension, machine learning and large language models could be incorporated as supplementary analysis signals. Recent research suggests that language models can reason about code security properties and inconsistencies. In this context, they could be used to analyze code comments and documentation for mismatches between stated intent and observed behavior, providing additional input to the constraint evaluation layer.

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 (https://man7.org/training/).

Man In The Middle in SCADA network

The SCADA acronym stands for supervisory control and data acquisition. A SCADA system, is a collection of different software and hardware components that are connected through a network. The system includes inputs and sensors, PLCS and Remote terminal units and different human machine interfaces.

A SCADA system can use communication systems over TCP, for example the IEC 104 protocol. That protocol like DNP3 does not come with the authentication and packet verification batteries included. This means it’s probably vulnerable to man in the middle attacks (hint: it is).

How would a man in the middle attack look like in such a network? We are mostly familiar with such attacks for web communications like for example we know about man in the middle attacks when a user logs into their bank web admin using an untrusted network. A man in the middle attack works similarly for SCADA systems.

Let’s suppose we have an electrical grid which uses some remote transfer units. Now let’s suppose one of these RTUs detects a faulty condition and wants to communicate the condition back to the main SCADA servers. This communication is vulnerable when it’s being done over MODBUS, DNP3 or IEC 104. An attacker with enough domain knowledge will intercept the communication and will be able to modify crucial data.

For example if the communication is over TCP with IEC 104, an attacker can intercept 104 packets, modify the SPI (status) field of one packet and then route it back to the SCADA servers. This can lead to hiding the problem from the engineers and could lead eventually to economical loss or damage to the company’s image.

tshark and tcpdump

Occasionally we work with interesting network bugs or we want to learn more about how our service behaves outside of the application layer. Two tools that help me in those occasions are tshark and tcpdump.

Installation

Let’s assume we work on a unix system. Then to install tcpdump we simple execute:

$ apt install tcpdump

Installing tshark is simple too:

$ apt install libcap2-bin tshark

Example API

As a demonstration, we are going to utilize a clean and small Sinatra server. For this example a working Ruby installation is required. See the official docs on how to install Ruby properly on a local machine: https://www.ruby-lang.org/en/documentation/installation/

Going back to our example, first, create the repo:

$ mkdir booklist && cd booklist

Install sinatra:

$ gem install sinatra

Create the example API:

$ cat server.rb

require 'sinatra'
require 'json'

get '/' do
["pragmatic programmer", "clean code"].to_json
end

Fire up the server:

$ ruby server.rb

== Sinatra (v2.0.4) has taken the stage on 4567 for development with backup from Puma
Puma starting in single mode...
* Version 3.12.0 (ruby 2.4.0-p0), codename: Llamas in Pajamas
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://localhost:4567
Use Ctrl-C to stop

It works:

$ curl -X GET localhost:4567 | jq .

[
"pragmatic programmer",
"clean code"
]

tcpdump

tcpdump is available on most unix systems, so we can use it on a small remote sever where tshark would be most probably an overkill. It provides decoding so we can investigate how our services interact with the network.

We will work with the lo interface for this example:

$ tcpdump -D

Execute:

$ sudo tcpdump -i lo -A

Hit the service:

$ curl -X GET localhost:4567

Now notice that tcpdump has captured the traffic:

HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Length: 37

["pragmatic programmer","clean code"]

tshark

tshark is a powerful sniffer with many filters which can decode traffic and provides tools for running more complex analysis on it.

tshark can behave exactly like tcpdump:

$ tshark -i lo --color

Depending on the problem, the best solution may be to combine the powers of these tools. A usual case is to create a file with captured decoded traffic with tcpdump and then run analysis on the file with tshark. Or just do both with tshark.

Let’s explore how to do this on the previous example.

Capture the traffic to a packet capture(pcap) file:

$ touch dump
$ tshark -i lo -w dump.pcap

Analyze it:

$ tshark -r dump.pcap

For example, HTTP analysis:

$ tshark -r dump.pcap -Y http.request -T fields -e http.host -e http.user_agent | sort | uniq -c | sort -n

We could also use wireshark for the last step which provides a nice GUI.

Outro

Learning more about these tools has helped me analyze and research solutions on more complicated problems, which in turn help me grow as an engineer and problem solver. Some good references for learning more about these tools are:

1) tutorial: https://danielmiessler.com/study/tcpdump/
2) how tcp works: https://medium.com/@eranda/analyze-tcp-dumps-a089c2644f19
3) book: https://www.goodreads.com/book/show/505564.The_TCP_IP_Guide