Introduction Link to heading

This will be the first in a series of articles providing an overview of the tooling, processes and best practises that I adhere to in development of my labs and applications.

I suspect like a lot of people when i start a project I have a lot of enthusiasm and eager to begin typing up some code, or start downloading the requirements for the lab and find it difficult to remember that without working within a framework for development the results are not going to be what I or others would consider secure and or worthwhile.

The framework I choose to work within is the DevSecOps framework.

Figure 1. DevSecOps Flow

Alt text

The diagram shows the beginning of the process to be the PLAN stage and it is this phase in the process that I begin with.

Plan Link to heading

In the planning stage I identify what I want to achieve with either the program, script or lab, specifically identifying what skill i want to reinforce or learn. While I don’t go into a full blown requirements capturing exercise, I do ensure that the outcomes of the lab or the programming task align with furthering either my learning or my professional skills. Over the years, constructing labs, programs and scripts, I have identified that spending time creating conventions, infrastructure and supporting scripts, that can be used later is beneficial. I have found the following useful to support labs and programming exercises.

  • Create a fictional company with associated organization entities, departments, groups and usernames.
  • Allocate a DNS domain name for all lab activities.
  • Allocate a RFC 1918 address space with a large enough space to accomodate all your labs, .e.g. 10.0.0.0/16
  • Create a lab PKI to support TLS encryption communication traffic between lab equipments, (self signed certificates are easy, but will trip you up later when you may have to interact with other PKIs).
  • A DNS server .e.g. Windows DNS, BIND or for an easier life DNSMasq.
  • A file server to support shared services and a basic web server for large file download .e.g. iso files
  • Create two GnuPG identities. One associated with your public internet presence and one your private lab presence for code signing and external communication.
  • Templates for boilerplate code .e.g. Python & Bash scripting Templates.

All of this functionality can be housed within a single virtual machine or multiple container images depending on your choice of implementation.

While this might seem excessive, the time taken to plan, document and setup this supporting infrastructure provides significant benefits later when constructing labs.

Code Link to heading

All labs, coding and documentation is housed within Git repositories either locally on my fileserver or on Github. All documentation is created using Markdown, allowing for linting and templating.

I use Pre-commit within all my repositories, forcing compliance with best practice and keeping me honest about my coding quality.

All Git commits are signed (once this becomes a part of your workflow this becomes second nature and becomes a significant safeguard for your external repositories) ensuring authenticity of the authorship of the artefacts.

I employ a trunk based workflow for git branching. I find this branching model more effective when developing my code and labs.

Well thats it for this article. In the next article, I will discuss in more detail the BUILD section of my workflow and the tooling that I use for the majority of my lab.