Your own code
Rules written by Visiminds look for weaknesses in your code. Some follow untrusted data, within one file, from where it enters to where it is used.
Code and app security on your own machine
Checks the code you build
Ivy Lens finds the weak spots in the code you build, the packages it uses and the Android or iOS app you ship. It runs on your own computer, and your code is never sent to a cloud.
For teams that build software and mobile apps, and for organisations that must keep their code on their own machines.
Ivy Lens in numbers
893rules written by VisimindsMost are security rules. A few are for code quality.
100languages and platforms recognised34 of them with 10 or more security rules
27standards and frameworks explained
58mobile app checksin 10 analyses
Read from Ivy Lens on 9 October 2026.
What one scan checks
Ivy Lens has two scans. Code Scan checks the first seven parts below. Mobile Scan checks the app build. You choose which parts run.
The packages you use
Each open source package (Code that others write and share openly, and that your software uses.) is checked for known weaknesses, with the version that fixes them. Ones attackers already exploit are rated at least high and lead the fix list.
A list of every part
The scan lists the parts your software is made of, with their versions, as a CycloneDX (The OWASP standard format for a software bill of materials.) software bill of materials (SBOM) (Software bill of materials. The list of every part your software is made of, with versions.). All three presets include it.
Passwords and keys
Files in any language are read for secrets (A password, key or token that gives access to a system, left in a file by mistake.), apart from folders named node_modules, dist, tools, work and .git. Archives inside the code are not opened. Ivy Lens never sends a secret anywhere to test it.
Server and cloud setup files
Terraform, Kubernetes, Helm and Dockerfiles are read for risky settings, such as a container (A packaged program that runs apart from the rest of the machine, with everything it needs inside.) with full rights on its host.
AI agent instruction files
The files that AI coding assistants follow are read for wording that weakens a safety rule, such as "ignore previous instructions".
Code quality
A maintainability grade (A grade from A to E for how easy the code is to change safely.) from A to E, and the technical debt (The estimated time to fix every open finding, worked out per finding and added up.) in days. The report shows how the technical debt is worked out, and the measures behind the grade.
The mobile build
The Android or iOS app you ship, even without its source code.
A closer look
Secrets, shown masked
A password or key found in the code shows only its last four characters: in the finding, in the code lines around it, and in every report. Ivy Lens never sends a secret anywhere to test it.
Packages attackers already use
Several checks read the same packages, and a weakness they agree on counts once. A package on the known exploited list is rated at least high and sorted first.
Instructions for AI agents
The instruction files of AI coding assistants are read line by line for wording that weakens a safety rule. No AI model runs, so the same file always gives the same result.
A list of parts, checked offline
The list of parts is matched against vulnerability data on your own disk. To refresh the data, an archive is made on a connected machine and carried across.
How Ivy Lens checks
Checked against the code
Scanning tools often report false positives (A finding that is reported but is not really a problem.). Ivy Lens reads each finding against the code before it counts it. No finding is removed on a guess, and every change is written down with its reason.
Measured by Visiminds in September 2026:
- One Python service: 443 findings reported, 178 kept. Most of the removed findings were attributes that a rule took for methods, errors that the code logged and then passed on, and duplicates.
- A test project full of real weaknesses: 30 reported, 26 kept. Four duplicates were merged, and nothing was dropped.
Your code never leaves your machine
No scan that Ivy Lens offers opens a network connection, and your code is never sent to Visiminds or to a cloud. There is no telemetry (Usage data a tool sends back to its maker.): nothing is sent back to Visiminds. The credits each scan uses are recorded in a ledger on your machine, and that ledger leaves it only in a true up report that you send.
There is no AI model in the scan, so the same code, with the same settings and vulnerability data, gives the same result.
- The full PDF and HTML reports print the date of the vulnerability data, so you know how current it is.
- You can check this yourself: run a scan with the network switched off, or watch the traffic while it runs.
A report for each reader
Each scan writes three reports from the same data: for developers, for the security team and for management. The totals are the same in all three.
- Developers see the fastest fixes first: critical, high and medium findings that take 30 minutes or less to fix.
- The security team gets a ranked list, with the reason for each finding's rank. A finding moves up when attackers already exploit it, when the code can reach it, or when two tools agree.
- Management gets about three pages, with the decisions to make, such as holding a release or accepting a risk in writing.
- From the second scan on, Ivy Lens names the findings that are new, fixed and still open.
Also from each scan
- Full PDF report
- HTML
- Excel
- SARIF (Static Analysis Results Interchange Format. A standard file format for analysis results that editors and build systems can read.) for code editors
- JSON (A plain text file format for data.)
- Threat model PDF
Ask this scan
Ask a question in plain words, such as what to fix first. The answer comes from the scan's own data and a guide built into the product, with links to the findings it used. No AI model runs.
False positives, decided in groups
Findings from one rule with the same shape of code are grouped. A reviewer writes one reason and decides for the group. The report lists each decision, with who decided and when.
Scan over scan
From the second scan on, each scan names the findings that are new, fixed and still open.
Check it yourself
Switch the network off and run a scan, or watch the traffic while it runs. The findings still arrive.
From findings to decisions
Ivy Lens also turns its findings into a threat model (A list of what could go wrong in a system: its parts, the boundaries between them, and the threats against each, with how serious each one is.), a view of the risk and a plan for the technical debt. Fixed rules do this work on your own machine. People make the decisions.
A threat model from your code
Ivy Lens reads the code and the design files your team keeps: an intake file, API (Application programming interface. The interface one program uses to talk to another.) descriptions, threat model files, architecture diagrams and decision records. It draws the system with its trust boundaries (Where data passes from something you do not control into something you do.), and marks where each part came from.
Each threat is seen in the findings, seen in the design, or proposed as a candidate. A candidate counts in no total until a reviewer rates it.
- A detailed data flow diagram (Data flow diagram. A drawing of the parts of a system and the data that moves between them, with the trust boundaries the data crosses.): every part and flow keeps its file and line, each flow its protocol, the data it carries and whether it is authenticated, and rules flag the evidence gaps, such as an internet facing route with no sign-in check.
- Each threat shows how likely it is and how much harm it could do, the controls already in place, and the risk that is left (The part of a risk that is left once the controls in place are counted.), now and after each way to reduce it.
- The controls are mapped to NIST SP 800-53 (A large catalogue of security and privacy controls from the US National Institute of Standards and Technology.) and ISO/IEC 27001 (ISO/IEC 27001. The international standard for an information security management system.).
- Your team accepts, rejects and re-rates each threat in the web interface, and chooses how to reduce it. A named person signs the model off.
- Ivy Lens measures the time from the scan to the sign-off, and compares it with your team's own earlier reviews.
A technical debt plan for each release
For teams that repay technical debt in every release. Ivy Lens shows the debt by module and by owner, the few rules behind most of it, the to-do notes left in the code, and the debt added and repaid since the last scan.
- A plan for this release that fits the time your team has.
- A build gate (A check in the build that stops it when a result passes a limit you set, such as new technical debt.) can stop any build that adds new debt.
Cyber Risk Intelligence
Findings are grouped into issues, one for each underlying problem, and into themes for management, with the reason for each group.
- The risk now, and after each recommended action.
- Each action shows how much risk it removes, the effort, what it depends on and its business impact.
- Fixed rules write the insights for management from the figures. No AI model is used.
- You can go from the whole portfolio down to one finding.
- A command also reads the CSV (Comma separated values. A plain text table, one row per line, that any spreadsheet can open.) exports and SARIF files of other tools.
India's DPDP Act
Findings are mapped to India's DPDP Act (Digital Personal Data Protection. India's law on personal data in digital form: the DPDP Act, 2023, with the DPDP Rules, 2025. It sets duties for the organisations that use personal data, and rights for the people it is about.), 2023 and the DPDP Rules, 2025. The scan also lists the personal data it finds in the code.
- The mapping covers the sections a code scan can speak to, such as the security safeguards.
- Duties a code scan cannot assess, such as consent and notices, are listed as not assessable from code.
Explain beside every figure
The security score, the risk now and after the plan, each risk issue and action, the technical debt and a finding's priority each have an Explain button: the formula, the inputs and where each came from, and for a risk the likelihood and the impact.
Confidence on every issue
A confidence level and score on the scan, each risk issue and each theme, with the reasons, such as how much of the code had rules and whether tools agree.
Two views, then the detail
The scan opens on its headline figures, with an executive view and a developer or owner view. "Ask how to fix this" on a finding asks Ask this scan about it.
How it is installed and licensed
Installed on your own machines
Unpack one package and run one setup script. Each package carries its own tools and vulnerability data, so setup needs no Docker and no internet connection.
Run it on one computer, or on a server your team shares. There is no cloud version.
To update the vulnerability data, a new archive is made on a connected machine and carried across by hand. This also works on an air gapped (A machine or network with no connection to the internet at all, usually on purpose.) network.
- Systems
- macOS, Linux and Windows
- Processors
- x86 and ARM (A family of computer processors, used in Apple silicon Macs, in phones and in many servers. The other common family is x86, used in most Windows and Linux computers.), on each system
- Optional
- A container bundle for Linux and macOS
Licensed by use, not by seat
You buy prepaid credits (The units a scan is paid with. You pay for the scans you run, not for each user.). An estimate of the price is shown before a scan starts, and a large codebase adds credits for its size when the scan finishes. A scan that fails is never charged. Credits do not expire, and they are counted on your own machine, with no licence server.
Adapted to your needs
Rules, reports and mappings can be adapted to your needs, and to the regulations of your country or region.
Mobile Scan: the app you ship
Code Scan reads the source a team wrote. Mobile Scan reads the file a person installs.
Reads the build, not the source
Add an Android .apk (Android package. The file an Android app is installed from.), .aab or .aar file, or an iOS .ipa (iOS App Store Package. The file an iPhone or iPad app is installed from.), .framework or .xcframework, to a scan on your own machine. Mobile Scan opens it with its own readers. It needs no source code, and no Android or Apple developer tools.
Findings are mapped to OWASP MASVS (OWASP Mobile Application Security Verification Standard. The list of controls a secure mobile app should meet.) 2.1, to the OWASP mobile testing guide (MASTG) and to the OWASP Mobile Top 10.
- Nine analyses work on Android and iOS. Decompiled code is Android only, and runs when you choose it.
- It looks for eight protections an app can have, such as root detection (Code in a mobile app that notices when the phone's built-in protections have been removed.), and says how sure it is of each.
- Parts inside the app with a known version are checked for known weaknesses.
The 10 analyses
- Manifest and configuration
- Transport security
- Data at rest and logging
- Cryptography
- Secrets and endpoints
- Third party components
- Binary protections
- JavaScript bundle
- Permissions and privacy
- Decompiled code
Standards, explained
Your developers and your auditors can read each finding in the standards they already use.
One finding, many standards
Each finding is linked to its weakness type in the CWE (Common Weakness Enumeration. The common list of software weakness types.) list. From there, Ivy Lens maps it to the OWASP Top 10 (OWASP's list of the ten most critical security risks to web applications.), the CWE Top 25 (The 25 most dangerous software weaknesses, ranked each year from published data.), MITRE ATT&CK (MITRE's catalogue of what attackers do, grouped by their goals and their methods.) and MITRE D3FEND.
For the OWASP lists and the CWE Top 25, the report shows every entry, including the ones with no finding, so an auditor sees what was checked.
For India's DPDP Act and the DPDP Rules, 2025, findings are mapped to the sections a code scan can speak to. The duties a scan cannot assess are listed too, so the table shows the whole Act.
Other standards are explained for reference, so your team can read them in one place. The mapping is Visiminds' own: it is not a statement of compliance.
| Category | Standards and frameworks |
|---|---|
| Application security | OWASP Top 10 |
| Mobile application security | Mobile Top 10, OWASP MASVS, OWASP MASTG |
| Weakness taxonomy | CWE Top 25, CWE |
| Adversary behaviour | MITRE ATT&CK, MITRE D3FEND |
| Software supply chain | CVE (Common Vulnerabilities and Exposures. The public identifier for one known vulnerability in one product.) and CVSS, EPSS (Exploit Prediction Scoring System. A daily score for how likely a vulnerability is to be exploited in the next 30 days.), CISA (Cybersecurity and Infrastructure Security Agency. The cybersecurity agency of the United States. It publishes the list of known exploited vulnerabilities.) KEV (Known Exploited Vulnerabilities. CISA's list of vulnerabilities that attackers are known to have used.), CycloneDX SBOM, SPDX, SLSA |
| Interchange format | SARIF |
| Code quality | ISO 25010, ISO 5055, Cyclomatic complexity |
| Assurance and compliance | NIST SSDF, OWASP ASVS, PCI DSS 4.0, DPDP Act |
| Artificial intelligence security | OWASP LLM Top 10, MITRE ATLAS, NIST AI RMF |
| Threat modelling | STRIDE (Spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. The six kinds of threat used in threat modelling.), DREAD |
Languages and platforms
Ivy Lens recognises 100 languages and platforms. Recognising a language is not the same as checking it, so both are shown.
With static analysis
These 34 have 10 or more security rules each:
- Android
- Go
- JavaScript and TypeScript
- Java
- Python
- Kotlin
- C# and .NET
- PHP
- Ruby
- Chef
- C++
- C
- Scala
- Swift
- iOS
- Rust
- Groovy
- Terraform
- Elixir
- Shell
- Dart and Flutter
- Helm
- Kubernetes
- Lua
- HTML
- HTML template languages
- PowerShell
- SQL
- nginx
- Docker
- Jenkins
- Solidity
- AWS CloudFormation
- Azure Bicep
Another 13 have a few rules each. The number of rules for each language is published, so a clean result for a language with few or no rules is not mistaken for a thorough check.
The checks for secrets and packages do not depend on the language. Packages are checked from the manifest (The file that lists the packages a project needs, such as package.json.) and the lock file (A file that records the exact version of every package a project uses.).
Ask for a demo of Ivy Lens
Write to info@visiminds.com. Tell us which languages your code uses, and whether your machines have an internet connection. A sample report is also available on request.