Secure SDLC

Secure development practices: PR review, SAST static analysis, staging testing, automated deploy

Secure Development Principles

The SSM.ro platform integrates security into every stage of the software development lifecycle (SDLC), not just as a final check.

Development Pipeline

1. Code written by developer (local)
       │ Optional local static SAST analysis
       ▼
2. Pull Request created on GitHub
       │ Mandatory code review by another developer
       │ SAST static analysis + SCA dependency scanning in CI
       ▼
3. Testing in Staging environment (internal, not publicly exposed)
       │ Functionality verified
       │ Relevant security scenarios verified
       ▼
4. Merge into main branch (PR approved)
       │
       ▼
5. Automatic Build & Deploy to Heroku
       │ Rolling restart of dynos
       ▼
6. Production monitoring (New Relic + Sentry)

Security Controls in the SDLC

Stage	Control
Source code	SAST static analysis — detects vulnerabilities in application code
Dependencies	SCA dependency scanning — detects vulnerabilities in packages
Code review	Mandatory PR review — at least one other developer approves any change
Branch protection	No direct merges into `main` — changes go through PR
Staging	Full testing before production — staging does not receive real data
Deploy	Automated GitHub → Heroku pipeline — no manual steps that could introduce errors
Rollback	Versioned releases — one-click rollback to any previous release
Monitoring	New Relic + Sentry — immediate detection of production regressions

Built-in Framework Protections

The platform's web framework provides automatic protections:

Parameterized ORM — parameterized queries (SQL injection impossible via the ORM)
HTML auto-escaping — output is automatically escaped (XSS prevented automatically)
CSRF protection — CSRF token generated and validated on every state-changing request
Input validation — explicit allow-listing of user input
HTTP security headers — configured centrally: HSTS, X-Frame-Options, etc.

Separate Environments

Development — local on the developer's workstation; not exposed to the internet
Staging — internal, not publicly exposed; access restricted via HTTP Basic Auth; test data only
Production — appssm.ro; real data; HTTPS enforced; active monitoring

Production data is never copied to staging.

Secrets Management in Development

Production secrets are not accessible in development or staging
Each environment has its own set of Heroku config vars
Secrets are not included in .env files committed to the repository