Security & Compliance
Security and compliance controls built into your pipelines and clusters, producing the audit evidence that proves they run.
Security that lives in documents protects nothing. Sophotech engineers build controls where they execute. CI/CD gates, cluster admission, network policy, identity, and secrets across AWS, GCP, Azure, and Kubernetes. Each control emits its own evidence: policy reports, signed artifacts, access logs.
The scope is stated up front: engineering-side security only. Penetration testing, red teaming, and security operations are separate disciplines that Sophotech does not cover. Sophotech engineers design, build, and harden the control surface itself, embedded in your team and working under your management.
DevSecOps & Secure SDLC
Security scanning is wired into the pipelines your developers already use, running as merge gates inside their workflow. Static analysis and software composition analysis run on every pull request, SBOMs are generated with Syft and scanned with Trivy, and container images are signed with Cosign and verified before they deploy. Severity thresholds are agreed with the team, so gates block what matters and pass the rest without ceremony.
OWASP SAMM and NIST SSDF serve as the reference standards this practice is mapped against.
Deliverables
- SAST and SCA gates on every pull request
- SBOM generation and vulnerability scanning in CI
- Cosign image signing with deploy-time verification
- Severity thresholds and exception handling agreed with the team
- Secure SDLC baseline mapped to OWASP SAMM and NIST SSDF
Tools: Semgrep · Trivy · Syft · Cosign · GitHub Actions · GitLab CI
Cloud-Native Security
The platform layer itself is hardened: admission control over what reaches the cluster, default-deny network policy, and CIS-benchmarked baselines for AWS, GCP, Azure, and Kubernetes. Workload hardening follows the same path: non-root containers, read-only filesystems, and dropped capabilities, all applied as code and reconciled through GitOps.
This is also where Sophotech contributes upstream. Engineers have shipped code into the delivery and policy machinery these baselines run on: FluxCD, Kyverno, and the Terraform providers. A problem found on a client platform gets fixed in the project itself, so the client runs released code instead of a private patch.
Deliverables
- Admission control requiring signed images and pod security standards
- Default-deny network policies with documented allow rules
- CIS baselines applied as Terraform modules and GitOps manifests
- Hardened workload defaults: non-root, read-only filesystems, dropped capabilities
- kube-bench reports tracked per cluster in Git
Tools: Kubernetes · FluxCD · ArgoCD · Terraform · Cilium · kube-bench · Kyverno
Policy-as-Code
A rule that depends on someone remembering it is not a control. Engineers author guardrails as OPA and Kyverno policies and enforce them at two points: admission, where non-conforming resources are rejected before they reach the cluster, and CI, where the same policies evaluate Terraform plans and Kubernetes manifests before merge.
Every policy decision is exported as Prometheus metrics, so coverage and violation trends sit on a live Grafana dashboard. New policies roll out in audit mode first, then enforce. This follows the same release discipline as application code.
Deliverables
- OPA and Kyverno policy libraries versioned in Git
- Admission enforcement with audit-mode rollout before blocking
- CI policy evaluation for Terraform plans and Kubernetes manifests
- Grafana dashboards reporting policy coverage and violations
Tools: OPA · Gatekeeper · Kyverno · Conftest · Prometheus · Grafana
Compliance Readiness
For SOC 2, ISO 27001, GDPR, NIS2, and DORA, the question an auditor asks is the same: show that the control operates. Engineers implement the technical controls. Change management through pull requests, encryption at rest and in transit, logging with defined retention, and reviewed access. Each system also collects its own evidence: policy reports, pipeline logs, approval trails, configuration history in Git. One control implementation is mapped across frameworks, so several audits draw on the same evidence.
The division of labor is plain. Engineers implement controls and produce evidence; accredited auditors examine it and certify. Sophotech issues no certificates and promises no audit outcome. It builds the engineering that makes the audit uneventful. NIS2 and DORA get the same treatment, handled as pipeline and platform requirements.
Deliverables
- Technical controls mapped to SOC 2, ISO 27001, GDPR, NIS2, and DORA
- Evidence collection wired into pipelines, clusters, and logging
- Change management through pull requests with approval trails
- Logging and retention configured to framework requirements
- Control inventory listing implemented, partial, and missing items
Tools: AWS Config · AWS CloudTrail · Azure Policy · Google Cloud Audit Logs · Kyverno · Terraform
Identity & Access Management
This is design-and-build work. Engineers design the identity model first, deciding which people and which workloads may act, where, and with what privileges. They then implement it: OIDC federation from your identity provider into clusters, cloud accounts, and CI; workload identity so services authenticate without long-lived keys; Kubernetes RBAC scoped to namespaces and roles instead of cluster-admin defaults.
Pipelines authenticate to clouds with short-lived OIDC tokens, so no long-lived credentials sit in storage. Least privilege is an engineering target with a review trail. Permissions are derived from what workloads actually use, and every tightening lands as an ordinary pull request.
Deliverables
- OIDC federation across identity provider, clouds, clusters, and CI
- Workload identity replacing long-lived service keys
- Namespace-scoped Kubernetes RBAC model in Git
- Short-lived OIDC tokens for pipeline-to-cloud authentication
- Least-privilege policy diffs with review trail
Tools: AWS IAM · IRSA · GCP Workload Identity Federation · Microsoft Entra ID · Kubernetes RBAC · OIDC
Secrets Management
Secrets are the control most often improvised: tokens pasted into CI variables, keys shared in chat, certificates that expire unnoticed. Engineers replace that with managed storage and rotation. Secrets live in Vault or a cloud secret manager, reach clusters through External Secrets Operator, and are encrypted with SOPS against cloud KMS keys where GitOps requires them to be declared in Git.
Rotation runs through the same machinery, so credentials change without hand-edited manifests or redeploy scripts. Access to secrets is logged, and those logs feed the audit evidence described under Compliance Readiness.
Deliverables
- Central secret storage in Vault or cloud secret managers
- External Secrets Operator syncing secrets into clusters
- SOPS encryption for secrets declared in GitOps repositories
- Rotation procedures wired into operators and pipelines
- Secret access logging feeding compliance evidence
Tools: External Secrets Operator · HashiCorp Vault · SOPS · AWS Secrets Manager · AWS KMS · GCP Secret Manager · Azure Key Vault
Engagements are open-ended and embedded in your team, under your management and processes; delivery direction stays with you. Sophotech, a European company, holds the employment side and handles contracts, payroll, and compliance. You interview every engineer before the engagement starts, and the engagement scales as the control surface grows and winds down when the work is done.
Explore engagement options in Talent ServicesFrequently asked questions
Do you provide penetration testing, red teaming, or a SOC?
No. The scope is engineering-side security. Controls built into pipelines, clusters, and cloud accounts, covering scanning, signing, policy enforcement, identity, and secrets, plus the audit evidence that proves they operate. Penetration testing, red teaming, and a staffed security operations center are separate disciplines. Sophotech engineers build the control surface those functions depend on and work alongside the vendors who provide them.
Will this work make us SOC 2 or ISO 27001 certified?
No vendor can certify you, and none should promise it. Engineers implement the technical controls the frameworks require and build the evidence trail that an accredited auditor then examines, including policy reports, change history, and access logs. The attestation or certificate is the auditor's to issue. The engineering goal is an audit that is short, evidenced, and free of surprises.
How do engineers work with our existing security tooling and team?
Inside both. Engineers integrate with the scanners, SIEM, and ticketing you already run, and they take direction from your security lead. Where tooling is missing they propose options, you decide, they build. Policies and findings land in the workflows your developers already use, staying out of any separate portal.
What access do engineers need in our environment?
Client-issued identities with least privilege. Engineers work under accounts you create in your own identity provider, scoped to the repositories, clusters, and accounts the work touches, and revocable the moment an engagement ends. No shared credentials and no access routed through Sophotech-owned accounts. Engineer activity shows up in your access reviews and audit logs like any other team member's.
Need something not listed here? Send us your spec and we will scope a fit.
Contact us