secure-coding

Name: secure-coding
Author: techygarg

165stars12forks

How to install secure-coding?

techygarg/lattice/secure-coding

$npx -y skills add techygarg/lattice --skill secure-coding

Installs into the current project.

Summary

Apply security-conscious thinking when generating or modifying code. Enforces trust boundary awareness, input validation, injection prevention, secrets management, and defense-in-depth authorization. Use when generating code that handles user input, authentication, authorization,

Files · 1

View on GitHub

SKILL.md

1	# Secure Coding
2
3	## Config Resolution
4
5	Skill support project-custom. Order:
6
7	1. Look `.lattice/config.yaml` in repo root
8	2. If found, check `paths.secure_coding` for custom doc path
9	3. If custom path exist, read doc, check YAML frontmatter for `mode`:
10	- `mode: override` (or no mode): Custom doc take full precedence.
11	Use instead embed default. Must be comprehensive -- sole reference.
12	- `mode: overlay`: Read embed `./references/defaults.md` first, then apply
13	custom doc sections on top. Custom sections replace matching
14	sections in default (match by heading). New sections append after default.
15	4. If no config, no path, or path not found, read `./references/defaults.md`
16	5. Language adaptation: If `paths.language_idioms` exist in config, read "Error Handling" section and adapt §1 (Trust Boundary Identification) error message patterns to language idioms. Language idioms take precedence over pseudocode defaults.
17
18	## Self-Validation Checklist
19
20	STOP after gen each component. Verify ALL before proceed. If check clearly fail, fix code before present. If check judgment call with multiple valid approach (see Ambiguity Signals), flag — present options and reasoning rather than silent choose.
21
22	1. TRUST BOUNDARIES: Where trusted code meet untrusted data? All boundaries explicit identified?
23	2. INPUT VALIDATION: Every external input validated at boundary with allowlist before reach business logic?
24	3. QUERY SAFETY: All database query parameterized? Any string concat in query build?
25	4. COMMAND SAFETY: Any shell/command execution? If so, input strict allowlisted?
26	5. SECRETS: Any API key, password, token, connection string in code? If so → move to env var or secret manager.
27	6. OUTPUT ENCODING: Output encoded appropriate for render context (HTML, JSON, URL)?
28	7. AUTHORIZATION: Authorization verified at service layer, not just controller? Each endpoint enforce least privilege?
29	8. ERROR MESSAGES: Error message exposed to user avoid reveal internal detail (stack trace, SQL query, file path)?
30	9. DEPENDENCIES: New third-party package necessary? Version pinned or constrained? Any known-vulnerable package added?
31
32	## Active Anti-Pattern Scan
33
34	STOP: After verify checklist above, scan output for specific anti-pattern. If find any, fix before present code.
35
36	- [ ] Trust All Input: No validation on request param; data flow direct to business logic → validate at boundary with allowlist
37	- [ ] SQL String Concatenation: User input interpolated into SQL query → use parameterized query or ORM query builder
38	- [ ] Hardcoded Secrets: API key, password, token in source code → use env var or secret manager
39	- [ ] Missing Authorization: Auth checked at login but not re-verified at service or resource level → check at every layer
40	- [ ] Overly Broad Permissions: Admin access granted where read-only suffice → apply least privilege
41	- [ ] Unvalidated Redirects: User-controlled URL used in redirect → allowlist permitted destination
42	- [ ] Verbose Error Messages: Stack trace or SQL in API response → return generic message, log detail server-side
43	- [ ] Logging Sensitive Data: Password, token, PII in log file → log event, not value; mask sensitive field
44
45	## Ambiguity Signals
46
47	Check often have multiple valid outcome. When encounter, present option rather than silent choose.
48
49	- Trust Boundary Scope: Internal API behind trusted gateway may or may not need full boundary validation.
50	- Error Message Detail: How much info is "actionable but safe" depend on whether consumer is human user, frontend client, or internal service.
51	- Validation Depth: Whether to re-validate at inner layer (defense-in-depth) or trust boundary validation alone.
52	- Auth vs Authz Failure Response: Whether to return 401 (not authenticated) or 403 (not authorized) depend on whether identity is known.
53
54	## Core Principle
55
56	Govern security posture of generated code — trust boundaries, input validation, injection prevention, secrets, authorization.
57
58	Boundary with clean-code: clean-code governs error message craft; this skill governs what error messages must not reveal (internal detail).
59
60	Boundary with architecture: architecture defines where checks live (service layer, not controller); this skill defines what to check (identity confirmed, permissi

People who liked this also viewed

6 picks

Type

secure-coding

165stars12forks

View on GitHub

How to install secure-coding?

techygarg/lattice/secure-coding

$npx -y skills add techygarg/lattice --skill secure-coding

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Secure Coding
2
3	## Config Resolution
4
5	Skill support project-custom. Order:
6
7	1. Look `.lattice/config.yaml` in repo root
8	2. If found, check `paths.secure_coding` for custom doc path
9	3. If custom path exist, read doc, check YAML frontmatter for `mode`:
10	- `mode: override` (or no mode): Custom doc take full precedence.
11	Use instead embed default. Must be comprehensive -- sole reference.
12	- `mode: overlay`: Read embed `./references/defaults.md` first, then apply
13	custom doc sections on top. Custom sections replace matching
14	sections in default (match by heading). New sections append after default.
15	4. If no config, no path, or path not found, read `./references/defaults.md`
16	5. Language adaptation: If `paths.language_idioms` exist in config, read "Error Handling" section and adapt §1 (Trust Boundary Identification) error message patterns to language idioms. Language idioms take precedence over pseudocode defaults.
17
18	## Self-Validation Checklist
19
20	STOP after gen each component. Verify ALL before proceed. If check clearly fail, fix code before present. If check judgment call with multiple valid approach (see Ambiguity Signals), flag — present options and reasoning rather than silent choose.
21
22	1. TRUST BOUNDARIES: Where trusted code meet untrusted data? All boundaries explicit identified?
23	2. INPUT VALIDATION: Every external input validated at boundary with allowlist before reach business logic?
24	3. QUERY SAFETY: All database query parameterized? Any string concat in query build?
25	4. COMMAND SAFETY: Any shell/command execution? If so, input strict allowlisted?
26	5. SECRETS: Any API key, password, token, connection string in code? If so → move to env var or secret manager.
27	6. OUTPUT ENCODING: Output encoded appropriate for render context (HTML, JSON, URL)?
28	7. AUTHORIZATION: Authorization verified at service layer, not just controller? Each endpoint enforce least privilege?
29	8. ERROR MESSAGES: Error message exposed to user avoid reveal internal detail (stack trace, SQL query, file path)?
30	9. DEPENDENCIES: New third-party package necessary? Version pinned or constrained? Any known-vulnerable package added?
31
32	## Active Anti-Pattern Scan
33
34	STOP: After verify checklist above, scan output for specific anti-pattern. If find any, fix before present code.
35
36	- [ ] Trust All Input: No validation on request param; data flow direct to business logic → validate at boundary with allowlist
37	- [ ] SQL String Concatenation: User input interpolated into SQL query → use parameterized query or ORM query builder
38	- [ ] Hardcoded Secrets: API key, password, token in source code → use env var or secret manager
39	- [ ] Missing Authorization: Auth checked at login but not re-verified at service or resource level → check at every layer
40	- [ ] Overly Broad Permissions: Admin access granted where read-only suffice → apply least privilege
41	- [ ] Unvalidated Redirects: User-controlled URL used in redirect → allowlist permitted destination
42	- [ ] Verbose Error Messages: Stack trace or SQL in API response → return generic message, log detail server-side
43	- [ ] Logging Sensitive Data: Password, token, PII in log file → log event, not value; mask sensitive field
44
45	## Ambiguity Signals
46
47	Check often have multiple valid outcome. When encounter, present option rather than silent choose.
48
49	- Trust Boundary Scope: Internal API behind trusted gateway may or may not need full boundary validation.
50	- Error Message Detail: How much info is "actionable but safe" depend on whether consumer is human user, frontend client, or internal service.
51	- Validation Depth: Whether to re-validate at inner layer (defense-in-depth) or trust boundary validation alone.
52	- Auth vs Authz Failure Response: Whether to return 401 (not authenticated) or 403 (not authorized) depend on whether identity is known.
53
54	## Core Principle
55
56	Govern security posture of generated code — trust boundaries, input validation, injection prevention, secrets, authorization.
57
58	Boundary with clean-code: clean-code governs error message craft; this skill governs what error messages must not reveal (internal detail).
59
60	Boundary with architecture: architecture defines where checks live (service layer, not controller); this skill defines what to check (identity confirmed, permissi

People who liked this also viewed

6 picks

Type