The kosli attest generic CLI command can attest anything, but unlike a “typed” attestation (such as kosli attest snyk), it does not calculate a true/false compliance value for you. Customers have reported that while a generic “escape hatch” is useful, it nevertheless has some drawbacks: Based on this feedback we’ve implemented a new attest command called kosli attest custom.

We are thrilled to announce that Kosli has joined the Fintech Open Source Foundation (FINOS), a Linux Foundation organization dedicated to fostering collaboration and innovation in financial services technology. Our goal is to engage the community establishing common standards and automation practices for DevOps controls and change management automation.

All but one of the kosli attest commands calculate the true/false compliance value for you based on their type. For example, kosli attest snyk can read the sarif output file produced by a snyk scan. The one that doesn’t is kosli attest generic which is “type-less”. It can attest anything, but Kosli cannot calculate a true/false compliance value for you. Often the tool you are using can generate the true/false value, which is then easy to capture.

The Kosli CLI provides several attest commands, such as kosli attest snyk, kosli attest jira, etc. These attestations are “typed” - each one knows how to interpret its own particular kind of input. For example, kosli attest snyk interprets the sarif file produced by a snyk container scan to determine the true/false value for that individual attestation.

Like many software teams, here at Kosli we use a continuous delivery approach. This means that every commit to our trunk is automatically built, tested, and deployed to our production-like staging environment. This provides us with the confidence that every build is potentially deployable to production. We use our staging environment to perform final exploratory testing before we deploy to production. Deployments to production are “on-demand”.

With software delivery, speed is everything. But how do you balance rapid delivery with quality, security, and compliance? To answer this question, let’s embark on a journey - one that starts in a software factory to running on the production superhighway.

“What’s really running in prod?” Every engineer will hear these immortal words on a long enough timeline (or career). It might be because a new security zero day was dropped, alerts fired from the depths of a vast microservice architecture, or you might just be looking to know what commit was actually tested. Either way, it often comes with the promise of a stressful day.

We are excited to announce that we will be migrating your Kosli Flows data to Flows with Trails. This transition will unlock access to our latest features, such as the first-class Sonar integration, as well as upcoming ones like environment compliance policies and custom attestation types. Legacy Flows have served us well in the early stages, where they were designed to map the value stream of producing a single software artifact.

The heart of Kosli’s functionality lies in its attest command. Think of it as a digital notary for your CI process. Every time you complete a significant step in your pipeline (e.g., a security scan, a build, a deployment, etc) you use kosli attest to create an immutable record of that event. However, integrating Kosli into your existing CI workflow isn’t always straightforward. You might find yourself grappling with questions like.

We’re thrilled to introduce our latest integration with LaunchDarkly! This powerful combination allows you to keep an immutable record of all changes made to your feature flags using Kosli Trails, ensuring you have the information you need for audits, compliance checks, security investigations, and incident responses.