IV Security Clarification After doing lots of reading on SO and other websites relating to AES cryptography, I am trying to understand the security issues surrounding IV's.

There seems to be a lot of confusion and contradiction surrounding this subject. 

Many say it is safe to publish the IV as it is not a secret whilst others say it should be kept safe AND a secret, as this translates to the starting point for the AES encryption engine using CBC. Without the IV, the decryption of the cipher block will corrupt, so by default shouldn't this add security by keeping it a secret?

Could somebody please help me understand, finally, what the official standpoint is regarding the IV so I don't release my cryptography software with a huge gaping hole in it. 

The way I see it, if the IV is the initialiser for the AES engine, surely if a cryptanalyst knows this it will give him a starting point for attacking the cipher text? On the same note, if the IV was kept a secret the cipher text would be even harder to attack as every encryption of a given string (or file) using an IV would produce a completely different cipher block and no 'starting point' is known.
Keeping the (initial) IV secret only adds security for the first block of your cipher text. The IV for the second block is by definition the first cipher text block, and so on. So if we would have the key but not the initial IV, we could decrypt the whole ciphertext except the first block. So it doesn't add much security, but it does add "management", as you do need to communicate the initial IV to any party you wish to be able to decrypt. 

So normally the IV is just prepended to the cipher text and not kept a secret. This is no problem as long as the IV is random and non-predictable for every message or file we encrypt with that key. CBC in this mode has a standard security proof (for privacy only, of course, as we do not have integrity checking).

Another option is to have an implicit IV that depends on key material (that the recipient should know anyway to be able to decrypt), using hashes or other pseudorandom functions. This is done in some standards. This saves the 16 (if that is the block size) bytes expansion for explicitly prepending it. It adds some complexity, and expansion is not really an issue these days for things like file encryption. I would avoid it.