Counter Measures Security · Project Scoping Briefing

<BART>Application Security Test & Penetration Test

Prepared for AccruePartnersJuly 2, 2026
WHY THIS ENGAGEMENT EXISTS

A sale to private equity —
and the diligence that comes with it.

AccruePartners is moving toward an acquisition by a private equity firm and its backers. Security diligence on a deal like this almost always asks for one thing by name: a penetration test. BART is the platform being acquired — so before the deal closes, it needs an independent security assessment and a clean attestation the buyers can stand behind.

The driver
02 / 17
The asset under test

BART is AccruePartners'
custom recruiting platform.

  • A branded web portal that invites and manages clients and candidates through the hiring workflow.
  • Two-way sync with AccruePartners' Bullhorn ATS — the system of record for people and jobs.
  • Holds real PII: resumes, candidate profiles, and hiring feedback — data that carries regulatory weight.
  • Runs on AccruePartners' own cloud and code accounts; nothing is proprietary to the developer (FYC Labs) — it is a standard modern stack.
What BART is
03 / 17
Technology surface

A standard modern web stack — and every layer is in scope.

Front end
React 18 + Vite — single-bundle SPA served over HTTPS
Back end
Node.js 22 · Express 5 · TypeScript — requests, business logic, integrations
Data
PostgreSQL via Prisma ORM — on Google Cloud SQL
Hosting
Firebase Hosting · Cloud Run · Cloud SQL — AccruePartners' own GCP project
Identity
Firebase Authentication — role-based access enforced on the API
Secrets
GCP Secret Manager — keys & credentials
Integration
Bullhorn REST API — polling every ~5 min · candidate sync ~15 min
Technology surface
04 / 17
Live recon · login surface

Two front doors, two auth models.

bart.accruepartners.com/login
BART recruiter login
Recruiter — password authEmail + password, "remember me", password reset. Classic credential surface: brute-force, lockout, reset-token integrity.
bart.accruepartners.com/login?mode=magic-link
BART client magic-link login
Client — magic-link / 6-digit OTPPasswordless code flow. Tests: code entropy, rate-limiting, replay, account enumeration, and session issuance.
Observed on the live app · a third-party Userback widget is also present
05 / 17
THE ENGAGEMENT

An application security test —
a full penetration test of BART.

Manual, tester-led analysis backed by AI-assisted tooling. Every finding ships with confirmed proof, exact reproduction steps, and clear ownership — fix-it-yourself versus take-it-to-the-vendor.

The engagement
06 / 17
Scope of work · nine workstreams

What we test.

01
Core
Penetration Test
Application security test of BART across every privilege level.
02
Teaming
Red · Blue · Purple
Client, internal, admin, and developer access — all exercised.
03
Integration
Bullhorn API
Authorization, object references, and data-exposure assessment.
04
Regulatory
CA + NY Privacy
Alignment with California and New York privacy requirements.
05
Code
Static + Dynamic Review
Source and runtime review, as far as access allows.
06
Logic
Business Logic
Workflow abuse, bypass, and privilege-of-intent flaws.
07
Diligence
Vendor Risk & Liability
From the developer contract, in the context of the PE sale.
08
Assurance
Re-test + Attestation
Verify fixes and issue a signed attestation letter.
Scope
07 / 17
Red · Blue · Purple across every role

Every privilege boundary, exercised.

We attack from each level and verify the controls between them hold — no horizontal or vertical escalation.

Client
External portal user reviewing shared candidates. The lowest-trust door — and the widest blast radius if it over-reaches.
Least privilege
Internal
Recruiter-level access managing clients and candidates across the workflow.
Operator
Admin
Elevated control over users, roles, and configuration.
Elevated
Developer
The deepest access — secrets, deploy, and data. Where vendor-risk and separation-of-duties meet.
Highest trust
Privilege model
08 / 17
How we work — attacker's progression

The methodology.

