Oscar's Blog

Launching SEMCL.ONE: Community-Driven Software Composition Analysis

Thu, 15 Jan 2026 00:00:00 +0000

After years of building compliance automation inside large organizations, I kept running into the same problem: the tools that exist are either too expensive, too rigid, or too disconnected from how software is actually built today.

So I built something different.

What is SEMCL.ONE?

SEMCL.ONE is a community-driven Software Composition Analysis platform. It combines open-source tools, shared infrastructure, and AI automation to make compliance management accessible and scalable.

The core idea is simple: compliance should be automated, not manual.

That means detection, analysis, validation, reporting, and continuous monitoring—all flowing through your development pipeline without constant human intervention.

Why now?

Traditional SCA tools were built for a world where developers copied libraries from known sources. But that world is changing fast. AI-generated code doesn’t always match existing packages. It transforms, adapts, and creates variations that slip past hash-based detection.

What’s inside?

The platform includes several specialized tools:

PURL2SRC & SRC2PURL — Convert between package identifiers and source code across 13+ ecosystems
OSSLILI — License detection supporting 700+ SPDX identifiers with multiple detection methods
Semantic CopyCat — Advanced IP contamination detection targeting AI-generated code transformations
MCP-SEMCLONE — IDE integration that brings conversational compliance to AI assistants like Cursor, Cline, and VS Code
OSPAC — Policy engine with 712 licenses and compatibility checking

Some tools are production-ready. Others are still in development. The project is about 79% complete, with OSSLILI, OSPAC, UPMEX, and MCP-SEMCLONE already live.

Community-driven by design

This isn’t a closed product. Everything is open source. The reference databases are community-contributed. The output formats follow industry standards—SPDX, PURL, CycloneDX.

If you want to contribute, there’s room for everything: bug reports, feature suggestions, code, documentation, detection patterns. The goal is to build something that works for everyone, not just those who can afford enterprise licenses.

Why I’m doing this

SEMCL.ONE is compliance automation built on agentic AI principles, designed for the way software is actually written today.

If you’re working on open source compliance, software supply chain security, or just curious about what AI-powered SCA looks like, come check it out.

Join the community

The views expressed in this document are solely my own and do not represent those of my current or past employers. If you identify an error, please contact me, and I will make the necessary updates.

How to Use AI Without Wasting Time and Money

Tue, 18 Nov 2025 00:00:00 +0000

After thinking about it for a long time (very long time), I realized the “AI problem” isn’t new. It’s the same old problem we’ve seen in software for decades.

AI gives you extra capacity. It speeds up your work, helps you move from an idea to a quick demo or a basic product, and reduces the time between each step. But the same speed also increases the number of mistakes. If your process was unclear before, AI will spread that confusion across every step.

Most AI projects don’t fall apart because the tech is weak. The tech is here. Many projects fall apart for the same reasons teams have failed with past tools:

No training
No real understanding of the tool
Trying to solve the wrong problem
False expectations pushed by hype

People expect AI to work like magic. They feed it missing context, unclear goals, or random data and expect it to “figure it out.” That never works.

Still, every misstep teaches you something. Every prompt that doesn’t work tells you what you misunderstood. And every rough draft helps you shape your thinking. These are the lessons that helped me the most while building with AI.

1. Learn the basics before putting AI into real work

You don’t need deep technical knowledge, but you should still understand a few core ideas. It helps to know what a prompt is, what makes one clear or vague, and why the model reacts the way it does. It also helps to understand what RAG means, when it helps, and when it is unnecessary. The same goes for agents. A little preparation goes a long way, and skipping this early learning step usually leads to wasted money, wasted time, and a lot of confusion.

2. Expect AI to be wrong, and expect yourself to be wrong too

You’ll get more value out of AI if you treat it as a partner that challenges your thinking instead of a tool that writes perfect answers. When you write a draft, try asking the model whether your argument actually addresses the real problem. Ask whether your reasoning makes sense and whether you’re overlooking something important. This works much better than simply asking it to clean up grammar. You get clarity, not just pretty text.

3. Keep AI systems small

Large AI systems with too many features usually collapse under their own weight. They lose context, take too long to build, and fail quietly. Smaller projects do the opposite. A small, clear use case gives you fast results, shows you where the gaps are, and helps you stay focused. The most helpful AI tools are the simple ones that solve a real problem someone faces every day.

4. Build simple versions first and release them quickly

Classic software cycles move slowly, and AI work moves fast. If you wait months to ship something, the idea is already old. It’s far better to release a simple version, try it, fix what breaks, and release the next version soon after. When you don’t release small pieces, you end up working hard without making any real progress, as if you were pushing the brake and the gas at the same time.

5. AI does not know your goals

A model does not understand how your business works, what matters to you, or how you make decisions. You have to teach it. This is a good opportunity to map your own work. When you write down your process, your rules, and what a good outcome looks like, you not only help the model but you help yourself. Clear context always produces better results than any prompt trick.

6. Do not replace people or processes

AI should support the way people work, not erase it. It can help you draft early versions of documents, sort information, pull out key ideas, and record recurring steps so you can turn them into playbooks. But people should still make decisions. And before you connect an AI system to anything serious, especially a production database, stop and think about what could go wrong. Treat this as a risk question, not a convenience question.

7. If you plan to use AI in your business, define a risk model

Different AI systems carry different levels of risk. A simple text classifier is not the same as a model that writes code. And a local model that stays within your network is not the same as a frontier model with broad reach. One way to think about this is to divide systems into several levels. At the lowest level, the concerns look similar to the usual software supply chain issues teams already understand. The next level might include smaller text tasks or basic predictions. Beyond that are systems that can produce code or guide decisions. At the top are advanced models with broad behavior and harder-to-predict outcomes.

As you move up each level, you should raise the bar for security, testing, documentation, deployment limits, and monitoring. This keeps you from treating every AI system as if it all carries the same weight.

8. Start small and grow from there

If you prefer workflows that behave predictably and only pull AI in as a helper, take a look at Strands Agents. When combined with a local Ollama setup, it lets you experiment without sending your data anywhere. It even works well when you’re offline on a plane. Once you’re comfortable, you can shift to cloud providers or bigger systems later.

Final thought

AI is just a tool. When it breaks, it’s almost always because the person asked the wrong thing, used the wrong tool, or started with a problem that wasn’t defined in the first place. Start small. Move fast. Give the model the information it needs. And make sure the thing you’re trying to solve is real.

