Is that security fix really working? Cyfendo founder Bryan Vuong explains what to check

Sponsored content
This Q&A is sponsored by Cyfendo.

AI tools can help businesses write software, but a working application can still contain security flaws. When a scanner flags a problem, someone has to establish whether it is exploitable, decide what to change, and check that the repair works without breaking something else.

I put eight questions to Bryan Vuong, founder and CEO of Cyfendo, about how small and medium businesses can approach that work. In his written responses, he explains what evidence to ask for, why an unsuccessful test does not necessarily establish that code is safe, and where human judgment remains necessary when security tools suggest changes.

The conversation also covers access controls, the risks of giving tools broad permissions, and practical steps small and medium businesses can take this month. His false-positive example below is illustrative rather than a specific customer incident.

Brian Fagioli: Where is the biggest gap between identifying a possible vulnerability and proving that it is a real risk?

Bryan Vuong: The biggest gap is context. Finding suspicious code is one step. Establishing whether an attacker can reach it, control the relevant input and cause an unauthorized outcome requires understanding how the application actually works.

For example, a database operation might look dangerous in isolation, but a protective control elsewhere could prevent the suspected attack. Conversely, an invoice download feature might look completely ordinary while allowing one customer to access another customer’s records.

For a small or medium business, that gap becomes a staffing problem. Someone must investigate the warning, establish its impact, work out a fix and check the result. Producing more warnings does not necessarily reduce that workload.

I think the most useful security tools will increasingly be judged by how much of that investigation they help complete, and how clearly they explain the evidence and remaining uncertainty.

Brian Fagioli: What evidence should a business require before treating an issue as a confirmed vulnerability?

Bryan Vuong: I would ask for four things:

• The affected path: Where does the untrusted input enter, and how does it reach the sensitive operation?
• The conditions: What access, configuration or permissions does the attacker need?
• The security impact: Can someone read another customer’s information, change something they should not control, or execute an unauthorised action?
• The supporting evidence: A safe, repeatable demonstration where appropriate, or sufficiently clear technical evidence when execution would be unsafe or unnecessary.

The report should also identify the code version and test environment. A vulnerability demonstrated in a controlled environment still needs its production exposure assessed.

A severity label or an AI-generated explanation is not enough by itself. Equally, businesses should not delay urgent containment while waiting for an elaborate demonstration. An exposed live credential, for example, should be revoked promptly.

The objective is evidence proportionate to the risk, not a dangerous proof at any cost.

Brian Fagioli: Can you walk through a false-positive example?

Bryan Vuong: I’ll use an illustrative example rather than present this as a specific customer incident.

Imagine a customer search function that passes a search term through several helper functions before querying a database. A scanner flags possible SQL injection because user-controlled input reaches a database operation.

On closer inspection, the final helper uses a parameterized query: the query structure is fixed, and the search term is supplied separately as a bound value.

In a controlled test, we would examine that final database call and exercise the relevant path with ordinary and deliberately malformed inputs. The evidence we want is that the input remains data and cannot alter the query’s structure.

If that is established, the specific injection warning can be dismissed for that path. But “we tried an attack and nothing happened” is insufficient: the test could have missed the relevant branch or failed before reaching the database.

And dismissing the injection warning says nothing about whether the search function enforces customer access permissions. That is a separate question.

Brian Fagioli: How should a team verify a fix, and what regression checks matter most?

Bryan Vuong: Preserve the original reproduction as a test. Establish that it demonstrates the problem before the change, then repeat it after the change under equivalent conditions.

The attack should fail because the underlying weakness has been corrected. If it fails because the endpoint now crashes, the database is unavailable or the test account cannot log in, that does not demonstrate a successful fix.

Next, check that legitimate behaviour still works. For a customer-record access issue, I would test that a customer can access their own records, cannot access another customer’s records, and cannot bypass the restriction through a related endpoint. Staff access should follow the intended permissions too.

For an injection fix, test ordinary inputs, edge cases and relevant application workflows alongside the security test.

