The practice of Secure Software Supply Chain (S3C) can get complex at times. Fortunately though, a large portion of the key things we can do to secure our software delivery pipelines are actually pretty easy. This post covers three concepts you can implement today:

If you are doing any vulnerability detection in your software release pipeline today, you are already familiar with the volumes of data these scanners can generate. That dataset gets significantly larger when you add things like license scanning and Software Bill of Materials (SBOM) generation.

Twitter does provide notifications for when new users start following you. It does now however provide any notifications when users stop following you. Now, there is an ample of web sites out there who do provide that service, in most cases though, they cost money, and ask you for a complete access to your Twitter account.

The recently introduced by GitHub support for OpenID Connect (OIDC) tokens in GitHub Actions allows workflows to mint new tokens and then exchange those tokens for short-lived OAuth 2.0 or JWT tokens. These tokens can be used to access and manage Cloud resources.

I learn best by doing. And recently, most of the projects I’ve been building are either REST or gRPC-base services deployed as container images into Cloud Run on GCP. That means that I increasingly find myself recreating a lot of the same infra and app deployment flows.

Why not Medium My main reason for migrating off Medium was the paywall Medium introduced while back. I actually understand why they did it. The unlimited access price: $5/month ($50/year) is too high, but still, I get it. For me though, the objective was to allow readers to easily discover and read my posts.

Increasing large amount of technical news I read come from the posts shared on Hacker News or on Twitter. While both of these services have search options, neither of these seem to be advanced enough to narrow my searches at the desired level or to setup automatic delivery.

All complexity needs to be abstracted, right? This reductionist statements misses nuance around the inherent cost/benefit tradeoffs, especially when you consider these over time. Don’t get me wrong, there often are good reasons for additional layers to make things simpler (grow adoption, lowering toil, removing friction, etc.

I recently joined the Office of CTO in Azure at Microsoft and wanted to ramp up on one of the open source projects the team has built there called Dapr. Dapr describes itself as: A portable, event-driven runtime that makes it easy for developers to build resilient, microservice stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks.

We are entering a period where custom, highly-optimized, vertical solutions are becoming viable option again. This is a good news for ISVs with proven domain expertise and skilled development resources. Why do I think so? We now have: Plethora of feature-rich developer frameworks, message queues, scalable data stores, and even lower-level components in the OSS community with great documentation and a large number of use-case validation Growing number of custom solution companies (more than just ISVs) with existing deep vertical/domain expertise who are also increasingly now investing in hiring and training strong development teams Virtually every Cloud provider offering either a raw Kubernetes service or managed container execution platform which (regardless how you feel about these technologies) creates ubiquitous surface area that can be addressed with a single solution Yes, there still are many ways in which these custom development efforts can fail.