Have fun with AI, but stay grounded. Focus your time and money on the parts that give you results now, and grow from there.

BSA Security Scanning tool for AI Models

Fri, 15 Aug 2025 00:00:00 +0000

Six months ago, I wrote about the massive security blind spot in AI adoption. Organizations download ML models from the internet. They deploy them in production. They trust them completely.

The response was overwhelming. Security teams reached out, asking the same question: “How do we scan these models?”

The truth was uncomfortable. No existing tools could do it properly.

The Problem is Real

A quick internet search reveals that over 60% of HuggingFace models lack license information. Traditional security scanners miss pickle files entirely. Supply chain attacks, such as PoisonGPT and the PyTorch compromise, have proven that a threat exists.

However, pointing out problems without solutions felt incomplete, and even a proof-of-concept tool could make a significant difference when the gap is enormous.

A Security Scanner for AI Models

I spent the last weeks extending BinarySniffer (an existing project I use for Binary Static Analysis of Linux Packages, firmware, and Mobile Apps) with ML security capabilities (file parsing, signature matching, reporting, etc).

The tool does what I wished existed when I wrote that first post. It analyzes ML models without executing them. It understands pickle files, PyTorch models, ONNX formats, and SafeTensors. It maps threats to MITRE ATT&CK frameworks to produce “features” that later match with signatures that I can generate using an AI Agent. Most importantly, it catches real attacks.

Testing Against Real Threats

I validated the tool against every known ML attack I could find. Results speak louder than marketing claims. 100% detection rate on malicious pickle exploits. Detects command execution patterns used in supply chain attacks. 94% confidence in detecting PyTorch model threats and 56% confidence in identifying suspicious XGBoost models. All of that can be achieved using simple string searching and signatures, which is pretty cool for a proof-of-concept approach.

The tool identified over 50 different attack patterns across various ML formats, but it’s not perfect. The tool is a proof-of-concept that makes progress but requires significantly more time to address the necessary features.

Making It Practical

The implementation is straightforward. You need to “pip it” and use it. Signatures and calibration will happen automatically as you use it:

pip install semantic-copycat-binarysniffer
binarysniffer ml-scan suspicious_model.pkl

The output integrates with GitHub Actions. It generates SARIF reports for CI/CD pipelines. Therefore, security teams can obtain actionable intelligence that they can act on immediately or execute on demand. The tool can also be integrated as a Python Library into another system. Simple as it gets.

What This Means for Your Organization

Every organization adopting AI faces the same choice. Wait for the first ML supply chain attack to hit your systems. Or start scanning your models today, and share your experience with others so we can improve tooling and research.

BinarySniffer is Open Source under Apache-2.0 and available on GitHub. Feel free to submit comments, recommendations, examples, new signatures, and even feature requests.

What it catches: Basic attacks, known malware patterns, unobfuscated pickle exploits, and obvious command injection attempts. What it misses: Sophisticated obfuscation, weight-based backdoors, novel attack patterns, and steganographic payloads. Think of it as your first line of defense, not a complete solution.

Moving Forward

The question isn’t whether ML supply chain attacks will happen. They already are. The question is whether your organization will be protected when the next one hits. Don’t wait to find out; you don’t need to use this tool. You can use any tool that works for your use case. However, the time to start doing something is today.

I welcome ideas to improve scanners or produce proof-of-concept tools. Many more are coming after this one.

Reference:

Pepe, F., et al. (2024). “How do Hugging Face Models Document Datasets, Bias, and Licenses? An Empirical Study.” 32nd IEEE/ACM International Conference on Program Comprehension (ICPC). https://mdipenta.github.io/files/icpc2024.pdf

Beyond Simple Code Scanning: Advanced Semantic Analysis for AI-Generated Code Compliance

Sat, 02 Aug 2025 00:00:00 +0000

When Code Scanners Miss the Forest for the Trees

The rise of AI-powered coding tools is creating a new kind of compliance risk that most organizations are not prepared for.

These tools offer remarkable productivity gains, but they also introduce subtle and serious challenges. License violations, patent exposure, and unauthorized reproduction of proprietary algorithms can now happen without direct copying. Traditional code scanners are not equipped to detect these risks.

The Growing Challenge of AI Code Compliance

Most current scanners rely on pattern matching, hashing, and surface-level similarity. This works for detecting direct reuse, but not for transformed, translated, or restructured code.

For example, an AI system might generate an audio or video codec that implements patented algorithms. Even though the code looks different (using new names, structures, or even languages), the core logic may still be the same. This can lead to intellectual property violations without any obvious sign of duplication.

Why Traditional Scanners Fall Short

Transformation blindness

AI-generated code is rarely copied directly. Instead, it often rewrites logic in a different style, language, or structure. For example, a quicksort algorithm written in Python using list comprehensions may appear entirely distinct from one written in Java with traditional for loops, even though they perform the same task.

Modern software projects frequently span multiple languages. An algorithm might start in Python during prototyping and later be implemented in Rust or Java for production. Most scanning tools are not equipped to follow this kind of transformation, which is understandable, since they were never designed to do so.

Pattern convergence

AI models can recreate functional equivalents of proprietary code without ever directly accessing the original code. This kind of convergence introduces risk, even when no exact code has been copied. In most cases, the developer is completely unaware that their generated code may resemble or replicate protected logic.

What Kind of Tools Are Needed

Scanning code to extract evidence and understand transformations is possible, but not easy. To meet this challenge, organizations need code analysis systems that can:

Recognize algorithmic similarity across different programming languages
Understand semantic equivalence despite style or syntax changes.
Identify core logic based on structure and behavior.
Remain effective even after variable renaming, code reordering, or formatting changes.

The problem requires a deeper understanding of the code’s logic and intent, not just its appearance. It may not appeal to everyone, but for old dinosaurs like me who enjoy technical puzzles and the thrill of discovering (or creating new problems), it is worth spending time exploring.

Research Project: Semantic Code Analysis

As part of a side research project, I developed a prototype system that analyzes the meaning behind code. The goal was to explore whether semantic similarity detection could uncover hidden risks in AI-generated code.

The Scenario

Over 1,000 AI-generated code samples
Five languages: Python, Java, JavaScript, TypeScript, and C
Algorithms included sorting, search, compression, and multimedia codecs.
Each code sample was transformed through:

