get_security_scanLABSCO SUMMARY
The security review moves to where the code is written, not to where it is merged.
Assistants generate more code than anyone reviews, and the gap between generation and review is where the injection flaw lives. Putting the scanner behind a tool call closes it: the assistant writes, scans, reads its own findings and rewrites, before any of it reaches a branch. The browser-testing half is the same instinct pointed at behaviour — record what a flow should do, and let the assistant find out the moment it stops doing it.
What it is
A server that gives an AI coding assistant a security pass over its own output. It runs static analysis with Semgrep and dynamic checks with tools such as Nuclei or ZAP against running components, and returns each finding with its vulnerability class, its location in the code, a severity, the evidence and a suggested remediation — in a shape the assistant can act on rather than a report a person has to triage. The same server also records browser tests from a description in words, replays them deterministically with Playwright, and heals them when the page changes underneath.
What you get
- A security scan of code an assistant has just generated or changed, returning vulnerability class, location, severity, evidence and a suggested fix
- A browser test recorded from a description in plain language, saved as a replayable file
- Recorded tests re-run on demand, with failures, screenshots and console logs returned to the assistant
- Test steps discovered by crawling a site, suggested per page
- The tests already recorded, listed
- Tests that repair themselves as the code changes, and assertions Playwright cannot express directly, such as whether text is overflowing its container
- Visual regression checks, by pixel comparison and by a vision model
Setup effort
Build from source — git clone https://github.com/GroundNG/VibeShift
USE CASES
01
Checking the code the assistant just wrote
Run the scan over the new code and get findings back with class, location, severity and a suggested fix, in a form the assistant can act on without you relaying it.
02
Turning a flow you described into a test
Describe the steps in words once; the agent drives the browser through them and saves the result as a file you can replay.
03
Catching a regression before you push
Replay a recorded test and read back the failures, screenshots and console logs — the tests heal themselves when the page changes rather than needing a manual update.
04
Working out what is worth testing on a site you inherited
Crawl from a starting URL and get suggested steps per page, instead of writing the first test suite from a blank file.
05
Seeing what coverage already exists
List the recorded tests before writing another one that does the same thing.
5 tools
Listed in project docs. Your client may show a different list.
record_test_flowrun_regression_testdiscover_test_flowslist_recorded_testsBEFORE YOU INSTALL
What to know first
Tools you get
5 tools named in the project's documentation.
Requires
- uv on PATH
- Python 3.10+
- LLM_API_KEY in your environment
Where it runs
All 3 documented clients run the server on your machine.
INSTALLATION
Connect your client
Server setup
TERMINAL
git clone https://github.com/GroundNG/VibeShift
cd VibeShift
pip install -r requirements.txt
patchright install --with-depsRename .env.example to .env in the project root and set LLM_API_KEY="<YOUR_LLM_API_KEY>" to your LLM API key
In the configuration below, <YOUR_PATH_TO_CLONED_REPO> is the folder you cloned
MCP Clients
Cursor, Windsurf, Roo Code
JSON
{
"mcpServers": {
"VibeShift": {
"command": "uv",
"args": [
"--directory",
"<YOUR_PATH_TO_CLONED_REPO>",
"run",
"mcp_server.py"
]
}
}
}The configuration does not set LLM_API_KEY; the server reads it from the .env file in the cloned folder (see the steps).
