Depending on where you are in your career and technology journey, the word ‘audit’ will evoke varying emotions. If you have not been through an IT audit before, the romantic idea of several external auditors in a conference room poring over printed system logs might pop into your head. Though in technology, understanding the what, where, why, and how changes occur is important every day - not only during yearly audits.
In the technology world, dealing with multiple systems is both a blessing and a curse. Potentially, having an electronic record of what happened would seem easier to produce systemically. However, systems are rarely modified in the same way, and piecing together what and how a change occurred can seem like a course in forensics. Regardless of the industry, having an audit trail or audit log can benefit all organizations.
An audit trail, also known as an audit log, is a chronological set of records that provides documentary evidence. The purpose of an audit trail can be used to trace a specific event, operation, or procedure. For example, your grocery store receipt can be used as a record of your purchases. In financial records, your ledger or collection of transactions is an audit trail.
Application Lifecycle Management (ALM) practices have been around for some time now. A common development practice is tying a requirement/defect/change request to what code has been modified. How this looks in modern practice for example would be a Pull Request tied to a JIRA ticket or GitHub Issue. That only tells part of the story. When going to production, your Continuous Delivery pipelines are crucial to orchestrating not only the application code changes, but also the infrastructure and release strategies.
Navigating software delivery is the culmination of decisions and changes that encompass the entire lifecycle of the software; rarely has one engineer been on a project their entire career. Explaining changes can be very tribal and open to interpretation, especially if those creating and/or making the changes have moved on from the team.
Since modern organizations leverage their Continuous Delivery pipelines as the core conduit to production, the system enacting the changes is great at being a systemic record of changes.
Depending on how you liked or disliked taking notes in school, when humans are required to fill out forms, prudent details are in the eye of the beholder - e.g. very subjective. Having the system record and log interactions is crucial because what the system logs is objective. When not left to a human to record and/or aggregate and display in a chronological order, having a systemic system of record is very prudent.
For software engineers, managing differences e.g. diffs is a part of the job. Source Code Management (SCM) solutions have been showing diffs for a while. Though when traversing multiple systems and configurations on the journey to production, potentially some of those configurations will be in separate repositories from the source code or not represented in source code management at all. The ability to see what has changed in your Continuous Delivery pipeline provides an excellent audit trail. These differences can be used as evidence to determine if drift has occurred.
Depending on your organization and the amount of enterprise risk and regulatory compliance you are under, audit trails can be mandatory. Though even if not under regulatory compliance, they can be beneficial.
This is the most quintessential use case for audit trails. Regulations and compliance word soup, such as being subject to a SOC 2, being under PCI/HIPAA (confidentiality, health information, privacy, data security, etc.) compliance, SOX (an annual financial audit), or even looking at FedRAMP, the ability to accurately log changes is very prudent for compliant environments and organizations.
The quintessential IT question: who made a breaking change? The ability to replay decisions systematically helps pinpoint specific changes. In modern blameless organizational cultures, this is important to learn - and prevents future failures. A modern trend is to start planning with a premortem; similar to a postmortem, but before a change is rolled in. Gameday planning for large software deployments takes this into account. Leveraging an audit trail on what has happened before can be a good indicator of what could happen next.
The CAMS model invented by Damon Edwards and John Willis is a mechanism that measures DevOps maturity. CAMS stands for Culture, Automation, Measure, and Sharing. Looking at one of the latest State of DevOps Reports that featured CAMS as a measurement, even elite performing organizations had challenges with sharing. Sharing focuses on visibility, transparency, and knowledge transfer.
Audit trails come in many shapes and forms. Outside the technology world, that can be a financial/general ledger, accounting entries, or accounting transactions - down to the receipts that you have from a restaurant or grocery store. Other audit trails, such as stock trade information, can be used for reconstructing trades to ensure compliance. When working off of pure audit level log information, finding prudent information (the needle in the haystack) can be an issue as data can be too broad/not have proper integrity. With Harness, displaying audit trail information is first-class.
A benefit of using the Harness Platform is that Audit Trails is built in as a feature into the platform. Most actions that are performed by the Harness Platform can generate an audit trail by default. Harness provides a convenient dashboard to view audit trail items.
An easy way to see this in action in Harness is just to make a change. For example, in this sample application, we decided to increase the Kubernetes resource requests from 300m to 301m of memory.
We can quickly browse the audit trail logs by going to Security -> Audit Trail and look at the last item. These items also log the IP address of the person making the change.
With the out-of-the-box difference (Diff) tool, you can easily compare what was changed.
Click the Diff tool:
As simple as that, you are on your way to having audit trail coverage in your pipelines.
Having an audit trail is not only important in account transactions, but for supporting internal controls of your IT organization. In terms of Continuous Delivery, one of the main purposes of an audit trail is to capture modifications/drift. Providing a sequence of activities is usually for team members on the team currently, and in the future. If you want to enable audit trails in your CI/CD pipeline, simply sign up for Harness today.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.