Only the generated output was evaluated, completely isolated from any training data. I used publicly available generic LLMs, so I had no control over the content they produced.

The challenge required designing a new mechanism and algorithm to support decomposition and analysis. I built a kind of “salad” using components from various Open Source tools and code analysis techniques. While I cannot share many details about the implementation, here is what I discovered:

Key Results

Transformation resistance

The new similarity mechanism detected a similarity range of 53 to 72 percent across transformed versions. It was designed to identify AI-generated reimplementations across different languages, coding styles, and workflows. In comparison, traditional hash-based tools detected only between 0% and 15%.

Cross-language detection

Python to Java implementations showed 53.5 percent similarity.
Shared algorithmic patterns resulted in a 73.3 percent overlap.
Function purpose matching reached 66.7 percent accuracy.

Pattern recognition

Sorting algorithms were identified across all five languages.
Mathematical operations were detected even when expressed in different ways.
Control flow and logic were recognized despite variations in syntax.

The results suggested that it might be possible to detect similarities between existing code, such as a proprietary codec, and unintentionally created AI-generated reimplementations. Based on that, I decided to apply the method to a real-world case and attempt to uncover potential reimplementations.

Case Study: Real-World Codec Analysis

To further test the approach, I used different publicly available LLMs to generate source code for audio codec implementations that could infringe on existing patents. The goal was to evaluate how the system performs when analyzing unknown code across multiple programming languages and to measure semantic similarity. Due to licensing restrictions, I am unable to share the exact code that was generated.

Additionally, I reimplemented some well-known algorithms used by commercial code scanners to benchmark their performance in the same scenarios. I recreated these algorithms using only public documentation, so the results may differ from those produced by proprietary tools.

What worked

Detected similar audio compression algorithms in both Python and Java
Identified MDCT (Modified Discrete Cosine Transform) logic regardless of language or library
Recognized Huffman coding, windowing, and frame-processing logic
Maintained reliability despite differences in naming, libraries, and language paradigms

What was challenging

Pattern matching mismatches reduced confidence in some cases. For example, masking thresholds in Java and psychoacoustic_model in Python referred to the same concept but used different terminology.
Library abstraction levels also presented challenges. High-level libraries required different detection strategies, which were too complex to fully resolve in a short timeframe.
Language-specific idioms added noise to the analysis, necessitating normalization and fine-tuning. This is where most of the meaningful work took place, and where the real value of the approach began to emerge.

Real-World Impact

In the codec analysis:

The Python version showed 28.6 percent similarity with known codecs
The Java version showed a zero percent match using traditional tools
Cross-language semantic similarity confirmed the presence of equivalent compression logic at 53.5 percent

This confirmed that surface-level scanners would have missed the intellectual property risk entirely, while the multi-tier analysis mechanism was able to detect it successfully.

Statistical Highlights

Analysis across 2,320 samples (464 algorithms in 5 languages):

Detection accuracy reached over 85 percent
Cross-language similarity averaged between 53 and 72 percent
False positives remained under 5 percent
Detection held strong even with:

Broader Applications

This kind of semantic analysis is valuable for much more than compliance. It can support:

Internal code clone detection across large codebases
Competitive algorithm analysis
Open source license compliance when derivative work is involved (the new legal challenge?)
Validation of originality in AI-generated code

As generative coding systems become more advanced, organizations may need analysis tools that match that level of complexity. The question is, do such tools already exist?

Final Thoughts

Traditional scanners are built to catch copied code. However, AI does not simply copy, it reconstructs, transforms, and reimplements.

To detect risks, we must analyze the code’s meaning, not just its appearance. This research shows that semantic detection is both possible and practical. It provides better insight, stronger compliance, and a deeper understanding of the algorithms behind the code.

The future of compliance lies in semantic understanding, not superficial matching. It may be time to implement “vibe compliance” to hunt code copycats. Then again, that might open a Pandora’s box.

This research was conducted independently. All code used for testing was explicitly generated for experimental purposes and was not sourced from any known proprietary dataset. I used generic, publicly available LLMs and did not use models whose creators claim to have excluded copyleft or other problematic code from their training data.

AI Supply Chain Security Risks and Legal Compliance Gaps

Thu, 26 Jun 2025 00:00:00 +0000

What Are AI Models and How Are They Distributed?

Artificial Intelligence models are trained software systems that make predictions or generate content based on input data. Unlike traditional software that follows explicit programming logic, AI models learn patterns from training data and encode this knowledge in mathematical weights and parameters.

Organizations today consume AI models through several distribution channels that create unique security and legal risks.

Model Components and File Formats

Tensors and Weights The core of any AI model consists of numerical parameters called tensors or weights. These contain the learned knowledge from training data. Think of them as the “brain” of the model that determines how inputs get processed into outputs.

Pickle Files (.pt, .pkl, .joblib) Python’s pickle format allows both data and executable code to be stored together in a single file. When you load a pickle file, any embedded code runs automatically. This creates a major security risk because malicious actors can hide executable payloads inside what appears to be a simple model file.

SafeTensors Format A newer secure format designed specifically to store only model weights without executable code. SafeTensors files cannot execute arbitrary code during loading, making them safer for production use.

GGUF Format Used primarily with LLaMA models and llama.cpp implementations. While safer than pickle, GGUF files can still contain metadata that requires inspection before use.

Inference Scripts and Configuration Files Models often include Python scripts that handle data preprocessing, model execution, and output formatting. These scripts can contain hidden logic or import malicious libraries.

Model Adapters and Extensions Lightweight modifications that change model behavior without retraining. LoRA adapters, for example, apply small weight adjustments to base models. Extensions might add web APIs or connect models to external services.

Datasets Training and evaluation data often accompanies models. Datasets can contain biased, copyrighted, or sensitive information that creates legal liability.

Distribution Through Python Packages

Many organizations distribute AI models inside standard Python packages (wheel files or tar.gz archives). This bundling approach creates a blind spot for traditional security tools.

The Package Problem When developers install a Python package that contains AI models, traditional dependency scanners only check the package metadata and Python code. They miss the model files stored in data folders within the package.

Real Distribution Examples

Transformers library bundles model configurations
Custom ML packages include pre-trained weights in data directories
Industry-specific packages embed domain models as package resources

This distribution method bypasses most security scanning because the models exist as data files rather than declared dependencies.

Legal Compliance Risks

