If you take a look at the EAL levels: Each EAL level introduces a set of security assurance components (SARs) that must be included in the evaluation such that the EAL level is met. If you take a look into the CC documents, you can see that most assurance components are structured hierarchically, and each hierarchy introduces some additional requirements. Take for example ADV_FSP, which is about the quality and extent of the functional specification of the evaluation target:
EAL1 requires ADV_FSP.1
EAL2 requires ADV_FSP.2
...
EAL7 requires ADV_FSP.6
ADV_FSP.1 is an "Informal functional specification", whereas ADV_FSP.2 requires in addition "Fully defined external interfaces". And this goes on and the higher hierarchies include more and more requirements. So in general a higher EAL level implies higher security. However there are two important issues that makes things more complex:
1. The scope of the evaluation. The EAL levels imply that certain assurance components (SARs) are included. You can roughly say that assurance components define how deep and thoroughly something is tested/evaluated. Then there are also the security functional requirements (SFRs), written down in a security target. The SFRs define what is tested - together with the other chapters of a security target they describe the scope of evaluation in a security target. A famous example for some strangeness here is the operating system evaluation for Microsoft Windows XP which is evaluated on EAL4 - however if you take a look at the security target, you will find that a lot of functionality is not described in terms of SFRs and simply taken out of the target of evaluation. Like network access. Which was a major weakness in Windows XP, and common sense dictates that the Windows XP certification really doesn't mean a lot in terms of security. On the other hand this is a perfectly valid approach: You simply focus on one area where the product must be secure, but other areas are out of scope. So you could have vendor A which is a bit more honest and ensures that his whole product is subject to evaluation but is only evaluated to say EAL2, and you could have vendor B which only evaluates a tiny fraction of his product but compiles to EAL4. Then vendor B's product is not necessarily better.
Protection profiles are targeting exactly this problem, as they describe a product in terms of a fixed set of SFRs and/or EAL level. If the security target of a product evaluation is than conformant to that protection profile, you know that the scope of the evaluation is at least as broad as described in the protection profile, and the above example of vendor A and B would simply be impossible if a suitable protection profile existed and both would ensure their products would be in conformance to that protection profile.
2. Augmenting Security Assurance Components (EAL X+). The other answer already mentioned ALC_FLR (documented and formal security flaw reporting and management procedures). This targets software, and basically means that you must have a process in place to ensure that vulnerabilities are fixed. Another very important assurance component is AVA_VAN - vulnerability assessment. This is precisely the part where the evaluation facility will take your product apart and test for vulnerabilities 
CC defines these relationships
EAL1: AVA_VAN.1
EAL2/3: AVA_VAN.2
EAL4: AVA_VAN.3
EAL5: AVA_VAN.4
EAL6/7: AVA_VAN.5
One issue here is that looking at these definitions, if you want to have a high AVA_VAN level, and based on that choose an EAL level that to get say AVA_VAN.5 you would choose EAL6. However EAL6 is suitable for semi-formally verified design and testing, and that might be a complete overkill, since the development process is simply too complex and the whole product development is too costly.
So what is often done in practice is taking a lower EAL level but augmenting it with a higher AVA_VAN level. For example, in the smartcard world you will often see EAL4+ where the + refers to AVA_VAN.5. You can then be sure that the product really can't be broken, hacked/cracked easily, but still the product wasn't necessarily semi formally designed and verified. Or in other words: A product which is EAL4+/AVA_VAN.5 might be practically more secure than a product which is (plain) EAL5, since EAL5 only requires AVA_VAN.4.
