Depends on how you build it. Either use AABBs like haegarr mentioned, or if you want rotated bounding boxes (probably mostly used in hitboxes) I would simply have a class that contains the model and its orientation, location and scale, and use that to set the state of both the GL objects and the Bounding box. That way you have logically seperated the two very different types of functionality, and you ensure that you're always running your calculations in the correct space.
I had considered this, but if I were to generate the bbox, and then apply the transformation/rotation/scale to it manually, a rotated model, would result in a rotated bbox. I was under the impression that this was bad practice. Unless I am mistaken.
Alternatively, I could use the apply the matrix to the points in the model, and then calculate a bounding box, but since applying rotation requires trig, and it would be run on every single vertex on every model, each frame, I imagined it would absorb ridiculous resources. Again though, I could be mistaken here as well.
A sensible approach, and it'll help simplify collision detection as checking for intersection with a sphere is trivial.
A bounding sphere may be an option for you here. It will certainly be easier to calculate - just position it's center at the object's position and calculate the radius from the object size and largest scale factor, done - no need to bother with rotations. They're also faster to test against the frustum, but the tradeoff is that a sphere may not be an optimal shape for all objects.