Security App Development

Companies building secure software face two distinct engineering problems: building security controls into the product itself (authentication, authorisation, secrets management, input validation) and building the secure delivery pipeline that ships software without introducing vulnerabilities in the process. Both problems are architectural, not bolt-on: authentication systems retrofitted late become the primary source of access control gaps; secrets injected via environment variables in CI become the primary source of credential leaks. Security decisions made at the schema and API design stage cost an order of magnitude less to fix than the same decisions made at the hardening stage. Scrums.com builds dedicated engineering teams that embed security architecture from the first sprint, not the last.

Authentication and Authorisation Architecture

OAuth 2.0 with PKCE is the correct pattern for every public client (SPA, mobile app, CLI). Never use the implicit flow: it exposes access tokens in the URL fragment, which is logged by proxies and browsers. The authorisation server issues short-lived access tokens (15 minutes maximum) and long-lived refresh tokens stored in HttpOnly, SameSite=Strict cookies (never in localStorage). Refresh token rotation: each use of a refresh token issues a new refresh token and invalidates the old one. A presented already-invalidated token indicates theft and triggers immediate revocation of the entire refresh token family.

JWT access tokens carry only the minimum claims needed for the immediate request: sub, scope, exp, and iat. Never embed roles, permissions, or mutable user data in the JWT; these become stale the moment they are issued. For authorisation decisions, validate the JWT signature and expiry, then look up the subject's current permissions from the authorisation service (cached in Redis with a 60-second TTL). This gives real-time permission revocation without token re-issuance.

Policy-based access control using OPA (Open Policy Agent): policies are written in Rego, versioned in Git, deployed to OPA sidecar containers, and evaluated at the API gateway or service mesh layer. The policy bundle is the single source of truth for what each identity can do, not scattered if/else permission checks throughout service code. Policy changes go through code review, Rego linting, unit tests via conftest, and integration tests against the staging identity store before deploying to production.

Session management: server-side session IDs (opaque random 256-bit values, not JWTs) for traditional web applications. Session records in Redis with absolute_timeout (12 hours) and idle_timeout (30 minutes). Session fixation prevention: regenerate session ID on every privilege escalation (login, re-authentication, MFA completion). Log every session creation, termination, and timeout to the security event log.

Secrets Management and Secure Configuration

No secrets in environment variables, no secrets in source code, no secrets in container images, no secrets in CI logs. These four failure modes account for the majority of credential leak incidents. The correct pattern: all secrets live in a secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager). Applications authenticate using short-lived identity tokens (AWS IAM role, GCP Workload Identity, Vault Kubernetes auth), retrieve secrets at startup or on-demand, and never cache them beyond their lease period.

Dynamic secrets are rotated automatically: Vault's database secrets engine generates a new credential for each application request with a TTL of hours. The old credential is revoked when the TTL expires or the lease is explicitly revoked. A leaked database credential is valid for a window measured in hours, not years. Each application gets its own credential; a breach of one service does not expose credentials used by others.

Secret scanning in CI: every commit is scanned by a secret scanner (Gitleaks, TruffleHog, GitHub Advanced Security) configured with a custom ruleset covering the organisation's secret patterns (API key prefixes, token formats, certificate headers). Secret scanning must run pre-merge (blocking) not post-merge (informational). A secret that reaches the default branch must be treated as compromised immediately: rotate the secret, audit access logs from the commit timestamp, and conduct a blast radius assessment.

Configuration-as-code: every application configuration value is stored in a versioned config repository with JSON Schema or CUE validation on commit. Environment-specific non-secret values are stored in config files; secret references are stored as Vault paths resolved at runtime. Configuration changes go through code review, are auditable, and can be rolled back.

Security apps like these are built and delivered by dedicated engineering teams through our mobile app development service.

Dependency Security and Secure SDLC

Software Composition Analysis (SCA) is a non-optional CI gate: every dependency is scanned against the NVD, GitHub Advisory Database, and OSV on every pull request. Trivy, Snyk, or Grype are suitable scanners; the choice of tool matters less than the enforcement policy. High and critical CVEs with available fixes block merge. High CVEs without available fixes generate a tracked exception requiring security team sign-off with a documented mitigation and an expiry date; unresolved expired exceptions block the next deploy.

A Software Bill of Materials (SBOM) is generated for every container image and application release in CycloneDX or SPDX format. The SBOM is signed with Sigstore/Cosign and stored in the container registry alongside the image. When a new critical CVE is disclosed, the security team can query all SBOMs to identify every affected service within minutes, not days of manual triage.

Container image signing with Cosign and policy enforcement via Kyverno or OPA Gatekeeper: the admission controller rejects any pod that presents an unsigned or unverified image. Image signing occurs in CI after the image passes all security gates, using a signing key stored in KMS. This prevents deployment of images that did not go through the approved build pipeline: eliminating a class of supply chain attack where a compromised registry entry is substituted for a legitimate image.

SLSA (Supply-chain Levels for Software Artifacts) Level 2 minimum for production workloads: a verifiable provenance attestation (build platform, source commit, build parameters) is generated for every artifact. SLSA Level 3 adds the requirement that the build platform is hermetic and isolated from developer workstations. The provenance attestation is verified at deploy time before the artifact is admitted to the production environment. Dedicated engineering teams from Scrums.com implement these secure SDLC controls from the first sprint.

API Security and Input Validation Architecture

Schema validation at the API gateway layer: every inbound request is validated against the OpenAPI specification before it reaches service code. Invalid requests (missing required fields, wrong types, values outside the allowed enum, strings exceeding max length) are rejected at the gateway with a 400 response; they never reach application logic. The OpenAPI spec is the single source of truth; schema validation is enforced by generating gateway config from the spec, not by writing separate validation code.

Input sanitisation for database interactions: parameterised queries (prepared statements) everywhere: no string interpolation, no ORM query methods that accept raw SQL fragments. SQL injection is the most consistently exploitable class of vulnerability in web applications; parameterised queries eliminate the entire class when applied uniformly. Static analysis rules (Semgrep, CodeQL) flag string interpolation into database queries automatically in CI, making the check pre-merge and blocking.

API rate limiting is a config-driven policy, not code: rate limit rules (requests per second, burst size, key by IP/user/API key, penalty duration) are stored in the API gateway configuration. Limits are enforced at the gateway, not re-implemented per service. Rate limit events are logged to the security event log with the caller's identity and the limit triggered, enabling detection of credential-stuffing and scraping campaigns.

mTLS for all service-to-service communication within the cluster. Istio or Linkerd issues short-lived X.509 certificates (rotated every 24 hours) to each service workload via SPIFFE/SPIRE. Service A can only call Service B if Service B's AuthorizationPolicy permits Service A's SPIFFE ID. This eliminates lateral movement attacks where a compromised service impersonates others using long-lived static credentials. Start a conversation with Scrums.com to build security into your product architecture from day one.