Developer staffing guide · 8 minute read ·
Review PostgreSQL row security with the roles the application actually uses — September 14 review
Exercise tenant reads, writes, maintenance paths, and policy bypass with synthetic accounts.
Readiness check
Is the handoff ready?
Use this table before you send the first ticket. Fix the weak spots while access is still limited.
| Area | Ready | Needs work |
|---|---|---|
| Question | One observable row-level security outcome | A request to inspect the whole system |
| Fixture | two synthetic tenants, ordinary and privileged test roles, overlapping record IDs, and denied write cases | Customer data or shared credentials |
| Evidence | database role, tenant context, statement, policy, returned row IDs, write result, and denial | A pass label without observed values |
| Approval | The database and security owners approve role grants, policy changes, and any bypass privilege. | The contractor changes production alone |
Reproduce the row-level security failure safely
A policy looks correct under an ordinary user but a worker role reads rows outside its tenant. Start with one case that can fail without touching customer records or production infrastructure. Write the expected result, stop condition, and reviewer beside the fixture.
Use two synthetic tenants, ordinary and privileged test roles, overlapping record IDs, and denied write cases. Label every identity and artifact so a reviewer can distinguish test evidence from a live record.
Leave enough evidence for a second person — September 14 review
Capture database role, tenant context, statement, policy, returned row IDs, write result, and denial. Include the source revision and test time. If behavior changes between runs, retain both results.
The database and security owners approve role grants, policy changes, and any bypass privilege. A remote programmer can prepare the fixture, run bounded checks, and explain the result. New policy, privileged access, and release approval stay with the named owner.
Copy-ready brief
Paste this into your hiring request
Test one bounded row-level security case against written acceptance rules.
two synthetic tenants, ordinary and privileged test roles, overlapping record IDs, and denied write cases
Record database role, tenant context, statement, policy, returned row IDs, write result, and denial.
The database and security owners approve role grants, policy changes, and any bypass privilege.
Buyer questions
Questions about planning the role
What should the first run prove?
It should show the expected row-level security result for one controlled fixture.
What belongs in the handoff?
Include database role, tenant context, statement, policy, returned row IDs, write result, and denial, the source revision, and any untested condition.
Who approves a production change?
The database and security owners approve role grants, policy changes, and any bypass privilege.
Sources
Planning references
These links explain the security, code review, and worker classification points used in this guide.
- NIST Secure Software Development FrameworkNIST guidance for managing software development risk.
- GitHub pull request reviewsFirst-party documentation for review and approval.