Hello! I was wondering if CircleCI would help assure the code that was deployed is the exactly the code that lies on a repository/branch.
For my organization, we need to let people easily check that the code that is viewable on GitHub is the code that is running in the server, as we need to provide transparency in that sense.
It certainly could do, but not any more than any other CI provider. I assume you would want to do this from an auditing perspective.
To my mind, it depends on what assurances an auditor would need. For example, if you write some software to help them verify that a deployment is an accurate reflection of a branch, then they would need to trust your code. If they are willing to do that, then great - if not then you might have to have a conversation with them about what baseline they are willing to trust.
A simple version would be a deployment system that checks out a Git repo at a specific tag, does an automated build, pushes it to a staging area, and waits for your authorisation to run migrations and deploy. Then it would hop to a waiting state for your authorisation on migrations and deployment to live. That is an auditable system where you could keep the logs in Circle and GitHub to show there was minimal capacity for code tampering, but you would need to get buy-in from the auditor (or whoever) to see if that would satisfy them.
You could expand this to add API endpoints in your application to hash the project files in a set of application directories, but an auditor would need to see your hashing code to ensure it is not giving faked responses. 
Thanks @halfer.
Actually, the whole point, just to give you more context for my post, is that any technical person could easily verify that the latest code was deployed, at least from a publicly accesible page from CircleCI.
That is because I’m in charge of a new political party in Uruguay based on ICT that relies solely on open source. And in order to promote transparency, and to assure that the available tools are working as expected in production without any data tampering, we need something that could provide that level of transparency between code and deployment.
As the open source tools available are going to be crucial for our political activity, gathering proposals and letting people vote for them to then notify our representative on how he/she should vote in the corresponding entity, trust is very important.
I was thinking that maybe using signed Docker images that can be published using the latest code could help, which involves a tool like CircleCI to build it.
Hi Leo. That sounds like a neat use case! I’m not quite sure I fully understand it, so rather then mix it up, can I ask you to post it at a new feature request here https://ideas.circleci.com/ ?
Thanks!
It sounds fascinating, and I think it is also a very hard problem to solve.
That your work would be open source is certainly part of the solution, since your code can be shown publicly on GitHub and your builds can be shown on CircleCI publicly. You could use that code to push to a cloud provider, but you’d need to demonstrate that the build output was a genuine expression of what had been deployed.
Of course, it also depends on who you trust, which can be determined by a threat analysis of your problem (who would subvert your code? why would they do it? how powerful or well-funded are they?). For example, AWS has strong ties to at least one large government apparatus, so if you deploy on AWS you (and anyone analysing your security) would have to trust AWS implicitly. Would they?
After the Diebold experience in the US, I am mostly suspicious about any electronic voting systems. However, people who want to use technology to carry genuinely even-handed democratic expression tend to look at digital signature mechanisms to prove that the voter is who they say they are.
Also, I appreciate every hipster and their expensive chiahuahua are talking about blockchains at the moment, but from a verifiability perspective, it may be worth looking into. Decentralised data is very hard to corrupt without detection.