Early PCAS cheat sheet for Python security, input validation, secrets, safe files, dependencies, evidence, and defensive automation.
Use this cheat sheet as early preparation for PCAS-31-0x: Certified Associate Security Specialist with Python. Python Institute lists PCAS as work in progress, so focus on stable applied Python security reasoning rather than final exam weights.
flowchart TD
S["Identify trust boundary"] --> I["Validate input before use"]
I --> P["Scope permissions and secrets"]
P --> F["Use safe file, parser, and dependency choices"]
F --> E["Handle errors without leaking internals"]
E --> L["Preserve useful logs and evidence"]
Most Python security mistakes start when a script treats input, files, environment values, dependencies, or internal services as more trustworthy than they really are.
| Area | Strong answer | Weak answer |
|---|---|---|
| Input validation | Validate type, length, format, range, and allowed values. | Trust input because it came from an internal system. |
| Secrets | Store secrets outside source code and keep them out of logs. | Commit tokens or print them while debugging. |
| File paths | Restrict paths, normalize carefully, and avoid broad filesystem reach. | Join user input into a path and open it directly. |
| Serialization | Use safe formats and avoid loading untrusted data with powerful object loaders. | Deserialize untrusted data into live objects. |
| Subprocess calls | Avoid shell string construction and pass explicit argument lists. | Concatenate user input into a shell command. |
| Dependencies | Pin, review, update, and scan packages when appropriate. | Install an unknown package because a tutorial used it. |
| Logging | Preserve evidence while redacting sensitive values. | Delete logs or expose credentials in logs. |
| Trap | Safer habit |
|---|---|
eval or exec on user-controlled strings |
Use explicit parsing, allowlists, or structured inputs. |
| Raw SQL or command strings | Use parameterized APIs or argument lists. |
| Unsafe YAML or pickle loading | Use safe loaders and avoid untrusted serialized objects. |
| Broad glob/delete operations | Preview scope, require confirmation, and keep backups where appropriate. |
| Debug tracebacks in user-facing output | Log details safely and show a minimal user message. |
| Secret values in exceptions | Redact tokens, passwords, keys, and connection strings. |
| Question | Why it matters |
|---|---|
| What is the input source? | External input needs stronger validation. |
| What is the blast radius? | Broad permissions turn small bugs into incidents. |
| What evidence is needed? | Logs and artifacts should support investigation without leaking secrets. |
| What can be safely retried? | Repeated security actions can create noise or damage if not idempotent. |
| What should fail closed? | Security checks should not silently allow risky behavior after errors. |
1allowed_roles = {"reader", "operator", "auditor"}
2
3if requested_role not in allowed_roles:
4 raise ValueError("unsupported role")
The important habit is allowlisting. A security-sensitive script should accept only known-good values instead of trying to block every possible bad value.