The GRC Vibe Coding Recipe Book · Lesson 04 of 07
Automate an Evidence Check
Start with Python and add FastAPI only when an API is necessary.
All 7 Lessons · Jump to a Lesson
Recipe 04 · At a glance
Python (FastAPI optional)
GRC use case: Automated evidence validation
Ingredients: Python evaluates evidence · JSON carries sample records · FastAPI adds an endpoint only if another app needs one
Know the boundary: A local script can be the whole solution; protect credentials when integrating real systems.
The GRC problem
Why would a team need this?
Every audit cycle, an analyst repeats the same evidence check and copies the result into a report.
A repeatable Python check that produces a result and explanation from fictional configuration evidence. This gives us a useful way to understand the technologies involved: start with the work people need to accomplish, then consider what the application must do to support them.
The underlying concepts
What changes from the previous lesson?
An automated check is only as useful as the rule and evidence behind it. Python is often chosen because it is approachable for reading files, working with APIs, and expressing repeatable checks. FastAPI is a separate decision: it becomes relevant when another application needs to request the result.
Remember the four responsibilities from Lesson 01: interface, application logic, storage, and hosting. As requirements become more demanding, those responsibilities may need different technologies. More sophisticated does not automatically mean better.
Meet the stack
What does each technology contribute?
Python reads and checks data. A local JSON file can hold a sample input. FastAPI is a Python framework for HTTP endpoints, but a scheduled script does not need it.
None for a scheduled script; add a simple page or React UI only if people need one
Python scripts; FastAPI when a real HTTP API is needed
Local files or SQLite for a prototype; PostgreSQL or object storage as requirements grow
GitHub
These ingredients have distinct responsibilities. Understanding those boundaries is more useful than memorizing a list of popular tools, because it helps you recognize when a project needs something different.
Under the hood
How would the information move?
Follow a single piece of information through the example. The input starts with a person or an existing record, a rule transforms or validates it, and the interface or report presents the result.
A fictional JSON record containing a storage encryption setting.
A Python function applies a documented rule and distinguishes Pass, Fail, and Unknown.
A small report with the result, reason, and timestamp.
The location of the rule matters. A browser can update its own display, but decisions about access to protected records must be enforced by a trusted service. A database stores information; it does not, by itself, make the surrounding application secure.
Understand the limits
What would change the stack?
Connect a least-privilege read-only cloud API only after the local rule works; add FastAPI if another system needs an endpoint.
There is also a reason not to add more technology yet: FastAPI is unnecessary when a local or scheduled script completes the job without incoming web requests.
What to remember: Use least-privilege read-only credentials, never put secrets in source control, and do not label missing evidence as a passing control. A good stack is one whose responsibilities and tradeoffs you can explain, not necessarily one with the most features.