Generating a SBOM can sometimes be very simple and other times a royal pain. For this first SBOM tutorial, I’m going down the very simple path! :-) Using the open source ios-triage app, the following steps will build a CycloneDX SBOM in json format. As I’m hoping this blog is useful for folks new to security and/or programming, I’m going to provide a step-by-step approach. Note: these commands were run on macOS but can be easily adapted for Linux or Windows

SBOM generation techniques There are two primary techniques for generating a Software Bill of Materials (SBOM): Source code analysis Binary analysis Each technique has their owns strengths/weaknesses and an ideal solution would be the combination of the two. This article will provide a brief overview of each techniques, pros and cons and wrap up with a quick tutorial. Source code analysis As the name implies, source code analysis refers to analyzing the source code of the application.

What is an SBOM Software Bill of Materials (or SBOMs) have been around for over a decade and in their simplest form are a structured list of 3rd party software, components and libraries included directly, or indirectly, in your code. Why are SBOMs useful SBOMs are useful from a number of use cases/personas: List all dependencies (developer) Remove unused software (developer) Update stale software (developer) Identify non-compliant software license (developer/product) Remediate dependencies with know vulnerabilities (developer/security/product) SBOM Standards In 2011, the Linux Foundation released the SPDX standard to ease software licensing compliance issues [^1].

There are plenty of reasons to host your own git server vs using services like GitHub or GitLab. Beyond just learning something new, I prefer to use a private git server for pass (my password manager). Step 1: Setup an Ubuntu 18.04 server There are quite a few ways you can do this however I prefer to have the server accessible on the Internet so I can sync my computer(s) while I’m traveling.

When you need to setup a new Linux server on one of the popular VPS providers, the first steps are often similar. A big reason I have a blog is so I can copy/paste common tasks I need to do more than once. So, below are the first few steps I take when setting up a new Ubuntu 18.04 server on Digital Ocean. Step 1: Create new server, add ssh key While the directions will vary between VPS providers, the first step is to provision a new server and then configure it to accept SSH keys.

While converting my various websites to hugo static sites, I looked at various ways to push my local changes to production. Ultimately, I chose s3_website as the best choice for my setup. The tool is static site generator agnostic so works well with jekyll, middleman, hugo and others but in case you are curious, the tech stack I use is: hugo [static website generator] Amazon Web Servics (AWS) S3 for storage / web hosting Cloudfront for CDN Certificate Manager for TLS Route 53 for DNS (alias support) s3_website for deploys Installing s3_website on macOS Installing s3_website on macOS requires a few dependencies so I wanted to document them here for anyone else interested in using it.

As a general rule, I don’t like password hints. If the hint is any good, it would give an attacker additional info to crack your password. However, I had that sinking feel of dread the other day after I rebuilt a MacBook Pro, attached the TimeMachine backup drive and was prompted for the password. On the previous build of the computer, I must have entered the password, saved it to the keychain and forgot about it.

If you are leveraging git submodule for Hugo themes and you are accustomed to using git diff to see what changes you made and totally forgot to commit, you will need to tweak your command for git submodules. By appending --submodule=diff you will see diffs for submodules as well: $ git diff --submodule=diff You can run this command at your top level repo and see all changes in that repo plus submodule(s) or cd into a specific submodule and see see the diffs for those changes only.

If you are leveraging git submodule for Hugo themes and you are accustomed to using git without passwords (via ssh urls), you’ll find that when you add a git submodule, it will be setup for “https urls” and thus prompt you for a password: $ git push origin master Username for 'https://github.com': This is obviously annoying but easy to fix. You can check the urls for your origin with git remote -v:

When I first started tinkering with Hugo for static website generation, I would find a Hugo theme that I like, cd into my themes directory and would simply git clone the repo into my website. This works, makes sense and is the most common install instructions from the theme authors. However, you will likely run into an issue where you want to make an edit to the theme only for your website.