Connector Laravel Package

Product Decisions This Supports

• Build vs. buy for the security-scanning layer. The decision it informs is not "should we scan PHP code" but "should we write our own client to the scanner's REST API, or adopt a pre-built wrapper." This package is the pre-built wrapper option, and its thinness is itself the argument: the integration surface is small enough to replicate in a sprint.
• Shift-left roadmap sequencing. If SAST gating in CI/CD is a roadmap item for a PHP-heavy codebase, this connector is the enabling piece that turns "we bought a scanner" into "every PR is scanned and blocked on findings." Without a connector, the scanner stays a quarterly manual exercise.
• Release-gate policy. Supports the decision to make vulnerability findings a hard merge block versus a dashboard-only signal. That's a product and process decision, and it requires programmatic scan triggering plus machine-readable results — exactly what this package exposes.
• Compliance evidence generation. For SOC 2 / ISO 27001 change-management controls, per-commit scan records are cheap audit artifacts. A connector makes this continuous rather than a scramble before the auditor arrives.
• Vendor consolidation. If the org is standardizing on Synopsys' portfolio (RIPS was acquired by Synopsys in 2019), this package supports the "keep the existing scanner, integrate it properly" branch of the decision rather than the "rip and replace" branch.
• Use cases where it earns its keep: legacy PHP audit for M&A or pre-refactor baselining, one-off due-diligence scans, and teams already holding RIPS licenses who need automation with minimal engineering spend.
• Non-decision: it should not drive a strategic commitment. With 4 stars and zero dependents, adopting it is not an ecosystem bet — it's a tactical shortcut.

When to Consider This Package

Adopt when:

• You already hold a RIPS license (on-prem or API) and the alternative is building and maintaining an HTTP client yourself.
• Your delivery stack is Composer/PHP-native and you want scanning invoked from the same tooling as tests and static analysis, not from a separate Python or shell orchestrator.
• You need something working this sprint rather than next quarter, and you're comfortable pinning, vendoring, or forking a small BSD-3-Clause dependency.
• The scan is advisory or single-purpose (an audit script, a baseline report) rather than a permanent, load-bearing stage in every pipeline.

Look elsewhere when:

• No existing RIPS relationship. Confirm the product's current commercial status before designing around it — the acquisition materially changed the standalone product's trajectory, and a connector to a deprecated API is a dead end regardless of code quality.
• You need a community safety net. No dependents and single-digit stars mean no downstream users to surface bugs, no security advisories, no maintainer pressure to keep pace with API changes. You are the maintainer, in practice.
• Multi-language scanning is on the roadmap. A PHP-only connector locks the scanning strategy to PHP; Semgrep, SonarQube, Snyk Code, and CodeQL all emit SARIF and slot into language-agnostic CI gates with far more leverage per integration.
• You want native PHP analysis without a vendor. Psalm's taint analysis and PHPStan's security rules run in-process, need no API credentials or network egress, and are already in most PHP CI setups.
• You need SLAs, support contracts, or a named escalation path. None of that exists at this adoption level.

How to Pitch It (Stakeholders)

To executives — frame it as a tactic, not a strategy. "This lets us run automated PHP security scans on every commit instead of a periodic manual review — faster feedback, auditable records, and no new headcount. The caveat is proportionality: the package has effectively no user base, so we should treat it as glue code we own rather than a supported dependency. Worth a small pilot; not worth a platform commitment."

To engineering — be honest about the work. "It's a thin HTTP client over the scanner's REST API with an auth and request layer. Budget roughly half a day to read it, pin the version, and vendor or fork it if we go ahead. The real integration effort is in result parsing and threshold policy, not in the connector. If we're not already a RIPS customer, we should evaluate Semgrep or Psalm taint analysis first — they give us SARIF output and a real maintainer community."

To security and compliance — lead with the outcome. "Every commit gets a scan record and a pass/fail gate, which gives us continuous evidence for change-management controls instead of a pre-audit fire drill. We control the scanning policy and the failure thresholds in our own CI config."

To finance or procurement — use the low adoption as leverage, not a red flag. "Adoption cost is near zero because switching cost is near zero. That cuts both ways: cheap to try, cheap to abandon. Cap the commitment at pilot scale until we've confirmed the scanner's support roadmap."