Dev Practices
Security Is Built In, Not Bolted On
Sensei Project Solutions follows a secure-by-design development philosophy modeled on the Microsoft Security Development Lifecycle (SDL). Security is not a final review step — it is integrated into every phase of how we design, build, test, and deploy Sensei IQ.
Our development team is small and senior, which means security accountability is direct and consistent. Every developer is responsible for the security of the code they write, and every change goes through a structured review process before it can reach production.
Microsoft Security Development Lifecycle (SDL)
Our development process follows Microsoft's SDL framework, which embeds security considerations throughout the software lifecycle:
| Phase | Security Activities |
|---|---|
| Design | Threat modeling, security requirements review, design pattern evaluation |
| Development | Secure coding standards (OWASP, Microsoft guidelines), peer review requirements |
| Build | Automated static analysis, credential scanning, dependency vulnerability scanning |
| Test | Security-focused test cases, environment isolation (dev/test/prod separation) |
| Deploy | CI/CD pipeline with gated deployments, staged rollout, post-deployment monitoring |
| Operate | Security alert monitoring, incident response, periodic vulnerability review |
Code Review: Mandatory Peer Review on Every Change
No code reaches production without a peer-reviewed pull request. This is enforced by branch protection rules in our source control system — direct commits to protected branches are blocked.
Pull requests are reviewed against a documented checklist that covers:
- Feature correctness: Does the code do what it's intended to do?
- Security vulnerabilities: Input validation, output encoding, authentication/authorization checks
- Dependency hygiene: Are new dependencies necessary? Are they from trusted sources? Are versions pinned?
- Secrets and credentials: No secrets, API keys, or credentials in source code
- Performance and maintainability: No patterns that could introduce denial-of-service or resource exhaustion
Security findings identified during code review are tracked as work items and must be resolved before the pull request can be merged.
Automated Security Scanning
Every pull request and every build triggers automated security tooling. We use a combination of tools to catch different categories of issues:
| Tool | What It Catches |
|---|---|
| CredScan | Credentials, API keys, secrets, and tokens accidentally committed to source code |
| BinSkim | Binary security issues in compiled assemblies (security feature checks, compiler settings) |
| ESLint / StyleCop | Code quality and patterns associated with common vulnerability classes in JavaScript/TypeScript and C# |
| CodeQL | Deep semantic code analysis for security vulnerabilities (SQL injection, XSS, path traversal, etc.) |
| Dependency scanning | Known vulnerabilities in npm and NuGet packages (cross-referenced against public advisory databases) |
Build pipelines are configured to fail on critical findings. Medium and lower severity findings are triaged by a developer within three business days of detection, and resolved or formally accepted with documented justification.
Secrets Management
Sensei IQ does not store secrets in source code. All production secrets, service principal credentials, and sensitive configuration values are managed through Azure Key Vault:
- Service principal secrets for deployments and integrations are stored in Key Vault with access restricted to pipeline identities and authorized personnel
- Developers do not have direct access to production secrets
- Secrets are rotated periodically and upon personnel changes
- Key Vault access is logged and auditable
During development, mock credentials and environment-specific test values are used in place of production secrets. Credential scanning (CredScan) catches any accidental inclusion of real credentials before code reaches a shared branch.
Dependency Management
Third-party packages introduce external risk. Our approach to dependency management:
- Dependencies are version-locked using package lock files (
package-lock.json,packages.lock.json) - Automated scanning checks all direct and transitive dependencies against known vulnerability databases on every build
- Security advisories for packages in active use are monitored and acted upon promptly
- Unused or outdated packages are removed during regular maintenance cycles
- Third-party GitHub Actions are restricted — only first-party GitHub and Microsoft actions are permitted in our CI/CD pipelines
Environment Isolation
Sensei maintains separation between development, test, and production environments. Production client data is never used in development or test environments. Test scenarios use synthetic or anonymized data only.
Deployment to production environments follows a staged process with approval gates. Deployments are tracked in our change management system (Azure DevOps) with full audit trails.
Security Awareness & Training
All Sensei developers participate in ongoing security education:
- Quarterly secure-coding sessions covering practical topics aligned with OWASP Top Ten and Power Platform-specific security patterns
- Annual completion of Microsoft's Secure Software Essentials learning path
- Post-incident reviews feed directly back into training materials and coding standards
- Security considerations are a standing agenda item in team retrospectives
Security is treated as a shared team responsibility, not a function delegated to a single role.