The AI model ecosystem creates new categories of legal risk that traditional software compliance programs do not address.

License Documentation Gaps

Research analyzing 159,132 models on HuggingFace reveals concerning compliance gaps¹:

Missing License Information Only 35% of HuggingFace models include any license information². This means 65% of available models exist in a legal gray area where usage rights remain undefined.

AI-Specific Licensing Complexity New license types like OpenRAIL, CreativeML-OpenRAIL-M, and BigScience-BLOOM-RAIL include “responsible use” restrictions that traditional open source licenses do not contain³. These licenses may prohibit certain applications, require attribution for outputs, or restrict commercial use in specific industries.

License Compatibility Violations Analysis found 707 GitHub projects using restrictively licensed models while distributing their own code under permissive licenses¹. This creates potential legal exposure for any organization using these projects.

Specific Violation Examples It’s common to find repositories on GitHub for projects that use permissive licenses but include (or bundle) incompatible models. The most common cases are:

Apache 2.0 licensed projects using GPL-3.0 licensed models
MIT licensed software incorporating CC-BY-SA-4.0 models
Commercial applications using non-commercial research models

Dataset Provenance Problems

Training data creates additional legal complexity that most organizations ignore.

Missing Dataset Documentation Only 14% of models properly tag their training datasets¹. Manual analysis of popular models shows 58% provide some dataset information, but documentation quality varies widely.

Copyright Exposure Models trained on copyrighted content (books, articles, images, code) may create derivative works. Organizations using these models could face copyright infringement claims, especially for commercial applications.

Privacy Compliance Risks Training datasets may contain personal information, biometric data, or other regulated content. Using models trained on such data could violate GDPR, CCPA, or industry-specific privacy requirements.

Real-World Legal Challenges The Stability AI StableLM model sparked legal discussions about licensing validity when trained on copyrighted datasets⁴. Similar concerns affect most large language models trained on web-scraped content.

Bias and Fairness Documentation

Only 18% of analyzed models document potential biases¹. This creates liability for organizations deploying models in regulated industries or customer-facing applications.

Documented Bias Categories

Population bias affecting demographic groups
Geographic bias favoring certain regions
Cultural and religious bias in content generation
Historical bias reflecting outdated social norms

Business Impact Examples

Hiring tools showing gender bias in candidate ranking
Credit models discriminating against protected classes
Content generation systems producing culturally insensitive outputs

Security Threat Landscape

AI models introduce attack vectors that traditional cybersecurity tools cannot detect or prevent. Although the known impact may be reduced or limited—potentially due to the absence of tools capable of detecting these issues at scale—there are some well-known real-world cases:

Weaponized Model Incidents

December 2022: PyTorch Supply Chain Attack The torchtriton package on PyPI contained malicious code that stole environment variables and SSH keys from developers using PyTorch-nightly⁵. The attack used DNS exfiltration to steal credentials without triggering network monitoring tools.

July 2023: PoisonGPT Researchers demonstrated a backdoored GPT-J model that produced misinformation when triggered by specific phrases⁶. The poisoned model appeared to function normally in most cases but generated false information about historical events when prompted with trigger words.

February 2024: HuggingFace Model Backdoors JFrog Security discovered approximately 100 malicious models on HuggingFace containing pickle files designed to open reverse shells⁷. These models appeared legitimate but executed malicious code when loaded.

December 2024: YOLOv8 Cryptominer Attackers compromised the YOLOv8 computer vision model repository through GitHub CI systems, injecting cryptocurrency mining malware into model downloads⁸.

January 2025: Obfuscated Pickle Attack ReversingLabs identified sophisticated attacks using corrupted 7z archives to hide pickle backdoors⁹. These attacks evaded HuggingFace’s security scanners by obscuring malicious code within compressed archives.

Attack Vector Analysis

If everyone is adopting AI for everything, how is it possible that these problems occur? The honest truth is that mostly no one is looking, verifying, or reviewing. As a result, attack vectors remain available.

Model Serialization Exploits Pickle format attacks remain the most common threat vector. Malicious actors embed executable code within model files that runs automatically during loading. This code can:

Install persistent backdoors
Exfiltrate sensitive data
Establish command and control channels
Deploy additional malware

Supply Chain Injection Attackers target model repositories, CI/CD pipelines, and distribution infrastructure to inject malicious code into legitimate models. These attacks affect downstream users who trust the model source.

Model Poisoning Subtle modifications to model weights create backdoors that trigger on specific inputs. Poisoned models perform normally for most inputs but produce attacker-controlled outputs when triggered.

Dependency Confusion Malicious packages with names similar to legitimate AI libraries trick developers into installing compromised versions. These packages often contain backdoored models or steal credentials during installation.

Current Protection Gaps

Industry technical leaders are actively trying to reduce or control the situation. However, it is unusual that these efforts are not widely recognized or discussed. I would assume that companies with Open Source Program Offices (OSPOs) or specialized security teams would have their own governance programs focused on handling AI models. Unfortunately, the sad reality is that very few understand the problem or attempt to implement the best supply chain practices.

HuggingFace Security Measures HuggingFace implements several security controls:

Pickle scanning for known malicious patterns (limited)
Automated malware detection
Community reporting mechanisms
SafeTensors format promotion

Identified Weaknesses Research reveals significant gaps in current protections:

Static analysis cannot detect runtime-activated threats
Obfuscated payloads evade signature-based detection
Social engineering bypasses community review
Advanced serialization attacks exploit parser vulnerabilities

Traditional Security Tool Limitations Standard cybersecurity tools fail to address AI-specific risks:

Antivirus software cannot analyze model behavior
Network monitoring misses AI-specific exfiltration methods
Dependency scanners ignore bundled model files
Code analysis tools cannot inspect serialized weights

Why Traditional Security Tools Fall Short

Software Composition Analysis (SCA) tools focus on declared dependencies in requirements.txt or setup.py files, while specialized code scanners or snippet analysis tools focus on hash matching against known signatures. However, they cannot:

Analyze Package Contents SCA tools do not extract and examine files within wheel (.whl) or tar.gz packages. This means bundled model files remain invisible to security scanning. While some SCAs include features to inspect archive files, they are not capable of directly handling serialization and binary blobs.

Understand Model Formats Traditional tools cannot parse pickle, ONNX, or other AI-specific file formats. They treat model files as generic binary data without security analysis.

