Its also worth noting that, because you ran DBCC CHECKDB on a secondary to offload and it didn't presented corruption, it doesn't mean you don't have corruption on the primary database.
It just tells you that your secondary isn't corrupted, doesn't tell you about the primary, i think i heard these words off from Gail Shaw once.
The only way it might work is if you are using some sort of SAN Snapshot copy of your database, in our case we have a SAN and we make snapshots of the databases, we restore these snapshots and these snapshots use the same blocks that are being used in the SQL Server production environment, that might help you with the PHYSICAL part of the database, there's also corruption at the memory level and the SAN doesn't help you with that case.
The best way is to make the DBCC Checkdb on your primary database to make sure you don't have corruption on that one.
Also, today i got the daily mail from SQLSkills and whenever i get the email, the part im most excited off of it is "The Curious Case of..." it's usually stories from customers or questions they ask Paul Randal and he make blog posts regarding these topics.
The Curious Case of… whether corruption can propagate to secondary databases