A lot of penetration testing I've seen has been black-box testing. In Agile teams, a lot of black-box testing moves to white-box testing. The nice thing about this is that white-box penetration testing can be more discrete, applied to each feature that the team develops and therefor it can be worked right into the sprint like any other type of discrete testing.
That being said, there is still an attack surface that exists when those features come together that can't be tested discretely and periodic broad-based penetration tests can still add value. I don't believe there is a hard rule about the frequency of those - you have to decide what is appropriate for yours.
As for the timebox and effort spent on results, I would never optimize for time on testing. I would always recommend optimizing for the level of quality appropriate to your application. Come up with a strategy that is needed for application and then it takes as long as it takes. Now, I can already hear the "that isn't the way the real world works" responses, but if your team doesn't have the time to reach the level of quality that your application needs, that is a completely separate conversation. Any gaps that are found should be judged based on their risk and potential impact and those deemed important to fix should be fixed, or the feature doesn't get released.
Edit: A point of clarification. Executing on a strategy carries with it an implicit timebox and in open-ended types of testing like exploratory testing, timeboxes still make sense otherwise they go on forever. My advise against timeboxes was more around close-ended testing (I need to test these X number of things).