Detect Runtime Behavior Model files may appear benign during static analysis but execute malicious code when loaded by AI frameworks. Current tools cannot predict this runtime behavior.

Assess Training Data Risks No existing tools analyze the legal or ethical implications of training datasets. Organizations remain blind to copyright, privacy, and bias risks embedded in model weights.

Monitor AI-Specific Network Activity Models may communicate with external services through subtle channels that traditional network monitoring cannot detect. AI-specific exfiltration methods evade standard security controls.

AI Governance Model

So, what should we focus on to create an internal risk management strategy for AI models? Start by assessing your risks and establish AI-oriented security processes.

Organizational Risk Assessment

Immediate Threats

Malicious models stealing credentials or data
Backdoored packages in AI development environments
License violations in production AI systems
Bias-related legal exposure from undocumented model behavior

Long-Term Concerns

Increasing sophistication of AI-targeted attacks
Regulatory enforcement of AI compliance requirements
Supply chain attacks targeting AI infrastructure
Copyright litigation over training data usage

Business Impact

Financial liability from legal violations
Reputational damage from biased AI outputs
Operational disruption from compromised AI systems
Competitive disadvantage from security incidents

Recommendations for Organizations

Establish AI-Specific Security Processes

Create dedicated review procedures for AI models and related packages. Traditional software review processes do not address AI-specific risks.

Implement Model Intake Controls

Verify model source and authenticity
Convert pickle-based models to safer formats when possible
Scan model files for embedded executables
Test model behavior in isolated environments
Document training data sources and licenses

Deploy Specialized Security Tools

Use ModelScan for multi-format model file analysis
Implement Adversarial Robustness Toolbox for model testing
Deploy Garak for LLM vulnerability assessment
Add AI-specific monitoring to network security

Develop Legal Compliance Programs

Audit existing AI model usage for license compliance
Create approval processes for new AI licensing models
Establish dataset provenance requirements
Document bias testing and mitigation efforts

Train Development Teams

Educate developers about AI-specific security risks
Provide guidance on safe model handling practices
Create incident response procedures for AI security events
Establish secure AI development workflows

Monitor the Threat Landscape

Subscribe to AI security threat intelligence feeds
Participate in AI security community forums
Regular security assessments of AI infrastructure
Stay current with emerging AI attack techniques

Build Organizational Capabilities

Hire or train staff with AI security expertise
Invest in AI-specific security tooling
Develop partnerships with AI security vendors
Create internal AI security standards and policies

Takeaways

The AI revolution brings tremendous business opportunities alongside new categories of risk. Organizations that proactively address these challenges will gain competitive advantages while protecting themselves from emerging threats. Those that ignore AI-specific risks face increasing exposure to both security incidents and legal liability.

References

Pepe, F., Nardone, V., Mastropaolo, A., Canfora, G., Bavota, G., & Di Penta, M. (2024). How do Hugging Face Models Document Datasets, Bias, and Licenses? An Empirical Study. 32nd IEEE/ACM International Conference on Program Comprehension (ICPC). https://mdipenta.github.io/files/icpc2024.pdf
Mend.io. (2024). Quick Guide to Popular AI Licenses. https://www.mend.io/blog/quick-guide-to-popular-ai-licenses/
Responsible AI Licenses. (2022). OpenRAIL Licenses. https://www.licenses.ai/
HuggingFace Community Discussion. (2023). StabilityAI/StableLM License Clarity Issue. https://huggingface.co/stabilityai/stablelm-tuned-alpha-7b/discussions/6
PyTorch Team. (2022). PyTorch-nightly dependency compromised. https://pytorch.org/blog/compromised-nightly-dependency/
Mithril Security. (2023). PoisonGPT: How we hid a lobotomized LLM on Hugging Face to spread fake news. https://blog.mithrilsecurity.io/poisongpt-how-we-hid-a-lobotomized-llm-on-hugging-face-to-spread-fake-news/
JFrog Security Research. (2024). Malicious ML Models on Hugging Face. https://jfrog.com/blog/jfrog-and-hugging-face-join-forces/
Wiz Research. (2024). Ultralytics YOLOv8 Cryptominer Supply Chain Attack. https://www.wiz.io/blog/ultralytics-ai-library-hacked-via-github-for-cryptomining
ReversingLabs. (2025). Backdoored ML Models Evade Hugging Face Scanners. https://www.reversinglabs.com/newsroom/press-releases/reversinglabs-identifies-novel-ml-malware-hosted-on-leading-hugging-face-ai-model-platform

Data Resources for Agentic AI in Open Source Security and Compliance

Tue, 08 Apr 2025 00:00:00 +0000

Following my previous post, I want to expand on the topic with some ideas for data feeds that support open source compliance audits and risk assessments when using an Agentic AI approach. These resources are available today, and I’ve had the chance to test and demonstrate them in a recent talk.

SCANOSS / Software Transparency Foundation

The Software Transparency Foundation offers a public API that connects to the Open Source Software Knowledge Base (OSSKB), which is produced by SCANOSS and licensed through the STF for public use. This system uses code fingerprints to identify code components, even at the snippet level. In addition to the main scanning API, SCANOSS offers specialized open datasets focused on regulatory and legal risks, including the Crypto Algorithms Open Dataset and the Geo-Provenance dataset.

Key data provided by SCANOSS includes:

Identified component identifiers (e.g., PURLs) from code fingerprint matches
Detected licenses associated with the identified code
Hashes of matched code snippets or files
A catalog of known cryptographic algorithm implementations
Jurisdictional mappings of software components by country of origin

This data enables agents to detect reused open source code, verify license attribution, trace code origins, identify components that might require export licenses due to cryptography, and flag software sourced from regions under trade restrictions or subject to data regulations.

Software Heritage

Software Heritage is an open, non-profit initiative maintaining the world’s largest public archive of source code. Its mission of collecting and preserving all publicly available software makes it a powerful resource for compliance and cybersecurity. By offering a rich API and persistent identifiers (SWHIDs) for every piece of code, Software Heritage enables agentic systems to verify code provenance, integrity, and traceability at scale. In practice, an AI agent can leverage Software Heritage in several ways to bolster open source compliance and security:

