> I would guess the OPs concern is inadvertently providing access to entities other than Github.

Well, yeah, sure.

> If you polled from the inside then you could be sure that the only thing you would need to worry about is how the data that is pulled down from Github is parsed because you are not providing access to anyone at all, including github.

That's a highly confused way of looking at things.

Whether you consider a process "pulling data" or "receiving pushed data" is ultimately entirely arbitrary. You can view any "push" as a "pull" and any "pull" as a push if you shift perspective slightly.

For some reason you decide to use a push configuration. How do you do that? You create some address where data can be delivered to. And then you inform the potential source of the data about that address, so it can push the data to you. So, really, you are just sending a request to send you the data, i.e., you are obviously pulling, right?

OK, say you don't like a push setup, so, let's say you send an HTTP request to a server in order to pull some data? Well, yeah, sure you do. But then, really, you are just creating a multiplexing identifier that allows you to receive data and you inform the HTTP server about that address, namely a TCP four-tuple plus sequence numbers, which the server can use to subsequently push the object to you.

Mind you, I am not just playing with semantics here: Anyone who knows the address that you submit to the "pushing" side can send you data, in both cases. Well, not quite as easily with the TCP connection state, as you have to fake IP addresses for that, but that's not really a huge barrier. The underlying layers give you no guarantee at all that the data you receive on an outgoing connection comes from the entity that you intended to connect to, that's just an illusion.

So, what do you do? You authenticate. You use TLS, you use SSH, you use keys and certificates, to cryptographically authenticate that the data that you receive is indeed coming from the entity that you want to accept it from, and anything that isn't authenticated successfully, you drop on the floor. Whether you do that on an inbound or on an outbound connection is irrelevant. And if you fail to do it in either case, you have a security risk.

Essentially, the idea that you aren't "providing access to anyone" is an illusion. When you can receive data from someone, you are "providing access" on some level, and when you pull data via HTTP from github, they obviously can send you data in response--and, as we have seen, others can as well, so you can't even be sure you are getting the response from github. That is, unless you authenticate cryptographically that it indeed does come from github--but then, there is no reason you couldn't do the same on an inbound connection.

Pull and push only have a useful meaning in terms of scheduling, but that has nothing to do with security: A pull is when the requested data is pushed as an immediate response to the request, while a push is when the requested data is pushed in response to an event external to the established link. See also HTTP long polling (outbound connection used for "push" from the server) or SMTP TURN (inbound connection used for "pull" from server).