Case study · SecurityProduction, MedTech
Security that is part of the release, not a review after it.
DevSecOps for medical and scientific software at Danaher. Code, running application and shipped binaries are scanned on every release, cloud accounts are continuously checked against policy, and environments are built to be HIPAA- and GDPR-ready from the start.
# Every release, in order: sast Veracode # source code dast Veracode # running application binary Cybellum # what actually ships # Continuously, every AWS account: cspm Prisma Cloud # policy + drift
From my work at Danaher and Ajmera Infotech, as listed on my resume.
The problem
Medical software has to be secure and prove it.
For diagnostics and lab-instrument software, a vulnerability is a patient-safety and regulatory problem, not only an IT one. Security reviews held at the end of a release cycle find problems too late to fix cheaply, and they leave no continuous record for auditors.
The approach was to move every check into automation: scans that run on every release and block it on failure, cloud posture monitored continuously, and access and encryption controls built into the infrastructure code.
What I built
Security in layers.
-
Release gates
At SCIEX, Jenkins pipelines run Veracode static analysis (SAST) on the source, Veracode dynamic analysis (DAST) on the running application, and Cybellum binary analysis on the shipped artefacts. A release that fails these checks doesn't go out.
-
Cloud posture
Prisma Cloud CSPM enforces security policy in real time across every AWS account, detects configuration drift, and keeps the accounts continuously audit-ready instead of being cleaned up before an audit.
-
Compliant by construction
At HemoCue, production infrastructure (EKS, VPC, IAM, S3, RDS, security groups) is defined in Terraform to HIPAA- and GDPR-compliant, audit-ready standards, so compliance is reviewed in code.
-
Identity, encryption, audit
At Ajmera Infotech: IAM least privilege, KMS encryption, CloudTrail audit logging and vulnerability scanning, with compliance reviews built into every sprint rather than saved for the end.
-
Governance alignment
I work with product, QA, security and compliance teams so infrastructure delivery follows MedTech release governance and regulatory audit requirements.
In code
The same thinking in my own projects.
- dineshsai07/kubernetes-javaPublic
SonarQube analysis and a Trivy image scan built into the Jenkins pipeline before the image is pushed, plus Trivy as a Kubernetes Job for in-cluster scanning.
- MicroGuardPrivate
A product with security features: CIS, SOC 2, HIPAA and PCI-DSS benchmark scanning, RBAC audit, network-policy analysis, an immutable audit log, encrypted storage of customer API keys, and rate limiting. Its CI runs gosec, Bandit and Trivy, which currently report findings rather than block a release.
- DinapatraPrivate
Supply-chain and application security in a daily automated job: actions pinned to commit SHAs, untrusted text kept out of the shell, SSRF protection on every outbound request, prompt-injection containment for model input, and secrets redacted from logs.
Stack
Tools used
- Veracode (SAST · DAST)
- Cybellum
- Prisma Cloud (CSPM)
- SonarQube
- Trivy
- AWS IAM · KMS · CloudTrail
- Terraform
- Jenkins
- HIPAA · GDPR
Want the details?
I can talk through how the release gates and cloud posture monitoring fit together, within what my employer allows.