After some research we were able to identify where this particular master asset had been used and created a database script to remove the real user's information from all instances where it had been implemented. The next step will be to create a new policy and process governing the creation and use of master assets so that this sort of thing doesn't happen again. We'll also conduct audits of the other 20 or so master assets to ensure there aren't any real data contained within them.
The second vulnerability was discovered by a security engineer for one of our customers who was interested in using our application programming interface to automate some reporting. His company's policy is to assess any API used for business purposes, and his assessment led to the discovery that by changing a value in a standard request, he could obtain data from another account within the application. A standard application assessment would not have discovered this vulnerability, since a similar request is not available through the normal user interface.
This was quite embarrassing, and led us to the realization that we haven't spent enough time assessing the security of our API. In response, I modified our vulnerability management program to include a regular internal and third-party assessment of our API.
As you can see, vulnerability management needs to include any area of an organization that has the potential to be compromised.