BILINGUAL (Spanish) Senior DevSecOps Supervise Fintech Security Remediation

🔐 BILINGUAL (Spanish) Senior DevSecOps — Supervise Fintech Security Remediation, Own the High-Risk Items & Certify (AWS + GitLab + Laravel) Fixed-price milestones (15–19 hrs scoped below + a capped async Q&A pool of up to 5 hrs = ~20–24 hrs total over 4–5 weeks), with an optional light advisory retainer afterwards and a visible Phase 2 roadmap of separately-scoped projects for the right person. ════════════════════════════════════ WHO WE ARE & CONTEXT ════════════════════════════════════ We run a consumer lending (fintech) platform in Latin America (Colombia). An independent technical assessment identified critical security debt: hardcoded credentials in the codebase and Git history, no secrets vault, missing SAST / Secret Detection in CI/CD, over-permissive server permissions, and Lambdas on a deprecated Node.js runtime. We already have a detailed, block-by-block remediation runbook (Phase 1) that our in-house Junior/Mid developer is executing at ~4 hrs/day. You will receive the full runbook and assessment report under NDA. This is NOT a "figure out what to do" engagement — the plan exists. Your job is to make sure it is executed without destroying production, personally own the decisions a junior must not make alone, and certify the result in writing. 🌍 HARD REQUIREMENTS (do not apply if you don't meet these): - Native or highly fluent SPANISH (spoken + written). You will run live technical sessions in Spanish with our LatAm-based developer and Company Owner. - Availability for scheduled live sessions in GMT-5 (Colombia time). - Hands-on GitLab CI/CD security experience (not GitHub Actions rebranded) + AWS DevOps. ════════════════════════════════════ WHO DOES WHAT — DIVISION OF LABOR & BUDGET MODEL ════════════════════════════════════ 👨‍💻 OUR IN-HOUSE DEVELOPER executes (~80–100 hrs, already scoped in the runbook): - Backups/snapshots, secrets inventory, replacing hardcoded secrets with AWS Secrets Manager + config() calls in Laravel, Linux permissions cleanup, uptime monitoring, GitLab scanners and branch protection, routine third-party credential rotations UNDER YOUR SUPERVISION. - ASYNC-FIRST MODEL: he records short narrated screen videos (≤5 min, secrets always masked on screen) of his progress and test executions, and maintains an EVIDENCE INDEX (runbook item → evidence link → video timestamp) so your review hours are spent auditing, not searching. Sync calls are reserved for the critical operations. - APPROVAL TIERS: routine MRs are merged by the developer with a green pipeline (you audit them in batch via the evidence index). Security-critical MRs (encryption, auth, serverless.yml, secrets tooling, disbursement/payment flows) require your WRITTEN approval before merge. 🧙 YOU (SENIOR) own only the high-risk, high-judgment items. You DESIGN, APPROVE IN WRITING, SUPERVISE LIVE (only what can break production), and CERTIFY. Our developer types; you make sure nothing explodes. ACCESS MODEL: you get READ-ONLY AWS access (SecurityAudit / ViewOnlyAccess) for the duration of the engagement — you verify with your own eyes; you never operate the production console directly. All changes go through our developer via documented MRs. STAGING NOTE: there is no permanent staging environment in Phase 1. Critical operations are rehearsed on an EPHEMERAL environment restored from production snapshots (spun up, tested, destroyed) — building permanent staging is a Phase 2 project. ════════════════════════════════════ SCOPE — 4 MILESTONES WITH ACCEPTANCE CRITERIA (Fixed price per milestone; a milestone is paid when its "DONE WHEN" is met and its written deliverable is submitted — no verbal sign-offs. Milestones follow the execution order of our internal runbook.) ════════════════════════════════════ ▶ MILESTONE 1 — FORENSIC VALIDATION & KICKOFF AUDIT (~2–3 hrs, week 1) The exposed credentials may have already been abused. Our developer pre-collects the exposed key list, CloudTrail CSV exports, IAM inventory, and GuardDuty setup so your billable time is spent analyzing, not gathering. You do: - Verify directly in CloudTrail / IAM / GuardDuty (read-only) whether the leaked keys show signs of active exploitation; cross-check the developer's pre-collected evidence. - Review the completed backup block (snapshots, restore test, AMI, PITR settings) and flag anything unsafe BEFORE risky work starts. DONE WHEN: 📄 Written forensic memo (1–2 pages, Spanish): keys reviewed, period covered, YES/NO on active abuse, IAM anomalies, and an explicit written GO / NO-GO posted on our task board. Our internal runbook BLOCKS all credential rotations and the Lambda upgrade until your GO is posted — your memo is the gate, so it must state what you verified yourself vs. what you relied on from provided evidence. If NO-GO: containment steps, prioritized. ▶ MILESTONE 2 — LAMBDA RUNTIME UPGRADE + CI/CD AUTH ARCHITECTURE (~5–6 hrs, weeks 2–3) You do: - Lambda Node 12 → nodejs20.x: define the migration path per function (AWS SDK v2 is NOT bundled in Node ≥18 runtimes — you decide per Lambda: migrate to SDK v3 vs. bundle v2 as a bridge), approve the pilot, supervise the rollout LIVE, define rollback per function BEFORE each deploy. - CI/CD auth: write the spec to replace long-lived AWS keys in GitLab CI with OIDC (id_tokens → IAM role, trust policy scoped to protected branches). OUR DEVELOPER implements the MR from your spec; you review and approve it. If OIDC is not viable in our setup, document why and spec the best alternative. - Review the protected branches / runners / variable scoping configuration done by our developer and flag what's wrong. DONE WHEN: 📄 All Lambdas on nodejs20.x passing real-event tests + GitLab pipeline deploying WITHOUT any stored long-lived AWS key + a 1-page written description of the CI/CD auth architecture (so we're not dependent on your memory). ▶ MILESTONE 3 — AES MASTER KEY ROTATION (DESIGN + LIVE SUPERVISION) (~5–6 hrs, weeks 3–4) Context: customer PII is encrypted at the application level (Laravel) with a master key that was exposed. Data encrypted with the old key exists in the DB. You do: - Write and sign the re-encryption runbook: dual-key pattern (WRITE always v2, READ v2 with v1 fallback deployed FIRST), how v1/v2 records are distinguished, idempotent batch migration requirements, fresh snapshot beforehand, verification queries, and the v1 key escrow policy (v1 is NOT destroyed while old backups exist). - Approve the mandatory REHEARSAL on an ephemeral environment restored from a production snapshot before anything touches production. - Review the developer's implementation MR line by line BEFORE deploy. - Be present LIVE (video call) while our developer runs the production migration. DONE WHEN: 📄 Signed runbook + rehearsal log + your written MR approval + migration executed with ZERO auth downtime + verification query showing 0 records on the old key + escrow confirmed. An incident during migration caused by a flaw in YOUR runbook voids the milestone until remediated at no extra cost. ▶ MILESTONE 4 — FINAL AUDIT, PERMISSIONS REVOCATION & WRITTEN CERTIFICATION (~3–4 hrs, week 4–5) You do: - Asynchronously audit the developer's evidence index (secrets greps, gitleaks/ trufflehog history scans, rotation logs, server permissions, Secrets Manager setup, uptime monitoring). - Write the restricted "developer" IAM policy (JSON) that will replace our developer's AdministratorAccess — delivered in writing BEFORE the closing session. - Rule on the pending Git history rewrite question: rewrite now / later / never, with written justification (rewriting is PAUSED by our runbook until your decision). - Lead the final LIVE Definition-of-Done session (recorded, screen-share): YOU run the verification commands yourself (grep, find, IAM queries) — you certify what you executed, not what you watched. Then guide the Company Owner (break-glass account) through revoking the developer's AdministratorAccess + deactivating his CLI access keys, and verify the deny live. Your own access is downgraded/removed in the same session (mirror offboarding) unless a retainer is agreed. DONE WHEN: 📄 CERTIFICATION REPORT (Spanish, 3–5 pages): what was verified item by item, what you fixed, residual risks ranked, Phase 2 punch list prioritized, your Git-history verdict, and your explicit statement: "no hardcoded/Git-history credential remains active". This report is the contract's final deliverable — the engagement is not complete without it. ════════════════════════════════════ PHASE 2 ROADMAP — VISIBILITY ONLY (Each item will be scoped and priced as a SEPARATE fixed-price project after Phase 1; NOT included in the retainer. We share this so you can see this is a long-term relationship, not a one-off firefight.) ════════════════════════════════════ - Permanent staging environment + deployment pipeline to it - High-availability & scaling readiness (stateless app review, Auto Scaling) - AWS WAF in front of the public endpoints - AI-assisted code review layer (SonarQube / GitLab Duo) tuned for our stack - Git history rewrite execution (if your Phase 1 verdict recommends it) - Native in-memory secrets loading for Laravel (replacing the Phase 1 .env bridge) OPTIONAL ADVISORY RETAINER (~$500/mo, 4–6 hrs): async MR reviews of security-sensitive changes, security questions, one monthly check-in call, and first-responder guidance if an incident occurs. Implementation work is always quoted separately. ════════════════════════════════════ RULES OF ENGAGEMENT (non-negotiable) ════════════════════════════════════ - NDA before any access or documents. - Read-only access only: you never operate the production console. All changes are executed by our developer via documented Merge Requests. Direct production changes by you = contract ends. - One risky change per day (runbook rule) — your schedule must respect it. - Every approval you give must be WRITTEN (task-board comment or MR approval). Verbal approvals don't exist in this project. - Async-first: routine reviews via the evidence index and short videos; live sessions only for the critical operations listed in the milestones. - Written deliverables are part of each milestone. No document = milestone not payable. ════════════════════════════════════ ⚠️ SCREENING QUESTIONS — answer all 3 in your proposal Generic or AI-pasted answers are auto-rejected. We want YOUR reasoning from real experience, in your own words (Spanish or English). ════════════════════════════════════ QUESTION 1 — CREDENTIAL ROTATION UNDER FIRE Our production EC2 app, three Lambdas, and the GitLab pipeline all consume the same long-lived AWS Access Key, exposed in Git history. Describe your exact rotation sequence for zero downtime: which consumers move to IAM roles vs. new keys, in what order, and the precise moment you deactivate (vs. delete) the old key. Name the single mistake most likely to cause an outage. QUESTION 2 — GIT HISTORY CLEANUP: WHEN *NOT* TO DO IT The repo has 3 years of history containing secrets. A previous dev suggests running BFG / git filter-repo on master immediately. Explain the risks on an active repo with a solo developer and a live pipeline, what you'd do INSTEAD as primary mitigation, and under what specific conditions history rewriting is actually justified. QUESTION 3 — GITLAB PIPELINE HARDENING A project has masked CI/CD variables holding production credentials, but feature branches run pipelines on the same shared runner. Explain how a malicious or careless MR from an unprotected branch could exfiltrate those variables, and the specific GitLab configuration (variable/environment scoping, protected branches/runners) OR modern auth architecture (OIDC) you would apply to make that structurally impossible. ════════════════════════════════════ TO APPLY ════════════════════════════════════ Start your proposal with the word "PANDA" so we know you read the full post. Include: (1) answers to the 3 questions, (2) one example of a similar audit/remediation engagement (anonymized is fine), (3) confirmation of Spanish fluency and GMT-5 overlap, (4) your availability over the next 2 weeks, and (5) whether you'd be interested in the optional post-project advisory retainer and/or the Phase 2 projects (not a requirement to apply).