How does supply chain security work in EK9?

← Security and Sanitization · Ref: Q270

EK9 addresses supply chain security through its package system, source-level compilation, and planned infrastructure for signed packages and SBOM generation.

PACKAGE DECLARATION

EK9 packages declare dependencies with explicit version constraints:

  defines package
    version 1.0.0-0
    description "My application"
    deps
      com.example.utils 2.1.0 <= v < 3.0.0

Semantic versioning is enforced. Range constraints prevent unexpected major version upgrades.

SOURCE-LEVEL COMPILATION

Unlike ecosystems where dependencies are opaque binaries (Java JARs, Python wheels, npm tarballs), EK9 compiles from source. You can inspect every line of code in your dependency tree. There are no hidden native binaries or obfuscated bytecode.

VERSION PINNING

Exact version pinning prevents the npm left-pad problem (package deletion breaks builds) and typosquatting attacks (similarly-named malicious packages):

  deps
    org.trusted.lib 1.2.3 == v

ARCHITECTURAL VISION

The EK9 supply chain security roadmap includes:

  SBOM generation: Software Bill of Materials listing all transitive dependencies
  Cryptographic signing: Package authors sign releases, consumers verify signatures
  Repository authorization: Restrict which repositories can provide packages
  Dependency auditing: Automated scanning for known vulnerabilities

COMPARISON WITH INDUSTRY INCIDENTS

npm left-pad (2016): Single package deletion broke thousands of builds. EK9's version pinning and source compilation mitigate this.
PyPI typosquatting: Malicious packages with similar names. Source-level compilation means every dependency is inspectable.
Log4Shell (2021): Hidden JNDI lookup in binary dependency. Source compilation makes hidden functionality visible.

See Q7 for dependency management. See Q15 for semantic versioning. See Q218 for security best practices. See Q268 for OWASP vulnerability prevention.

Example

defines module qa.security.supplychain

  defines package

    version as Version: 1.0.0-0
    description as String = "Supply chain security demonstration"

  defines program

    SupplyChainDemo()
      stdout <- Stdout()

      // === PACKAGE SECURITY ===

      stdout.println("EK9 supply chain security features:")
      stdout.println("  1. Semantic versioning enforcement")
      stdout.println("  2. Source-level compilation")
      stdout.println("  3. Dependency version pinning")
      stdout.println("  4. Full dependency tree inspection")

      // === SOURCE COMPILATION ===

      stdout.println("Source compilation advantages:")
      stdout.println("  No opaque binary dependencies")
      stdout.println("  Every line of code is inspectable")
      stdout.println("  No hidden native binaries")

      // === ROADMAP ===

      stdout.println("Planned security infrastructure:")
      stdout.println("  SBOM generation")
      stdout.println("  Cryptographic package signing")
      stdout.println("  Repository authorization")

Common mistakes

E50001 — Renaming the variable means later references to 'stdout' become unresolved, triggering E50001. Variable names must be consistent. See ek9 -h E50001 for details.

Incorrect:

stdoutXYZ <- Stdout()

Correct:

stdout <- Stdout()

Other ways to ask this

How does EK9 handle dependency security?
How does EK9 prevent supply chain attacks?
How does EK9 manage package trust and verification?

Coming from another language?

Java: Maven Central with binary JARs, no built-in signing verification, Log4Shell incident. Python: PyPI with binary wheels, frequent typosquatting. JavaScript: npm with tarballs, left-pad incident, frequent supply chain attacks. Rust: crates.io with source, better model but still vulnerable. Go: module proxy with checksums, good verification. EK9: source-level compilation, semantic versioning enforcement, planned SBOM and signing infrastructure.

Keywords: vulnerability, supply, package, migrate, dependency, protect, sign, safe, sbom, trust, version, npm, chain