Archive Verification: Agents can quickly check if a given source code release or package (e.g., a tarball) is already archived in Software Heritage’s database. This enables use cases like using the archived version for source compliance instead of publishing redundant tarballs.
Verify Modifications: Internal forks from open-source packages represent incremental technical debt due to cherry-picking changes when the software needs to be updated to a more recent upstream version, which is still often necessary (at least temporarily). Forks also introduce compliance and IP risks. Software Heritage’s API and scanners allow agents to identify whether a local fork has been modified and where those modifications were introduced.
License Files Dataset: Software Heritage has built the largest dataset of licenses from all the archived projects, a valuable resource for benchmarking compliance tooling and training AI on license generation.

Software Heritage’s archival infrastructure and identifiers ultimately empower a more transparent and secure open-source supply chain. By integrating SWH into their workflows, agent-based systems gain a dependable memory: they can detect unrecorded code, validate integrity through immutable hashes, and link to historical versions for context or legal compliance.

AboutCode

The AboutCode initiative encompasses several open datasets, tools, and APIs designed for in-depth analysis of software components concerning licenses, security posture, and provenance. Their key offerings include:

ScanCode.io, a self-hosted service with a RESTful API for scanning codebases
VulnerableCode, a public API that maps open source packages to known vulnerabilities
ScanCode LicenseDB, a comprehensive license database hosted on GitHub

These tools provide valuable data, including:

Detailed scan results from ScanCode.io in JSON or SPDX format, including detected licenses, package metadata, and file-level insights (Note: this service must be self-hosted.)
Vulnerability mappings from VulnerableCode, linking package identifiers (e.g., PURLs) to CVEs, along with references and fixed version details
An extensive collection of license texts, SPDX identifiers, and detection rules from ScanCode LicenseDB

Agents can leverage these tools to automate large-scale code scanning within CI/CD pipelines, query vulnerability data by package, and enrich license validation workflows or AI training sets with high-quality licensing metadata.

ClearlyDefined

ClearlyDefined is a community-driven effort focused on aggregating and curating licensing and security metadata for open source packages. This information is available via a public API, offering structured data across many popular ecosystems (npm, Maven, PyPI, NuGet, etc.).

The data includes:

Declared and discovered software licenses (SPDX identifiers)
URLs pointing to source code repositories
Copyright holder information
Full texts of detected licenses
Confidence scores indicating metadata quality
Per-file license information (accessible through specific query options)

The ClearlyDefined project is key in enriching SBOMs and compliance workflows by filling in missing or incomplete attribution data. To retrieve structured license insights, agents can query the API using standard package coordinates (type/provider/namespace/name/version).

deps.dev (Open Source Insights by Google)

deps.dev (Open Source Insights by Google) provides structured metadata and dependency information for software packages across significant ecosystems, including npm, Maven, PyPI, Go, and Rust. Its public API returns comprehensive metadata such as:

Complete dependency graphs, including direct and transitive relationships
Known vulnerabilities from the OSV database, mapped to affected version ranges
License data for each package version
Version history with release dates
Cryptographic hashes and links to source repositories
Integrated security signals, such as OpenSSF Scorecard results

This service helps agents analyze how dependencies are interconnected, track the entry points of vulnerabilities, verify licensing, monitor version freshness, and assess overall risk and health using standardized metrics.

OpenSSF Security Scorecards

OpenSSF Security Scorecards is a project by the Open Source Security Foundation that automatically evaluates open source repositories against security best practices. It assigns numeric scores to a set of defined checks, and makes results available through a public API.

The system evaluates aspects such as:

Use of code review and branch protection
Dependency pinning practices
Use of fuzzing and static analysis tools
CI/CD integration
Overall maintenance activity

Each check is scored from 0 to 10, and includes detailed explanations of what was detected and how the score was derived.

Scorecards offer a standardized, automated view of a project’s security maturity. This data can complement vulnerability and license scanning by flagging projects with weak security practices. Agentic systems can use this to prioritize high-risk components, identify gaps in development hygiene, and include security posture in broader risk assessments across the software supply chain.

Final Takeaways

These data sources are available and mature enough to support agent-based compliance tooling today. You can automate large parts of OSS license validation, vulnerability triage, and legal risk assessment by connecting them into your pipelines or AI systems.

If you’re exploring how to build or extend agentic systems for open source compliance, now is a great time to start integrating these feeds. The infrastructure is ready — it’s just connecting the dots.

AI Agents: The Missing Piece in SBOM Compliance

Mon, 07 Apr 2025 00:00:00 +0000

Today, I gave a talk called “Taming the SBOM Chaos: Using AI Agents to Audit SBOMs for OSS Compliance.” The slides and materials are on my GitHub account.

As Software Bill of Materials (SBOM) adoption grows, so does the complexity of managing, validating, and ensuring compliance with evolving regulatory frameworks. Many companies struggle with these challenges due to a lack of specialized in-house Subject Matter Experts (SMEs). My talk explored how AI-powered workflows, leveraging specialized models and OpenData APIs, can streamline compliance and audits. Attendees gained insights into how AI agents can assist in automating SBOM analysis, reducing human workload, and enhancing compliance strategies in an increasingly regulated software landscape.

Here’s a quick write-up of the ideas behind the talk:

The problem

Open source license compliance is complicated. A license might seem simple, but how you use the software changes everything. Using a library internally might involve minimal obligations, but shipping it within a product can trigger significant compliance requirements under the same license.

So the same code, under the same license, can mean different obligations depending on its use. That’s why compliance isn’t just about reading the license or running a scanner to generate a report. You need to understand the whole picture—how the software is built, how it runs, and who it’s for. That makes scaling compliance across large projects very difficult. Every case is different, and making the right call takes time, experience, and judgment.

Tools don’t solve the problem.

We have tools that try to help but don’t go far enough. Most tools assume the input is perfect. They expect a clean SBOM with all the correct and complete data. They presume every package has a valid license string, every file has the correct hash, and every rule is black and white.

But in real life, SBOMs are often broken or missing key information. Many tools struggle with this reality. Some crash, others give you results that look right but aren’t. Either way, they often don’t explain their reasoning. Even if you identify an error in the source data, correcting it within the tool isn’t always possible.

Even commercial tools that promise complete automation (Automated SCA audits) fall short. They might work for simple cases (like security vulnerability scans), but they struggle with edge cases or complex builds. And they often lock you into their thinking, acting as black boxes that you can’t easily question or improve their results.

SBOMs should help. But they often don’t.

A good SBOM should tell you what’s inside your software: package names, versions, licenses, and hashes. But most SBOMs aren’t that helpful.

