TX Text Control .NET Server

SBOM

Topic

Which third-party code does an application built with TX Text Control .NET Server ship with? A software bill of materials (SBOM) answers the question in a form that tools can read: it's a machine-readable inventory of the components, dependencies, versions, licenses and cryptographic hashes of a software product. Starting with version 34.0, Text Control provides signed SBOMs for the TX Text Control NuGet packages. Security teams use them to check what an application ships with, next to the dependencies that the application brings in itself.

Why an SBOM Matters

Publishing an application puts the TX Text Control assemblies, their native libraries and the Document Editor backend next to your own code. An SBOM makes these parts visible to the processes that manage the risk of third-party software:

  • Security incidents. When a vulnerability becomes known, the SBOM shows whether a product contains the affected component.
  • Vulnerability scanning. Tools that read the CycloneDX format check the listed components against vulnerability databases, also in a CI/CD pipeline that stops a build with critical findings. Text Control names Dependency-Track, OWASP Dependency-Check, Anchore, Snyk, Black Duck, GitHub Advanced Security and Microsoft Defender for DevOps as examples.
  • Provenance. The SBOM records who supplies each component.
  • Procurement and regulation. Enterprise procurement asks for SBOMs, and they're part of regulatory compliance, for example under the EU Cyber Resilience Act (CRA). Compliance gives the dates of the CRA.

What Text Control Provides

The SBOMs were announced in the blog article Signed CycloneDX SBOMs for CRA Compliance Available for Text Control Products:

  • Format. Each SBOM is a JSON file in the CycloneDX format.
  • Signature. Each SBOM comes with a detached PKCS#7 signature, which lets you verify that the SBOM is authentic and unchanged. A package has two files: the SBOM, ending in .cyclonedx.json, and its signature, ending in .cyclonedx.json.p7s.
  • Versions. SBOMs exist for the TX Text Control .NET NuGet packages starting with version 34.0.
  • Guideline. The SBOMs follow the requirements of the Technical Guideline TR-03183-2 of the German Federal Office for Information Security (BSI), which asks for dependency relationships, cryptographic hashes, component provenance, licensing information and metadata of deployable artifacts.

An SBOM lists:

  • the name and version of the package, its supplier and further metadata;
  • its first-party and third-party dependencies, including the transitive dependencies that referenced packages bring in;
  • the third-party native libraries it contains, including statically linked libraries where they apply;
  • package identifiers and licensing metadata;
  • a dependency graph of the package.

Which Packages Are Covered

These packages of TX Text Control .NET Server are in the list of the announcement:

PackageContains
TXTextControl.TextControl.Core.SDKThe Core engine with ServerTextControl and MailMerge
TXTextControl.TextControl.ASP.SDKThe Classic engine
TXTextControl.WebThe WebSocket middleware and the HTML helper of the Document Editor
TXTextControl.Web.DocumentEditor.BackendThe Document Editor backend process TXTextControl.Web.Server.Core
TXTextControl.Web.DocumentViewerThe Document Viewer for the Core engine

The list also contains the packages of TX Text Control .NET for Windows Forms and WPF and of TX Spell .NET. It doesn't name TXTextControl.Web.DocumentViewer.Classic or the packages on nuget.org, such as the Blazor components and TXTextControl.PDF.Validation.

Get the SBOMs

The SBOMs aren't part of the NuGet packages. Customers with an active subscription request the SBOM files and their signatures for the products they have licensed from the Text Control support or sales team.

What the Packages Depend on

Text Control develops TX Text Control almost entirely in-house, including its SVG-based rendering engine and its own JSON and XML parsers, so the SBOMs contain few external dependencies. The blog article Version 33.0 Preview: NuGet Packages Explained and Why we Minimize Dependencies explains this approach.

The Core engine package TXTextControl.TextControl.Core.SDK has no NuGet dependencies, and the other packages depend only on a few Microsoft packages, Newtonsoft.Json for the Document Viewer and the ASP.NET Core shared framework. Package Overview names the dependencies of each package with their versions. Two more facts complete the picture:

  • Native libraries. The Linux libraries of the Core engine link only against the GNU C Library, libstdc++ and libgcc_s, and not against OpenSSL, fontconfig, FreeType or X11, as Linux Requirements lists.
  • Fonts. The fonts in the Fonts folder that the Core package adds to your project are licensed under the SIL Open Font License, Version 1.1, as the file licenses.txt in the folder states.

Check the Dependencies of Your Project

The SBOMs of Text Control describe the TX Text Control packages. Your application has further dependencies of its own, and the .NET SDK lists them all. Run the following command in the folder of your project:

dotnet package list --include-transitive --vulnerable

The command works as follows:

  • --include-transitive adds the packages that other packages bring in to the packages your project references.
  • --vulnerable shows only packages with known vulnerabilities. Add --format json for output that other tools can read.
  • dotnet package list is the form of the .NET 10 SDK. With the .NET 9 SDK and earlier, the command is dotnet list package with the same options.

NuGet also checks packages for known vulnerabilities while it restores them, a feature called NuGet Audit, and reports them as the warnings NU1901 to NU1904, from low to critical severity. For projects that target .NET 10 or later, it checks transitive packages as well by default; for earlier target frameworks, only direct references. The vulnerability data comes from package sources that provide it, such as nuget.org, which takes it from the GitHub Advisory Database. Microsoft describes the options in dotnet package list and Auditing package dependencies for security vulnerabilities.

Next Steps

  • Secure Deployment: keep the packages of a deployment current and consistent.
  • Compliance: the Cyber Resilience Act and the other regulations that concern documents and software.
  • Package Overview: what each package contains and which ones your project needs.
  • Security Overview: how the parts of an application fit into its security.