Xygeni seamlessly evaluates the security posture of every asset of your Software Development Life Cycle (SDLC). It offers automated asset discovery and a comprehensive inventory, ensuring total transparency over your software projects. Cataloging all artifacts, resources, and dependencies aids in making informed decisions for asset protection and implementing preventive and mitigative strategies.
Stay proactive with Xygeni's integrated anomaly detection. This feature safeguards your business operations by identifying unusual patterns that indicate emerging threats. Our code tampering prevention ensures the integrity of critical pipelines and files, and enforces security and build procedures. Additionally, Xygeni allows you to proactively identify risky or suspicious user actions, providing automated real-time alerts.
Assess the security posture of all of the components in your SDLC effortlessly using the automatic inventory and assessment capabilities of Xygeni.
Systematically prevent and remediate risks everywhere in the Software Supply Chain, including open-source packages, pipelines, artifacts, runtime assets and infrastructure.
Integrating anomaly detection is a proactive measure to safeguard your business operations by identifying unusual patterns indicating emerging threats.
Xygeni streamlines security processes, improves collaboration, and provides detailed reporting for effective software supply chain security management. It offers a range of essential features, including:
- Identifying and tracking all components in software projects to enhance security visibility and control.
- Continuously scanning and assessing components and dependencies for vulnerabilities and anomalies.
- Prioritizing and supporting teams in efficiently remediating software supply chain issues. Offering remediation support capabilities and integration with ticketing tools.
- Offering advanced reporting capabilities for tracking and monitoring changes and progress.
Please note that to utilize this plugin, a license of Xygeni Platform is required. You can easily request your license on our contact page. Dive in and experience the next level of efficiency!
Get in touch today! Book a demo and let us know how we can help you.
- Installing the Xygeni-Sensor plugin
- Xygeni pipeline-compatible Steps
- Java >= 11
- Jenkins >= 2.387.2
- In Jenkins, navigate to
Manage Jenkins > Manage Credentials > System > Global Credentials > Add Credentials- Select
Secret textas Kind and fill out required information
- Select
- In Jenkins, navigate to
Manage Jenkins > Configure System > Xygeni Sensor,- Set the
Xygeni Token Credential ID(generated above). - Set the
Xygeni API Url(https://api.xygeni.io). - Optionally click the
TestTokenbutton to check url connection and token validity. - Click the
Savebutton.
- Set the
The Xygeni Sensor plugin adds some pipeline-compatible steps that help using the Software Attestations Layer for Trust (XygeniSalt) tool by Xygeni Security in the pipeline.
Creating and verifying software attestations is the core of the SALT framework. Attestations in SALT follow the in-toto Attestations Framework. Get more info at Xygeni Docs: https://docs.xygeni.io/xydocs/build_security/salt_cli.html#_generate_custom_attestation (Subscription required).
Creates the initial draft with initial information
Adds elements (material, subject, product or statement) to the current draft attestation.
Runs a command and adds an attestation predicate for the command execution.
Builds the final attestation as in-toto Statement, serializes it as JSON, signs it with the passed key material, creates an in-toto Envelope with the statement as payload, the signature and the reference for the signing key, and publishes it in the attestation registry.
Software attestations provide context (metadata) about artifacts like versions, origins (provenance) of the source code and its git repository plus branch / tag, the build process from which it was created, dependencies or security checks passed. The attestation is typically a signed document that gives software consumers a trusted context on the built artifacts. A common attestation format is SLSA provenance.
The Xygeni Sensor plugin adds a Post Build Step to generate SLSA provenance attestations.
This step command will generate an slsa attestation provenance xygeni-salt-attestation.json in SLSA format and upload attestation to salt.xygeni.io server.
Pipeline Syntax tool could help to define xygeniSalt steps with their arguments.
- The
xygeniSaltAt(Init|Add|Run|Commit)steps could be invoked for generating custom SALT attestations. - The
xygeniSaltSlsapost step could be invoked for generating SALT provenance. Build information for the registered attestation subjects (also known as software 'products' or 'artifacts') will be registered in the signed attestation. - The
xygeniSaltVerifypost step could run Salt verify command to perform post-build and attestation validations.
Pipeline syntax example:
Subjects could be provided explicitly as a list in the subjects property. Each item in the list is a map with a given name and a content, either a Docker image published in a remote registry as part of the build (image: 'REGISTRY/IMAGE_NAME:TAG'), a local file produced by the build as a packaged artifact (file: 'path/to/file.zip'), or a value (which could be a SHA digest of a given artifact, a base-64 encoded binary value, or a string representing the artifact (value: 'sha:03afb3...1c24').
Alternatively, subjects could be referenced by pattern using the artifactFilter pattern (an Ant-like pattern), which matches files in the workspace that will be used as subjects for the SLSA provenance attestation.
The key / publicKey parameters contain the key pair to use for signing the provenance file. The signature is done with the private key, and the public key is added to the signed attestation for verification by software consumers. The keys are provided as either PEM-encoded values (text format with key enclosed between -----BEGIN...----- and -----END ...----- delimiters). The PEM-encoded key could be provided also as a path to the key file relative to the workspace directory (prefix the path with file: prefix), or as an environment variable prefixed with env:.
An optional X.509 certificate could be used for helping the software consumer to trust the signature, using the certificate parameter with a similar format.
The pkiFormat specifies the signature format (one of x509, minisign, ssh, pkcs7 or tuf). Use x509 as a good default.
Remember to encrypt the signing private key with a strong password !
For the key-password, create a Jenkins secret and use the secret name as value for the field.
You can use xygeniSalt keygen command option to generate and save signing keys to use in this attestation command.
To use keyless signing, the --keyless option could be passed to the salt commit | provenance commands. An ephemeral keypair is generated, and an ephemeral X.509 certificate will be issued by the SigStore Fulcio CA.
To authenticate the Jenkins build, Fulcio needs an OpenID Connect (OIDC) id token, as explained in OIDC Usage in Fulcio. Such OIDC token could be generated using the Jenkins OpenID Connect Provider plugin. The claims to be included in the token for proper authentication with Fulcio CA are iss, the issuer (which should be set to https://oauth2.sigstore.dev/auth) and aud, the audience (which should be set to sigstore). The sub, subject is set by the plugin as the default URL of the Jenkins job, which is adequate as the "identity" of the signer in this context. See Registering the identity provider for further information.
Jobs running in Jenkins runners use the plugin's OIDC provider that authenticates the job and generates a short-lived OIDC ID token. The OIDC plugin will store the token either in an environment variable or in a CI/CD file, so the xygeniSalt commit or xygeniSaltSlsa commands will fetch it to use for authentication with Fulcio CA.The variable and the path are configured in the conf/salt.yaml file, and the default values are SIGSTORE_ID_TOKEN or /var/run/sigstore/cosign/oidc-token path, respectively.
The ephemeral certificate has a life of 10 minutes, and the event is registered in a transparency log. Verifiers of the attestation can check that the certificate was valid at the moment where the attestation was signed, and validate the certificate chain. The identity (the Jenkins build URI) will be registered as an URI field in the X509 certificate's SAN (Subject Alternative Name), so the verifier knows which Jenkins job created the attestation. For full details, read Certificate Issuing Overview.
post {
success {
archiveArtifacts: 'target/*.jar, ouput/report*.html'
withCredentials([string(credentialsId: 'slsa-key-pass', variable: 'KEY_PASS')]) {
xygeniSaltSlsa(
artifactFilter: 'target/*.jar',
subjects: [[
name:'build image',
image:'index.docker.io/my_org/my_image:latest']],
key:'my.key',
publicKey:'mypub.pem',
keyPassword:'$KEY_PASS',
pkiFormat: 'x509'
)
}
}
}
pipeline {
agent any
stages {
stage("Init") {
steps {
xygeniSaltAtInit(
materials: [[material: 'src/']]
)
}
}
stage('Add') {
steps {
xygeniSaltAtAdd(
items: [[name: 'name', value: 'value']])
}
}
stage('Run') {
steps {
xygeniSaltAtRun(
command: 'dir',
items: [[name: 'name', value: 'value']],
maxerr: 100,
maxout: 100,
step: 'mystep',
timeout: 10)
}
}
}
post {
success {
withCredentials(
[string(credentialsId: 'OIDC_TOKEN',
variable: 'SIGSTORE_ID_TOKEN')]
) {
xygeniSaltAtCommit(
certs:[keyless:true],
outputOptions: [output: 'out.json', outputUnsigned: '-', prettyPrint: true])
}
}
}
}
The plugin provides following actions:
Build actions- XygeniSaltAtInit to Initialize a draft attestation
- XygeniSaltAtAdd to add an attestation predicate
- XygeniSaltAtRun to capture a build step
Post-build actions- XygeniSaltAtCommit to sign and publish a draft attestation.
- XygeniSaltSlsa which will generate SLSA provenance attestations.