The canonical reference for this is [Community Initiative Proposal] Project Applications Process Revamp.
As of 2017/03/14, most of the plan has been implemented on the back-end, but some of the documentation still needs to be updated and there are still a few things that are being fine tuned.
To directly answer your question, the old Project Application queue is being repurposed as the Drupal.org security advisory coverage applications queue.
There is currently a documentation page about how to apply for permission to opt into security advisory coverage.
In short, you need to go through the application process where your project is reviewed. Instead of being allowed to promote your project (which you can now do on your own), a successful application will result in the applicant being able to opt-into security team coverage (the meaning of the "git vetted" role is being changed).
The process is essentially the same, and the security advisory coverage application checklist has been updated. The review admins will block applications on
- Licensing problems (including third-party code)
- Security problems
An application can be blocked on other items in the checklist at admin discretion.
You can go ahead an work on the issues in your project's issue queue. Make sure you follow best-practices as outlined in (the page I can't find about being a responsible maintainer). If you haven't already, then make sure you have an application in the queue, and reviewers will use the latest -dev version of your code for evaluation.
Just keep in mind that the process changes that were just done were to allow project promotion; there is a still the human factor (and backlog) for the manual reviews for the security opt-in.