Andrew blog pipeline

docs/_sass/blog.scss

@@ -15,7 +15,7 @@ section.blog-section {
 		ul {
 
 			div.header {
-				background-color: $dark-grey-background-color;
+				background-color: $dark-blue-background-color;
 			}
 
 			div.info {

docs/_sass/default.scss

@@ -22,6 +22,38 @@ section.default-section {
 			& > h3 {
 				text-align: left;
 			}
+
+			& > ul {
+		    font-size: .9em;
+			}
+
+			blockquote {
+			  background: #f9f9f9;
+			  border-left: 10px solid #003357;
+			  margin: 1.5em 10px;
+			  padding: 0.5em 10px;
+			  quotes: "\201C""\201D""\2018""\2019";
+			  font-size: 1em;
+			  font-style: italic;
+			}
+			blockquote:before {
+			  color: #ccc;
+			  font-size: 2em;
+			  line-height: 0.1em;
+			  margin-right: 0.25em;
+			  vertical-align: -0.4em;
+			}
+
+			blockquote p {
+			  display: inline;
+			}
+
+
+
+			& > p {
+				text-align: left;
+				font-size: .9em;
+			}
 		}
 	}
 }

docs/_sass/main.scss

@@ -113,7 +113,6 @@ a.btn-primary, button.btn-primary {
 a.btn-secondary, button.btn-secondary {
 	background-color: $secondary-color;
 	color: $black-font-color;
-
 	&:hover {
 		background-color: $primary-color;
 	}
@@ -124,6 +123,7 @@ div.horizontal-top {
     display: inline-block;
     margin: 10px 20px;
     vertical-align: top;
+
 }
 
 /*

docs/blog/_posts/2024-09-10-implicit-to-explicit.md

@@ -1,10 +1,10 @@
 ---
 layout: post
-title: "From Implicit to Explicit: Why Code Signing is the Missing Link in DevSecOps"
+title: "From Implicit to Explicit: Why code signing is the missing link in DevSecOps"
 image: '2024-09-09-bg'
 date: 2024-09-10 08:00:00 +0000
 author: Paul Savoie
-summary: "By eliminating complexity, SignPath delivers a robust and flexible mechanism that fits naturally in modern software supply chains"
+summary: "By eliminating complexity, SignPath delivers a robust and flexible mechanism that fits naturally in modern software supply chains."
 description: "description"
 ---
 
@@ -36,7 +36,7 @@ Code signing is the only surefire way to guarantee that pipelines haven't been t
 
 ## The Problem with Traditional Code Signing
 
-Code-signing means attaching a digital certificate to software. Traditionally, within a Public Key Infrastructure (PKI), a certificate authority (CA) verifies the developer's identity and adds its public key to the certificate. The developer then hashes the source code, encrypts the hash (digest) with their private key, and combines this with the certificate and hash function to create a signature block. This block is then inserted into the software, completing the code-signing process.
+Code-signing involves applying digital signtures to software. Traditionally, within a Public Key Infrastructure (PKI), a certificate authority (CA) verifies a developer's identity and adds its public key to a certificate. The developer then hashes the source code, encrypts the hash (digest) with their private key, and combines this with the certificate and hash function to create a signature block. This block is then inserted into the software, completing the code-signing process.
 
 The problem with this process arises when the build environment grows more complex and dynamic:
 

docs/blog/_posts/2024-11-29-building-trusted-software-for-macos.md

@@ -1,10 +1,10 @@
 ---
 layout: post
-title: "Building trusted software for macOS"
+title: "Building Trusted Software for macOS: A how-to guide for digital signing"
 image: '2024-09-09-bg'
 date: 2024-11-29 06:00:00 +0000
 author: Paul Savoie
-summary: "Distributing trusted Apple applications beyond the App Store"
+summary: "To provide a great user experience, you must prevent annoying pop-ups and alerts by digitally signing your app to make it trusted by macOS."
 description: "description"
 ---
 

docs/blog/_posts/2025-02-02-pipeline-integrity.md

@@ -0,0 +1,74 @@
+---
+layout: post
+title: "Zero-Trust Pipelines: Rethinking software supply chain security"
+image: '2025-02-02'
+date: 2025-02-02 06:00:00 +0000
+author: Stefan Wenig
+summary: "It’s urgent that we shed traditional trust models and embrace a modern and holistic zero-trust approach to build pipelines."
+description: "description"
+---
+
+{% include image.html url="/assets/posts/2025-01-02_zero_trust_pipelines.png" %}
+
+Modern software supply chains present a paradox: they're simultaneously more automated and more vulnerable than ever. 
+
+Consider a seemingly straightforward enterprise application lifecycle:
+
+`source → compile → test → package → sign → deploy`
+
+Simple, right? Except the reality is far from the clean, straightforward diagrams we draw on whiteboards. A typical enterprise build pipeline might involve dozens of interconnected systems - from source control to artifact repositories, CI/CD platforms to deployment targets. Each connection point represents both an integration opportunity and a potential security breach.
+
+Yet it's common for security models to treat build pipelines as trusted ‘black boxes.’ These outdated security models are proving inadequate to address the emerging threat landscape. Today, malicious actors specifically target the complexity and opacity of build pipelines to operate stealthily and to conceal  their activities over long periods of time.
+
+
+## The Hidden Reality of Modern Build Systems
+We need to face the reality: most build systems are built on a foundation of implicit trust that no longer makes sense in the context of this modern threat landscape.
+We're dealing with sprawling ecosystems of interconnected tools, ad hoc scripts, and poorly governed services that have been cobbled together over the years of the credo: "just make it work". Each of these systems operates with varying levels of access and permissions, often with broad privileges that extend far beyond what's actually needed for any particular  functions.
+
+Operating under the assumption that since they're "internal" tools, development teams default to granting sweeping access rights to build systems and automation tools. They must be trustworthy, right? This model of  inherited trust propagates throughout the pipeline, resulting in a chain of  components that implicitly trust upstream sources, without any form of verification.
+
+This complexity isn't just an architectural challenge – it's a security nightmare. As one security architect recently noted, 
+
+> "The modern build pipeline has become the perfect hiding place for malicious actors. It's complex enough to conceal subtle manipulations, yet trusted enough that few question its output."
+
+In short, these systems weren't designed with zero-trust principles in mind - they were built to meet deadlines, handle edge cases, and keep the deployment pipeline flowing.
+
+Despite this glaring mismatch of priorities, many organizations continue to rely on traditional code signing as their primary safeguard. They treat the signing process as a magical seal of approval, a final checkpoint that somehow validates everything that came before it. The uncomfortable truth is that by the time code reaches the signing stage, it's already passed through numerous points where integrity could have been compromised.
+
+## Where Traditional Code Signing Meets its Match
+Current approaches to code signing operate on a dangerous assumption: that if the signing credentials are valid, then the code itself must be trustworthy. This oversimplified model ignores the complex journey that code takes from developer commit to signed artifact. When a build script requests a signing operation, traditional infrastructure simply checks the credentials and proceeds with signing, blind to the potential compromises that might have occurred along the way.
+
+Consider the implications: a properly signed application could contain malicious code inserted through a compromised build agent, an unreviewed branch, or a poisoned cache. The signature, meant to be a seal of trust, becomes instead a shield for potential attacks. The SolarWinds incident demonstrated this vulnerability with devastating clarity – properly signed software, “trustworthy” served as the vector for one of the most significant supply chain attacks in history.
+
+If we want to adapt to this new reality, it’s urgent that we shed traditional trust models and embrace a modern and holistic zero-trust approach to build pipelines.
+
+## The Case for Zero-Trust Pipelines
+Zero-trust pipelines represent a fundamental shift in how we think about build security. Instead of treating signing as a final stamp of approval, we need to view it as the culmination of a verified, trustworthy process. To do so, we must move  beyond simple credential verification and think bigger, to comprehensive pipeline validation. 
+
+The core principle is elegantly simple:
+
+>  "Developers should have fine-grained control over what they build, but zero control over how it is secured and validated."
+
+This separation of concerns empowers  development teams to maintain their agility and velocity,  while also ensuring that security teams can implement robust verification and validation processes.
+
+In practice, this means every build must undergo rigorous validation before receiving a signature. The verification process reaches back to the source code repository, confirming not just the code's origin but its review status, branch protection rules, and build environment configuration. Each component in the pipeline must continuously prove its trustworthiness rather than receiving it by default. This way:
+
+- Everything is verified server-side (because you cannot trust client-side credentials).
+- The build platform is continuously authenticated using robust mechanisms, rather than simply relying on one-time checks.
+- Security policies are defined once, stored securely outside the build environment, and enforced consistently across all build pipelines - including build configurations, branch protection rules, code reviews, and provenance tracking.
+
+Rather than dispersing signing operations throughout build scripts, a zero-trust approach centralizes verification in a controlled environment. The controlled environment is strongly bound to one or more trusted build platforms, enabling the verification of build origins and configurations, external to and independent of the build process itself.
+
+The magic happens in how this system interfaces with existing development workflows. For developers, the complexity of signing disappears behind a simple interface – they focus on building software, while the zero-trust pipeline handles security validation automatically. Security teams gain unprecedented visibility and control, defining policies at the system level that are automatically enforced for every build.
+
+This approach fundamentally reshapes the relationship between development velocity and security assurance. By moving security validation out of the developer's domain and into a controlled, automated environment, a zero-trust approach  eliminates the traditional tradeoffs  between speed and safety. The pipeline itself becomes the enforcer of security policies, creating an immutable record of verification that travels with each artifact throughout its lifecycle. This shift from periodic validation to continuous verification creates a foundation of trust that scales with modern development practices.
+
+
+## Looking Ahead: The Evolution of Build Security
+As our build systems continue to evolve, becoming more distributed and complex, the need for zero-trust pipelines will only grow. Future challenges will include integrating with emerging cloud-native platforms, supporting increasingly complex multi-architecture builds, and adapting to new regulatory frameworks.
+
+Yet the fundamental principle remains constant: trust must be earned through verification, not assumed through authentication. 
+
+> By embracing zero-trust pipelines, organizations can finally deliver on the true promise of code signing: ensuring that every signed artifact represents exactly what developers intended and security teams approved - nothing more, nothing less.
+
+The journey to secure software supply chains is complex, but the destination is clear. Zero-trust pipelines provide the architectural foundation needed to face the security challenges of modern software development with confidence and clarity.

docs/blog/index.html

@@ -54,6 +54,8 @@ <h2>Featured Posts</h2>
     <h2>Recent Posts<a href='/feed.xml'>Feed
       {% include rss.svg %}
     </a></h2>
+
+
     <ul class='card-container'>
       {% for post in site.posts %}
         <li>
@@ -78,6 +80,8 @@ <h2>Recent Posts<a href='/feed.xml'>Feed
                 {{ post.excerpt | truncatewords: 15 }}
               {% endif %}
             </p>
+		</div>
+		<div align="center">
             <a class='btn btn-secondary' href='{{ post.url }}'>Read more</a>
           </div>
         </li>