CodeScoring

Vendor Responsibility in Open Source: Licensing Obligations Exposed by Sonatype Nexus Changes

The article examines how vendors building products on copyleft open source projects like Nexus Repository OSS inherit significant legal and security responsibilities under licenses such as EPL 1.0. Sonatype's February 2025 shift from regular OSS binary releases to a limited Community Edition forces downstream vendors to handle their own builds, patch porting, and compliance disclosures. This change highlights the second part of copyleft licenses that outlines obligations for distributors, including revealing modifications and assuming liability for the final product. Security implications arise because critical vulnerabilities in the upstream project must now be tracked and patched by the vendor, with delays creating measurable supply chain risks. The piece provides a practical checklist for buyers to assess licensing hygiene, SBOM availability, and vulnerability response times in any open source-based solution.

Challenges in Building Accurate SBOMs for C and C++ Projects Highlighted by CodeScoring Analysis

C and C++ ecosystems lack centralized package manifests, making SBOM generation far more complex than in Python, Java, or JavaScript. Libraries may arrive through system package managers like apt or dnf, build tools such as Conan and vcpkg, or direct source inclusion, with no single record of all components. CodeScoring’s Johnny agent uses eBPF to observe linker commands during builds and cross-references results with dpkg, RPM, and pkg-config metadata. The analysis distinguishes build-time SBOMs, which capture static libraries and compilation commands, from runtime SBOMs that reflect dynamic dependencies at execution. When version data cannot be verified, components are explicitly marked unresolved rather than guessed. The approach also addresses header-only libraries and patched artifacts that defeat simple hash matching.

CodeScoring Launches CodeScoring.Save Artifact Repository for Secure Enterprise Development

CodeScoring has introduced its own artifact storage solution called CodeScoring.Save, designed to handle packages, libraries, container images, and other software components used in development. The product targets corporate users of any size seeking a predictable and resilient repository that integrates security checks directly into storage and distribution workflows. Built in Go for modern Kubernetes environments, Save supports multiple package formats including Maven, npm, NuGet, PyPI, Go Modules, Docker/OCI, DEB, and RPM while providing proxy access to external repositories. It features role-based access, auditing, independent scaling of compute and storage layers, and native integration with CodeScoring.OSA to surface vulnerability data inside the repository itself. The company positions Save as a standalone local deployment option that can operate independently or alongside its existing OSA Proxy module to block malicious components at the repository level. Future plans include support for AI models as artifacts, starting with storage and distribution for ecosystems such as Hugging Face, along with certification for Russian secure development requirements.

PyPI Explores Prefix Reservation for Organizations Under PEP 752 to Prevent Name Squatting

PEP 752 proposes reserving package name prefixes for organizations on PyPI, allowing control over entire families of related package names rather than individual entries. The change addresses dependency confusion and name squatting risks where attackers register packages with familiar prefixes like google-cloud- or opentelemetry- to exploit user trust. Analysis of over 800,000 PyPI projects by CodeScoring shows that prefixes are rarely controlled by a single owner, with ecosystems like aws- managed by hundreds of accounts. The proposal introduces implicit namespaces and new metadata for clients and proxies while preserving the flat namespace model familiar to Python developers. PEP 755 will define the governance process for granting prefix rights, limiting applications to organizations and requiring clear justification. Existing packages receive backward compatibility exceptions, and the mechanism does not transfer across repositories.

Linux Foundation Report Reveals Why Companies Fork Open Source Projects and Maintain Internal Patches

A new Linux Foundation Research study of 567 IT professionals shows that organizations actively modify open source components rather than using them unchanged. While 72% contribute back to projects in some form, many maintain internal forks due to missing features, integration needs, security timelines, and regulatory requirements. The average organization supports 86 internal forks, consuming over 5,000 hours per release cycle. The largest gaps between business-critical technologies and actual contributions appear in programming languages and databases. The findings highlight growing supply-chain risks when internal branches diverge from upstream projects without proper tracking of patches and commits.