Some use different formats. Others are missing key fields like license data or component hashes. Sometimes, the fields are there, but they’re wrong or manually edited. There’s no standard for what “good” looks like, and the quality varies significantly depending on how the SBOM was created.

Many SBOMs create more work instead of providing answers, forcing teams to spend valuable time correcting inaccuracies rather than using the data for analysis.

How Agentic AI helps

This is where agentic AI comes in. It’s not just a script or a one-time tool. It’s a system that can think, plan, and take action to solve a goal.

If you provide an SBOM to an AI agent, it will read the data, even if the SBOM is incomplete or incorrectly formatted. It can figure out what’s missing and try to fill in the blanks. It can check other sources, like public license databases or internal records. It can pull together what it finds and generate a clear summary for assessment.

In short, it doesn’t stop at parsing the file. It tries to answer the bigger question: “What are the risks, and what should we do about them?”

For example, imagine you get an SBOM with no license info and bad hashes. A regular tool would either fail or give you incomplete results. An AI agent would keep going. It could search for license data using the package identifiers. It might cross-check with external databases. It could flag what it couldn’t verify and give you a report showing what it found and what’s still unknown.

That’s a big step forward.

The Key Ingredient: Expert-Curated Data

Training an AI agent without data is like hiring an intern and asking them to handle compliance on day one—with no examples, training, or documentation. They won’t know where to start. Forced to provide answers without adequate guidance, you can expect anything from half-baked responses to outright hallucinations.

Like any Open Source Compliance Engineer, AI agents need foundational knowledge and context to perform effectively. If we expect agents to make sense of licenses, assess risks, and produce useful reports, we must give them expert-curated information. That includes examples of license metadata, known issues with specific packages, rules for when obligations apply, and context about how software is used.

These aren’t just “nice to have.” They’re the foundation. Without them, the agent can’t reason. It can’t tell if a component is risky. It can’t spot patterns. It can’t improve to help you better.

So instead of building tools overloaded with underdeveloped features (suffering from ‘Swiss Army knife’ syndrome), we need to focus on building and maintaining strong data feeds of knowledge. These should come from people who know open source compliance, like compliance engineers, lawyers, and auditors, who have done the work and been in the trenches.

The better the data, the better the agent. That’s what makes the difference. Pioneering organizations like SCANOSS, NexB, and Software Heritage understand this. They lead the way by offering the curated knowledge and data feeds crucial for effective compliance. This foundational work will fuel the next wave of automation driven by AI.

Other organizations like OpenSSF, ClearlyDefined, and Deps.dev offer data sources to address security and compliance information.

Final thought

AI won’t replace compliance engineers but will change how we work. Instead of spending hours looking for missing package metadata, checking GitHub for licenses, reading reports, or fixing bad SBOMs, we’ll design systems that do most of the heavy lifting for us. We’ll focus on the decisions that matter, and we’ll train agents to handle the rest.

We’re already seeing that shift, and it’s worth building on. AI agents represent the next wave in compliance management. Now is the time to start riding it.

Why Most SBOMs Fail and What to Do About It

Fri, 14 Feb 2025 00:00:00 +0000

SBOM adoption is accelerating. Regulatory pressure, threats to software supply chains, and transparency demands drive widespread use. But while SBOMs are becoming standard, their quality often falls short.

Open Source License Compliance (OSLC) teams have tracked software components and licenses for years before SBOMs became mainstream, often using spreadsheets. Standardized formats like SPDX and CycloneDX promised automation and clarity, but SBOM-driven processes usually fail to deliver in practice.

The Reality: SBOMs Are Often Incomplete, Inaccurate, and Hard to Use

Despite years of standardization and significant progress around standardized structure formats, most SBOMs lack the consistency and depth needed for real-world use. They pass schema checks but fail basic usability and quality tests.

** Common SBOM issues fall into several categories:**

Many files are incomplete, missing critical fields such as licenses, supplier names, or checksums.
Others contain duplicate components or rely heavily on “no-assertion” entries, offering little usable information.
License data is frequently inaccurate, a problem made worse by the overconfidence placed in automated SCA tools—often promoted by security departments that, by sheer coincidence, also happen to control the majority of the tooling budget.
Format incompatibility is also a frequent challenge. Although SPDX and CycloneDX aim for similar outcomes, their structural differences create friction during integration or conversion.
Compounding this, updates to SBOM standards introduce new fields and capabilities, but tools often lag in adopting them.
Many SBOMs are generated automatically by software composition tools and assumed to be accurate without further validation, leading to widespread trust in documents that may not meet compliance or quality requirements.

What Makes an SBOM High Quality?

The OpenChain Telco SBOM Guide v1.1 offers a practical definition of SBOM quality. It emphasizes standardization, completeness, and transparency to support software supply chain management. It outlines recommendations and requirements for including key metadata, license data, and transitive dependencies. The core goal is simple: every SBOM should be clear, consistent, and complete at the point of delivery.

Testing SBOM Quality: How Can You Measure It?

Here are practical methods to assess the quality of SBOMs for those using or generating them. These are general recommendations, and industry-specific practices may further enhance this framework. The following list represents basic validation checks that have proven effective in various scenarios.

Schema Validation: Use tools, such as JSON or XML validation tools, to verify that your SBOM adheres to the SPDX or CycloneDX schemas.
NTIA/CRA Compliance: Verify that your SBOM includes the necessary fields for regulatory compliance, such as license information, supplier details, and versioning.
License Verification: Employ license validation tools to compare the licenses listed in your SBOM against established license datasets and identify any inconsistencies. In experimental scenarios, I’ve observed that even advanced SCA tools may struggle to achieve 100% accuracy in license identification. When a license cannot be definitively determined, the SBOM often contains multiple notations, “no-assertion” entries, or empty fields.
Evaluating No-Assertion Rates: I have encountered SBOMs where every field for each component is marked as “no-assertion.” It is advisable to verify this information directly in the raw SBOM file, as many commercial tools attempt to infer missing data during the SBOM import, potentially contaminating the SBOM with unverifiable assumptions as the tool lacks access to the source code for confirmation.
Legal Risk Detection: Scan SBOMs against curated datasets of problematic packages to identify high-risk dependencies associated with known vulnerabilities. Some open-source communities maintain projects with datasets of problematic components (hidden binaries, incorrect license assertions, undeclared deep dependencies, etc.), which can aid in risk identification. Examples include VulnerableCode from NexB, ClearlyDefined from OSI, and OSSA (Open Source Software Advisory) from Xpertians. If your project uses any cryptography library, it’s a good time to check against the Crypto Algorithm dataset offered by SCANOSS.
Cross-Format Compatibility: When supporting multiple SBOM formats, conduct tests to preserve data integrity during conversions between SPDX and CycloneDX.
Hashing: Verify that all components include the same set of hashes and that the length and format of these hash strings correspond to the expected values.
Metadata Integrity: Vendors sometimes provide heavily manipulated SBOMs. In such cases, the tool description may be absent, or the information may exhibit inconsistencies throughout the file.

