When you use the Security editor via the SF menu, you will pick/create a project. The data is then stored in the SF database, using the project to keep things separate. When you update roles/permissions this way, you will then need to deploy the security data to your database.
The easiest way to do this is to use the DDT to manage it. However, I believe that if use it and have your security tables in your app database, you have to also use the DDT to manage deployment of your entire database (I think the newest versions allow for custom/non-DDT sprocs and views, but I think all tables still need to be deployed via the DDT). If is the case for you, then open the DDT and just redeploy the database. Typically, when you add the security tables to the DDT, it adds the appropriate data packages also, so it is a snap.
If you aren't using the DDT, it gets more interesting. If you use the security editor via VS or the SF menu to update roles, then you need to move the data out of the SF database yourself. I haven't done this...it just looked like too much fun and I have a weak liver
For more help on deploying security data, see the "Deploying Security Data" topic in the RBS section of the help file.
What I've done is a hybrid. I just have two databases: one for the app and one for security. That way I can use scripts to manage my app database and DDT to manage the security database. When I started, there were reasons I chose not to use the DDT for my application database, but if I were to start out now, those reasons have diminished a lot, so I might just use the DDT for both now.
However, you can make a call to the security dialog within an app and then it uses the security key to identify the appropriate data source that contains the SFS* tables for your app. You'd use a call like this within a project setup for security:
using (SecurityDialog loDialog = new SecurityDialog())
{
loDialog.ShowDialog();
}
See the "Calling the Security Maintenance Dialog" help topic in the RBS section of the help file for more info.
Even if you do this, you will still need to deploy the data from your dev environment to your test and then production environments. However, you could use this to skip the whole deployment thingy while figuring out the RBS at this stage.
Good luck!