Skip to content

Mini projects

General guidelines

Prepare a 5–10 slide deck that documents the key steps you took to reach your solution. The deck should incude the project objective and a brief summary of the solution, followed by a concise description of your methodology and the high-level steps you followed. Include information about data sources, tools, and technologies used, then present the main experiments, their results, and the decisions you made based on those results. Describe the challenges you encountered and how you addressed them, and finish with the final outcome plus next steps or recommendations.

When submitting in moodle, attach the full slide deck (a larger version is acceptable), all code and scripts, any datasets or sample input/output files, and a short README explaining how to run the code and reproduce the results.

It is also ok add a file with a link to an online repository (GitHub/GitLab)

MP1: Build-time SBOM

Goal

Evaluate the differences between SBOMs generated at the different levels of the Supply Chain to understand the potential benefits/drawbacks of build-time SBOMs.

Overview

Build-time SBOMs inspect and analyze the entire build process by inspecting network calls, system calls and files stored. In this project you will compare the different SBOM generation approaches. An example could be:

  1. Pick 2/3 OSS projects implemented with different programming languages
  2. Generate the SBOMs
  3. Compare SBOMs. Check for: Missing dependencies Unexpected components Build/runtime mismatches

Do not focus on OS dependencies (they will not be in the runtime SBOM)

Which tools to use

For directory and container scanning you can use:

The only tool available for runtime SBOM generation is witness.

Expected outcome

We expect there to be differences in the SBOMs in terms of granularity (which type of information can we get out of the SBOM) and findings.

MP2: Software-Composition-Analysis obfuscation

Goal

Understand and discover limitations of SCA tools via Dockerfile analysis.

Overview

We know that SBOM generation using SCA is vulnerable to obfuscation attacks. One can find obfuscation attacks by inspecting the container images or by parsing the Dockerfile. In this project you will search repositories in Github for Dockerfiles whose contents have been modified in such a way that they hide some information.

Whith tools to use / Where to start from

You can start from the container obfuscation benchmark to look at some of the examples of how to obfuscate a Dockerfile. In your project you will start by searching in Github for similar patterns (e.g, RUN rm requirements.txt) an then you can:

  1. Check / Generate the SBOM of the project and see if the removed files are present or not.
  2. Use SAST tools to check if the removed files have known vulnerabilities
  3. Group your findings by type (e.g., OS removal, OSPKG modification, PKG removal/modification, direct URL usage, etc..)

Expected outcome

You will likely find a large number of Dockerfiles that are modified in Github repositories

MP3: Secret scanning

Goal

Compare and evaluate the performance of different secret scanner tools

Overview

Secret leakage is one of the most common initial step of many software supply chain attacks. In this project you will compare some of the most used secret scanners to assess their capabilities.

Whith tools to use / Where to start from

For this project you need two things:

  1. Tools to compare Some examples are:

  2. Example secrets. You can use the leaky-repo project but feel free to include other projects too.

After that, you should compare all the tools against the secrets dataset. Report:

  • True positives
  • False positives
  • False negatives

Expected outcome

Expect to see differences in output and resolution.

MP4: Intent-Based Networking with AI

Goal

Generate Kubernetes network policies from natural language using plain LLMs or agentic workflows.

Overview

This project explores whether AI systems can generate correct and secure Kubernetes NetworkPolicy objects from high-level security intents expressed in natural language.

The workflow combines:

  • Kubernetes application deployment
  • Topology discovery
  • Intent specification
  • AI-assisted policy generation
  • Policy verification and evaluation

The project also investigates the limitations of LLMs when reasoning about real-world service communication patterns and implicit network dependencies or assumptions.

Selecting Applications

Start by choosing Kubernetes applications to deploy and analyze.

You can find Helm charts on Artifact Hub.

To make the environment more realistic, deploy multiple applications simultaneously. This simulates production clusters where several services coexist and interact.

You can also use some well-known test Kubernetes Applications

Increase the Difficulty

Many real-world applications do not explicitly declare all ports or communication paths. To simulate this challenge, you can create custom containers or reuse infrastructure from the network security course materials.

The network security infrastructure has contains container image that can be configured to open arbitrary ports.

Deployment and Initial State Analysis

After selecting the applications:

  1. Deploy the applications into a Kubernetes cluster.
  2. Study the architecture and expected communication flows.
  3. Use KubeSonde to analyze runtime connectivity.

KubeSonde can help identify:

  • Existing communication paths
  • Open ports
  • Service dependencies
  • Potentially reachable endpoints

This produces a baseline connectivity graph before any policies are enforced.

Defining Security Intents

Security intents describe desired communication constraints in natural language.

Example Intents

  • Frontend services cannot access the Internet.
  • Backend services are accessible only internally.
  • Databases must be isolated from external workloads.
  • Monitoring services may scrape metrics endpoints only.
  • Payment services may communicate only with currency and email services.

The intent descriptions serve as input to the LLM or agentic system.

Policy Generation

The goal is to generate Kubernetes NetworkPolicy resources automatically.

Possible Approaches

  • Plain LLM prompting
  • Agentic workflows
  • Tool-augmented reasoning systems

Candidate Systems

  • Claude Code
  • OpenAI models
  • kagent
  • Other Kubernetes-aware agents

Inputs (can use one or more of:)

  • Security intents
  • Connectivity topology
  • Kubernetes manifests
  • Service metadata

Outputs

  • Kubernetes NetworkPolicy YAML definitions
  • Explanations of generated rules
  • Policy assumptions and limitations

Suggested Workflow

  1. Select a Kubernetes application (or multiple).
  2. Deploy the application in a Kubernetes cluster.
  3. Discover the connectivity topology.
  4. Define security intents:

  5. For each intent:

    a. Ask the AI system to generate network policies.

    b. Verify correctness and security properties.

Example Evaluation

Correctness

  • Do the policies enforce the intended restrictions?
  • Are required communication paths preserved?

Over-Permissiveness

  • Are unnecessary connections still allowed?
  • Does the policy violate least-privilege principles?

Strictness

  • Are legitimate communications accidentally blocked?
  • Does the application remain functional?

Intent Alignment

  • Does the generated policy accurately reflect the natural-language intent?

Robustness

  • How well does the AI handle:

  • Missing port declarations

  • Implicit dependencies
  • Multi-service interactions
  • Dynamic workloads

Expected Findings

  • AI systems may generate correct policies for simple architectures.
  • Complex microservice environments are harder to secure.
  • LLMs may over-permit traffic when uncertain.
  • Hidden connections can cause policy breakage.