The Industry Problem: SBOMs Evolve Faster Than Tools

The most significant barrier to SBOM reliability is the gap between evolving standards and stagnant tooling. While SPDX and CycloneDX continue to add new metadata and security features, most supporting tools—scanners, automation pipelines, and policy engines—struggle to keep up. This misalignment creates gaps in automation, format conversion, policy enforcement, and risk detection. The result is a fragmented ecosystem with inconsistent adoption and limited interoperability across the software supply chain.

The Path Forward

SBOMs are essential, but generating a file isn’t enough. Usability and reliability require collaboration across standards bodies, toolmakers, and users. Schema validation is the floor, not the ceiling. We need clear quality benchmarks, better cross-format compatibility, and automation that flags low-quality SBOMs. Until a widely accepted quality standard emerges, teams must validate and refine the SBOMs they produce, consume, and share feedback to strengthen the ecosystem.

What challenges have you faced with SBOMs? What does “quality” mean in your context? I’d love to hear how you validate and improve the SBOMs in your environment.

The 'keep it simple SBoM' is the perfect small first step for your organization.

Fri, 08 Nov 2024 00:00:00 +0000

SPDX and CycloneDX are excellent standards for handling Software Bill of Material (SBoM), but full adoption requires time, tooling, and correct intake processes. If your organization is not yet ready for this, consider using a simplified format like KissBOM (commonly known as Open Source Package Inventory or OSPI). It’s a practical choice that can ease your transition into SBOM management.

For early adopters, KissBOM offers a simplified SBOM format that is not only more accessible to manage but also covers the essentials: package URLs (PURLs), license information, and optional copyright statements. Its design for ease of use makes it an excellent option for organizations needing to quickly track their software components without the overhead of more complex formats. It even allows for the manual creation of an SBOM.

While KissBOM doesn’t support the complexity of managing relationships and metadata, it can help achieve two primary goals: documenting the package inventory with license information and empowering organizations with the knowledge of using these artifacts to track and share package inventory information. Once best practices for generating, parsing, and tracking components are established, organizations can transition to fully standardized formats, implementing the necessary tooling and robust processes to create and receive SBOMs in a fully standardized format.

Starting with a simplified format will alleviate Open Source Compliance activities and allow risk screening without involving heavy tooling. For example, using the package data from KissBOMs and data sources like VulnerableCode can help simplify security risk analysis. I’ve been using KissBOMs for testing tools that automatically produce Open Source Compliance artifacts like Legal Notices and Source Compliance to alleviate the work of generating Attribution Documents. While all of these projects are still “Works in Progress,” the key is the adoption of a simplified SBoM.

Adopting a full standard will be ideal, but if we want to start experimenting and aligning organizations, concepts like KissBOM are the perfect small step to consider today.

Detecting source code generated by AI using Machine Learning

Sun, 23 Apr 2023 00:00:00 +0000

AI has become disruptive in many ways, especially for developers using AI agents to debug software, remediate errors, and even automatically generate the whole code for simple applications.

Using AI to create the software comes with additional concerns related to undeclared obligations, mainly for the lack of clearness around definitions of copyright ownership, an undefined legal figure of the service provider (contractor services vs. tooling), and the still open questions if the generated code is affected by third-party licenses of the datasets used to train the model.

The Problem with AI and Copyright

The new paradigm has brought new challenges for lawyers and copyright experts, who were surprised by the technology and are rushing to define policies and strategies to help developers to use AI tools responsibly while balancing friction to use and management for possible legal risks.

Now, whatever set of rules an organization defines about using AI, there’s the practical problem around enforcing and verifying if source code comes with AI contributions, for which companies must devise a way to verify when code was generated by an AI tool or an engineer to ensure legal compliance and security standards. While many could suggest plagiarism detection for identifying AI-generated code, it’s apparent that matching code blocks against Open Source is no longer helpful.

Detecting AI-generated code has become challenging, and as AI technology evolves, it will become more complex each day until it becomes impractical. Some AI agent services are looking to provide additional features for users so legal aspects are covered, like using “reftags” to track the provenance of the generated output or allowing users to filter the datasets used to answer a question. Still, not all players want to keep the game fair and to keep the advantage are OK with not adding these safeguards when generating code, which undoubtedly will raise concern from the Industry.

Plagiarism and Snippet Detection for AI could be obsolete.

Many vendors who offer snippet detection products are trying to add AI detection features. Still, AI technology has evolved beyond generating blocks of code. Most recent versions of AI tools can understand the programming language as human writing language, making code snippet detection obsolete if they don’t add AI capabilities to the detection tools and implement additional techniques.

If plagiarism detection is obsolete, we should look at what a developer does when writing software instead of checking the code blocks. Every developer writes code differently, not because they use different structures, but because each has other preferences for the “style” of how the code is written. There are even studies around coding style preferences against the amount of money a developer makes.

The “styles” and preferences added when the code was written together with the algorithm behind the source code could be the input for an AI detection system.

Using Machine Learning and feature extraction to identify AI

Implementing an AI detection system goes beyond what a blog post could cover, but simple techniques can be used.

While researching, I came to an idea about implementing a “feature extraction” to later generate a score for each feature that can be used to train a Machine Learning DecisionTreeClassifier, to identify AI vs. Human based on the scores.

As features, I’m extracting five features: cyclomatic complexity, style guidelines consistency, repetitive patterns, comments quality, and code indentation. Each class provides a score later passed to a DecisionTreeClassifier implemented with scikit-learn. Feel free to suggest others features, you can find the whole project on GitHub.

It is a rudimentary method in an ugly code, but it’s a method that can be extended.

NOTICE

This tool does not provide legal advice; I’m not a lawyer.

The code is an experimental implementation. Refrain from relying on the accuracy of the output of this tool.