As a follow on from my previous post from OSCAL, I wanted to take a step back and discuss the role of Open Source GRC Engineering. If we look at traditional Governance, Risk, and Compliance (GRC) tooling - because I do imagine there are GRC platforms today that are not Open Source but are innovating - we’ve seen interfaces that primarily operates on consuming data and visualizing it. Not a bad business model by any means, but where it can fundamentally fail is defined paths for data to flow.
I’m sure I am not alone here - but at one point in my engineering career I had helped build a platform, and only after building it did we come to the threshold that was - “Has this been evaluated by security”. IE traditional silos and the need to evaluate for compliance across controls that may or may not apply.
In the era of DevSecOps and the Sec was never integrated. Embarrassing in some perspectives but I had no background to even constitute knowing what standard we would even be evaluating the platform against. Ignorance does not get a free pass though - and it instilled a need to understand why there wasn’t any data to pull for re-use. This activity is done time and time again with many of the same tools and architectures and yet each one is done in a silo? that didn’t sit well with me.
Commit Signing
Let’s start with WHY?
Neat article on this topic - FBI Warning
The article above lays out a few Supply Chain Security attacks that are applicable to software development. The TLDR is that - without signing your commits - there are ways to impersonate your github account through fairly trivial means. This is a pretty scary thought - impersonation is a pretty simple social engineering attack that could result in someone letting down their defenses when they otherwise shouldn’t - or worse - attributing some known bad code to someone else in an attempt to degrade their reputation.
I am a firm believer that a continuous growth-mindset is essential for any developer (and any other person to be honest). We execute day-in and day-out and more often than not will find ourselves playing to our strengths and focusing on the mission need instead of poking at every new skill and programming language under the sun.
Devoting yourself - your time, energy, focus and grit towards the skills you know will be required for making the next big decision is a great way to continue to grow. You’ll often find yourself sitting in a position of holding subject-matter-expertise and providing that knowledge to help inform greater entities (team, company, etc) on how to execute well.
It’s amazing to me the return on investment that comes from a company investing in themselves. Every month we’re given 2 days and the ability to focus on an area of experimentation that could align with our mission objectives.
July 2022 - Small team formed to discuss the topic “OSCAL”. That’s it - no prior solutioning or planning, just prior knowledge from a few on other R&D engagements that informed us OSCAL was a topic we wanted to look at.
Another wellbeing topic - as I believe people need reminders on a regular basis. This one being important to me because it comes from a conversation with a friend.
Self Perception: How do you perceive yourself - here and now - as well as where you believe you can go.
Self deprecating comments can be fun jokes at the expense of oneself and do no harm when you know the truth behind them. But the other side of the coin is that imposter-syndrome would not be a thing if not for doubt that lives in the minds of others.
New Year - same me. Everyone has a different opinion on Resolutions and aiming to be a better person/spouse/parent/etc. It’s admirable to have that mindset.
I’m far from alone in taking the stance that I am not a resolutions-person. I both don’t wait until the new years to start thinking about resolutions and I don’t wait until the new years to start doing them. I do it all the time - continuously.
I am always looking for ways to break the extreme fundamentals of air-gapped execution into modular chunks that make application in disconnected and connected environments more capable. If you solve for the air-gap, you’ve likely solved many other delivery and orchestration problems in connected environments.
If we are talking containerized workloads services, Zarf already handles a majority of the considerations for everything post-Kubernetes (Specifically everything after the cluster has been created). What that means is there is still a gap here - we need Highly-Available Kubernetes clusters in the air-gap, and we need to be very careful to document the dependencies that get us there.
(Picture of my co-author and I writing this post)
First off - this is meant to be a very light-hearted post. Something that I hope to impress on others is that Homelabs are a great opportunity to learn and grow your skills in new and relevant ways - but they come at the cost of being a labor of love. Something you maintain entirely in your free time and is best-effort to maintain and keep healthy.
When I was first getting ready to kick this blog off - I was looking for a unique domain name. I had already purchased brandtkeller.com and that is/was more than sufficient, but I loved the idea of something more playful and fun that added a little flare to the creation of content.
Listening to some Jocko Willink Podcasts while getting my indoor cycling session in and there was that common joke “so and so woke up and chose violence” and I laughed - then got curious if there something there to explore.