Vulnerability Scanner/Detector Log4Shell Remote Code Execution Log4j (CVE-2021–44228) — Ansible log4j-cve-2021–44228 How to automate the Vulnerability Scanner/Detector provided by Red Hat RHSB-2021–009 Log4Shell — Remote Code Execution — log4j (CVE-2021–44228) with Ansible Playbook.



https://youtu.be/YXKXQy66MAA

https://redd.it/rmfjog
@r_devops

Vulnerability Scanner/Detector Log4Shell Remote Code Execution Log4j (CVE-2021–44228) — Ansible log4j-cve-2021–44228 How to automate the Vulnerability Scanner/Detector provided by Red Hat RHSB-2021–009 Log4Shell — Remote Code Execution — log4j (CVE-2021–44228) with Ansible Playbook. Installation of



https://youtu.be/YXKXQy66MAA

https://redd.it/rmffwf
@r_devops

DevOps Foundation Certifications Tutorials.

DevOps Foundation Certifications Tutorials.

\---------------------------------------------

https://www.youtube.com/playlist?list=PL0xeHY\_ImQVWiVUwZag\_ZcNYaS45gw1x\_

DevOps is a modern approach to a software development process that overcomes the challenges of earlier working models where now the Development and Operation teams work together in collaboration and sharing end to end responsibilities from Requirement gathering >> System Design >> System implementation >> System testing >> System deployment >> System maintenance and monitoring and gathering feedback from the end users, then again implementing the changes and releasing the product without delaying any time.

​

​

\#DevOps #DevSecOps #SRE #Certifications #Course #Training #Tutorials

https://redd.it/z9mt3o
@r_devops

Release: asdf-plugin-manager v1.4.0

The asdf-plugin-manager v1.4.0 has been released.

This version verifies and notifies the user if the plugin git URL doesn't match what is in the .plugin-versions file (also a couple of fixes).

If you use asdf-vm and care about security, you should use asdf-plugin-manager given asdf doesn't provide any mechanism to control which plugin version you download!

In other words, without asdf-plugin-manager, if any plugin gets compromised, you will be too! And asdf-plugin-manager comes to fix that issue.

https://github.com/asdf-community/asdf-plugin-manager/releases/tag/v1.4.0

#devsecops #security #asdf

https://redd.it/1fq4w6m
@r_devops

🚀 Milestone Unlocked: 2K Stars! 🌟

🚀 Milestone Unlocked: 2K Stars! 🌟

My Cheat-Sheet Collection just hit 2,000 stars on GitHub!
Huge thanks to everyone who starred, shared, and contributed. Your support keeps this project growing. 🙌

If you haven't checked it out yet — it's a curated collection of high-quality PDF cheat sheets for developers, DevOps engineers, and tech enthusiasts. 📚💻

Feel free to explore, contribute, and share!
\#DevOps #CheatSheet #GitHub #OpenSource #Infosec #DevSecOps #Kubernetes #Linux

https://redd.it/1kuxk2d
@r_devops

Bringing trust to your CI System

How would you even know if your build pipeline was compromised — not your code, the system that builds it?

That question is basically what pulled me down a rabbit hole last weekend. I was just going back to basics, re-reading the fundamentals of secure software delivery, and somehow landed right back on the one question that always pops up eventually: how much does anyone actually trust CI?

Because if someone quietly got a foothold in a build system, the artifact that comes out the other end still looks completely legitimate. Nothing downstream catches it, because most pipelines are built to just trust the artifact by default. That's the same pattern behind incidents like SolarWinds and Codecov — not application bugs, trust failures in the delivery path itself.

So I went down the rabbit hole properly — the current SLSA framework, provenance, in-toto attestations, the whole "how do you actually prove what happened during a build" question. Turns out the industry's answer is pretty elegant: provenance is a verifiable record of what happened during the build. Attestation is how that record gets proven, cryptographically, at every step after.

A few late nights later, my notes turned into something worth keeping — a handbook I know I'll come back to, more than once. The whole thing distills into one line I keep coming back to:

Git → Build → Artifact → Deploy → Runtime — identity, evidence, and independent verification at every boundary.

If you operate any part of a software delivery path to production, ask yourself that question today.

Read the handbook at https://securesoftwaredelivery.wckd14.xyz/

\#PlatformEngineering #SupplyChainSecurity #SLSA #SSDLC #DevSecOps

https://redd.it/1v7cj9j
@r_devops