This is why you keep your CI networks in a private VLAN with proxy servers back to the public Internet. You don't just stick your CI servers on your corporate network -- you park them behind a jump server and proxy back anything you need to.
For every project I've set up CI for, it doesn't matter if someone hacks my CI servers because they don't have access to anything other than dummy data. Sure; you could hack prod systems by building a trojan version of one of the binaries. But even then the binaries just get uploaded to a repository; so with proper code profiling and security testing you would notice the rogue binary before it ever hits a prod server.
It is important to keep CI as a dev process -- deployment should be handled by an orchestration system as it's much more of a tech ops process than a dev process. This is where config management and the like become very important; and those should be left to people who think like operations and security managers rather than hackers who just want to make shit work quickly (there's a place for both inside any good dev org).
Another good reason to keep CI locked out from other networks is to make sure all asset references are properly rewritten. Of summertime hard codes an open internet source or, even worse, an internal source, that will generate a 404 when testing, and any unexpected 404s in the log are instant test fails.
For every project I've set up CI for, it doesn't matter if someone hacks my CI servers because they don't have access to anything other than dummy data. Sure; you could hack prod systems by building a trojan version of one of the binaries. But even then the binaries just get uploaded to a repository; so with proper code profiling and security testing you would notice the rogue binary before it ever hits a prod server.
It is important to keep CI as a dev process -- deployment should be handled by an orchestration system as it's much more of a tech ops process than a dev process. This is where config management and the like become very important; and those should be left to people who think like operations and security managers rather than hackers who just want to make shit work quickly (there's a place for both inside any good dev org).