1 · External recon
Attack-surface enumeration, tech fingerprinting, TLS & header review, external vulnerability scan.
Outside-in
2 · Auth & session
Both login flows — password and magic-link/OTP: rate-limiting, lockout, enumeration, token & session integrity.
The front doors
3 · Access control
Horizontal and vertical privilege testing across client, internal, admin, and developer.
Boundaries
4 · API & data
Endpoint authorization, insecure direct object references, and data-exposure — including the Bullhorn integration.
The seams
5 · Business logic
Injection, XSS, CSRF, and workflow-bypass across forms and endpoints.
The rules
6 · Code review
Static and dynamic review for hardcoded values, exposed routes, and sensitive-data leakage.
Inside-out
Methodology
09 / 17
Integration spotlight

The Bullhorn seam is where the crown jewels move.

BART syncs two ways with Bullhorn — event polling roughly every 5 minutes and candidate auto-sync every 15. That pipe carries the most sensitive data in the system, so it gets dedicated attention.

  • Authorization — can a lower-privilege user reach records the sync pulled in?
  • Direct object references — are candidate and client IDs guessable or enumerable across tenants?
  • Data exposure — does the API return more than the UI shows (over-fetching, hidden fields)?
  • Credential & token handling — how are Bullhorn dev/QA credentials scoped, stored, and rotated?
Bullhorn API
10 / 17
Regulatory alignment

California & New York privacy — checked against reality.

BART holds resumes and hiring feedback — personal information under state privacy law. We assess where the platform meets those requirements and where a buyer would want gaps closed.

California
CCPA / CPRA posture: notice, access & deletion rights, and reasonable security over personal information.
CCPA · CPRA
New York
SHIELD Act reasonable-safeguards expectations for private information held on residents.
SHIELD Act
Data lifecycle
Retention, deletion, and vendor terms across Google Cloud, Firebase, Bullhorn, and email.
PII handling
Privacy & regulatory · alignment, not legal opinion
11 / 17
The diligence angle

Vendor risk & liability — de-risking the acquisition.

A private-equity buyer is buying the platform and the arrangements around it. We read the developer relationship the way an acquirer's counsel would.

  • Delegated access — FYC Labs holds admin/deploy access as a vendor. Who can grant, revoke, and audit it after close?
  • Ownership — the contract assigns the custom work as work-made-for-hire; pre-existing tooling carries a perpetual license. We confirm that holds in practice.
  • Transferability — GitHub, GCP, Bullhorn, and domains sit in transferable accounts; we validate a clean handoff is real, not aspirational.
  • Liability — where the developer contract leaves risk with the buyer, in the context of the sale.
Vendor risk & liability
12 / 17
What you receive

Four deliverables the buyers can stand behind.

Executive Briefing
A plain-language read of risk for leadership and the deal team.
For decision-makers
Technical Findings
Severity-rated findings with evidence, reproduction steps, and remediation.
For engineering
Re-test
We verify developer fixes actually close the findings — not just claim to.
Verification
Attestation Letter
A signed statement of the testing performed — the artifact diligence asks for.
For the buyers
Deliverables
13 / 17
To start cleanly — customer obligations

What we need from AccruePartners.

  • Test accounts at each privilege level — client, internal, admin, and (where possible) developer, so every boundary can be exercised.
  • A technical point of contact available for questions during the assessment.
  • Testing windows & restrictions — any off-limits areas or maintenance windows, communicated in advance.
  • Timely decisions on issues that would otherwise block progress, and participation in the findings briefing.
What we need
14 / 17
Commercials
$9,000
Structure
Fixed fee — no hourly surprises
Terms
NET 30 — due 30 days after SOW execution
Expenses
Excluded — unless pre-approved in writing
Includes
Full test · re-test · attestation
Commercials
15 / 17
The path to attestation

From signature to sign-off.

01
Sign SOW
Countersign and we schedule.
02
Provision
Accounts at each privilege level.
03
Test
Recon → auth → access → API → logic → code.
04
Brief
Executive + technical findings.
05
Re-test
Verify developer fixes.
06
Attest
Signed letter for the buyers.
Next steps
16 / 17
Counter Measures Security

We find what
scanners miss.

RR
Robert RittichPrincipal · Cyber Risk Analyst · CISSP, CEH, CHPS
info@CounterMeasuresNow.com (610) 717-3947 CounterMeasuresNow.com