Finally, keep those checks in the automated test suite. A fix is more valuable when the team also gains a reliable way to detect the same mistake returning.

Brian Fagioli: Which security mistakes in AI-built applications should small and medium businesses prioritize?

Bryan Vuong: The categories I would prioritize are missing server-side access controls, exposed credentials, unsafe handling of untrusted input, overly permissive storage or service settings, and vulnerable dependencies.

These are not exclusive to AI-generated software. The concern is that code can now be produced and connected faster than a team can examine its security assumptions.

A working login page is a good example. It establishes who a user is, but the application must still decide which records and actions that user is allowed to access. A convincing interface can conceal a serious permissions problem.

For prioritization, ask: Can an attacker reach this? What could they access or change? How much privilege would they gain? Is there evidence of active exploitation?

An exposed credential or a reachable flaw exposing customer data should generally take priority over a speculative warning in an unused component. The business needs an ordered response based on exposure and consequence, with an owner for each important issue.

Brian Fagioli: How does Cyfendo approach verification and fix validation?

Bryan Vuong: Cyfendo analyses source code to find potential vulnerabilities, investigates whether they can be exploited, and generates proposed fixes for developers to review.

It traces how untrusted inputs reach sensitive operations and, for findings it can validate through execution, tests the relevant behaviour in an isolated environment. After proposing a patch, it retests the original issue and runs available project tests to check for regressions.

Developers can review the evidence behind the finding, the proposed code change and the test results. The practical goal is to reduce the investigation and repair work that would otherwise fall on the development team.

Human judgement remains essential. Developers understand the intended business rules, assess whether the change is appropriate and decide whether to accept it. Cyfendo does not automatically merge fixes into production.

There are also limits. Not every finding can be reproduced automatically, and source code alone may not reveal production configuration or every business-logic issue. Passing the available tests does not prove the entire application is secure. An inconclusive result must remain inconclusive.

Brian Fagioli: What should organizations consider before giving an AI security tool access?

Bryan Vuong: Treat a security tool as another supplier with access to sensitive systems.

Start with the minimum permissions required. If the task is source-code analysis, ask why production credentials or broad write access would be necessary. Restrict access to the relevant repositories and use scoped, revocable credentials.

Ask where code is processed, which external providers receive it, whether it is used for model training, how long it is retained and how deletion works. Logs and vulnerability reports also deserve protection because they can reveal sensitive implementation details.

For testing, use isolated environments and synthetic or appropriately sanitised data wherever possible. Any system that executes project code should have controlled network access and no unnecessary production secrets.

Also examine what “local” means. A tool running on your laptop may still send code to an external model provider.

The organisation should be able to explain what it has shared, with whom, for what purpose and how that access can be withdrawn.

Brian Fagioli: What three steps should small and medium businesses take this month?

Bryan Vuong: First, identify the software that matters most and name an owner. List the applications that handle customer information, payments or business-critical operations. Record where the code lives, who maintains it and who has administrative access. Check for exposed secrets and unnecessary permissions.

Second, examine one important customer journey. Choose something concrete, such as logging in, downloading an invoice or changing account details. Combine code analysis with controlled testing of the permissions and data handling. Ask for evidence that explains what could go wrong and under which conditions.

Third, take a confirmed high-priority issue through fixing and retesting. Apply the fix, rerun the original security test, check legitimate behavior and retain a regression test. Add appropriate checks to future code changes so the exercise becomes a repeatable practice.

If no such issue has been confirmed, add a regression test for a critical security control, such as preventing one customer from accessing another customer’s records.

A small business does not need to solve every security problem in a month. It can establish ownership, understand its most important exposure and demonstrate that a meaningful improvement actually worked.

---

About Bryan Vuong

Bryan Vuong is the founder and CEO of Cyfendo, an application-security company helping small and medium businesses investigate vulnerabilities and evaluate fixes. He previously held engineering leadership roles at Google and Meta and holds a PhD in Computer Science from the University of Wisconsin-Madison.

---