This is about the details of security update package preparation. See DebianSecurity/AdvisoryCreation/DebDev for the business of actually fixing the code.
Preparing fixed packages
Patch the package. Use whatever patching scheme the package you're working on already used. If the maintainer didn't apply any patches apart from the debian/ subdir, just use the native package diff without adding any patch support to the build. If it used dpatch, cdbs, quilt, etc., stick with that.
Depending on how far from the upstream release the Debian release is, you may have to either rework the security fix, broaden it to cover more cases, or come up with an alternate approach. In most cases, the upstream fix (assuming there is one) will apply more or less cleanly.
Create a new package version based on the original version-release, appending "+debXu1" for the first (security) update in that distribution, "+debXu2" for the second, and so forth (make sure to base on the latest version either in the given relase or acked version by the stable-release-managers in the proposed-updates queue. If unsure ask first back). It must be greater than the current package, but less than package versions in later distributions. If you are updating oldstable and stable, always check the stable version is greater than the oldstable one. If in doubt, test it with dpkg --compare-versions. For example from 1.23-4 when making a fix for Debian Wheezy 7, use 1.23-4+deb7u1. Detailed information can be found in developer's reference.
Make sure the version you chose has never been used before. Even if the version was at some point in sid but gone now, you must not use it. Pay especial attention to this when the version is +nmuX.
The first upload (and only the first upload) of any given fixed package to the security build system should include the upstream source (e.g. dpkg-buildpackage -sa or pdebuild --debbuildopts -sa). Use rmadison to find out whether the source is already in the security build archive. Source-only uploads are ok.
If you have to upload which is new both for oldstable-security and stable-security and furthermore has the same orig tarball, special care needs to be applied when uploading the package. The first one you upload should be built with -sa to include the orig tarball. The second upload for the second suite then should not include the orig tarball in the upload.
Do your build in the distro you intend to fix (stable pbuilder or similar); be wary of introducing unintended dependency changes. You can easily check if a given set of packages would cause a breakage with 'would-break'. You can get it from git.debian.org (and its man page). Don't mix .changes files of different architectures, it won't work.
Testing fixed packages
There are two major things to test -- first, that the fix you've applied completely addresses the vulnerability (i.e. the exploit no longer works), and that you haven't introduced regressions. Non-hostile sample exploits may already be available, or in some cases (XSS attacks, e.g.) the attack is easy to reproduce.
no-dsa as a stable proposed update
If the issue doesn't worth a DSA Advisory (please, check this with the security-team) you should prepare an upload for stable-proposed-updates. You should send an email to email@example.com with the debdiff and ask for upload permissions. Read more about uploads to the stable and oldstable distributions at Developer's Reference, 5.5.1.
If the tracker doesn't reflect this situation (that the fix will be via spu), you should add in data/CVE/list something like the following lines:
CVE-2010-XXXX [Insufficient stripping of CR/LF allows arbitrary IRC command execution] - libpoe-component-irc-perl 6.32+dfsg-1 [lenny] - libpoe-component-irc-perl <no-dsa> (#581194)
and in data/spu-candidates.txt
libpoe-component-irc-perl (CVE if known) #581194 note about situation