What follows is an explanation of the ActiveState build process as it relates to users interested in SLSA attestations.
ActiveState uses an automated ingestion pipeline to copy in the source code of language core versions and packages from package managers such as PyPi, CPAN, and RubyCentral. We then ingest CVEs and correlate those to the appropriate language core versions and packages.
In an effort to provide a robust and useful catalog, we target the most popular packages, as well as packages specifically requested by our users. We do a weekly build review, and then “bump the timestamp”, incorporating new additions to our catalog. After this update to our system, the source code becomes an available ingredient for users of our platform.
When a project is created, or when revisions are made to an existing project, it first goes to our Solver. The Solver determines the build graph that is needed for the requested project configuration. This includes the language version, OS, and any requested ingredients (including all the transitive and upstream dependencies).
When an error occurs in a build, a backend engineer at ActiveState may review the build plan to find the source of the error. For example, there may be an incompatibility between two requested packages. This information is noted in our ingredient metadata (which is version-controlled and access to which is strictly limited) which the Solver uses to make choices when creating build plans. Information about the build plan and any failures is stored as a record.
Next, the build process creates a runtime containing all the needed artifacts and ingredients. Each ingredient is built from source in an ephemeral Docker container, with parameters set by the automated build system. This process can be replicated at any time by re-using the same build plan.
Finally, a user brings down the artifacts contained in a specific project commit using our command line interface, the State Tool. The State Tool verifies each artifact is correct as it arrives in the virtual environment it creates for each project.
When a request for an attestation is made, either for a specific project commit or an artifact commit, the build plan generates and signs the requested version of the attestation.
Because the source code we use to build from and the build plans themselves (which contain build parameters) are stored in an immutable and git-like history versioned way, we are able to generate an accurate attestation for any point in the project’s history.
Below are items that we have intentionally excluded from our attestations. Please reach out on the forum, or to your Account Team if there is any additional information you were expecting in your attestation and did not receive. We will respond to your question and the information provided will be used to update this policy page.