Is this is a concern?

I won't say no but one thing to realize is that Java comes with a lot of things that aren't relevant in any context you are likely to see it used. Almost all of the security vulnerabilities in Java are client-side. That is, most are only applicable when you are using Java plug-ins on your browser. Very few of the Java vulnerabilities are server-side. A lot of IT-admin type people fail to understand this and it's possible they are over-reacting.

On the other hand, a small number of vulnerabilities (e.g. one) can allow for pretty significant exploits so there's really no good argument for not working to patch the JVM.

Overall, though, it's likely that your vendor has creared vulnerabilities in their code or have used libraries with vulnerabilities. I would wager it's far more likely those issues will be exploited than JVM/JDK vulnerabilities. This is suggested stringly by the fact that they seem unable/unwilling to retest their code on a new version of Java. Backwards compatability is very well maintained in Java. It's really unacceptable for them to respond in this way. It implies they have very weak development processes.

What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?

Those are good questions to start. You probably need to have some help though. You might want to have someone do a static analysis (their license may forbid this, however) of the system and/or penetration testing.

Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?

I would. It really should not be an issue. They won't need to change any code, to my knowledge. It's unreasonable for them to refuse.

EDIT: I should add, if this is an application that is running on servers that your IT team controls, you can have your IT people install and run the application on an updated JVM without any assistance from the vendor. It's unlikely there will be any issues unless they are doing something goofy but they might use this as an excuse for not supporting the application. There's no need to recompile or anything, an application written using Java 1.6 should run on a 1.8 JVM.

Is it true that 1.6 is at end of life and therefore no more security patches are generated?

Yes, in 2013. You can buy extended support, however.

Is this is a concern?

I won't say no but one thing to realize is that Java comes with a lot of things that aren't relevant in any context you are likely to see it used. Almost all of the security vulnerabilities in Java are client-side. That is, most are only applicable when you are using Java plug-ins on your browser. Very few of the Java vulnerabilities are server-side. A lot of IT-admin type people fail to understand this and it's possible they are over-reacting.

On the other hand, a small number of vulnerabilities (e.g. one) can allow for pretty significant exploits so there's really no good argument for not working to patch the JVM.

Overall, though, it's likely that your vendor has creared vulnerabilities in their code or have used libraries with vulnerabilities. I would wager it's far more likely those issues will be exploited than JVM/JDK vulnerabilities. This is strongly suggested by the fact that they seem unable/unwilling to retest their code on a new version of Java. Backwards compatability is very well maintained in Java. It's really unacceptable for them to respond in this way. It implies they have very weak development processes.

What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?

Those are good questions to start. You probably need to have some help though. You might want to have someone do a static analysis (their license may forbid this, however) of the system and/or penetration testing.

Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?

I would. It really should not be an issue. They won't need to change any code, to my knowledge. It's unreasonable for them to refuse.

EDIT: I should add, if this is an application that is running on servers that your IT team controls, you can have your IT people install and run the application on an updated JVM without any assistance from the vendor. It's unlikely there will be any issues unless they are doing something goofy but they might use this as an excuse for not supporting the application. There's no need to recompile or anything, an application written using Java 1.6 should run on a 1.8 JVM.

Is it true that 1.6 is at end of life and therefore no more security patches are generated?

Yes, in 2013. You can buy extended support, however.

Is this is a concern?

I won't say no but one thing to realize is that Java comes with a lot of things that aren't relevant in any context you are likely to see it used. Almost all of the security vulnerabilities in Java are client-side. That is, most are only applicable when you are using Java plug-ins on your browser. Very few of the Java vulnerabilities are server-side. A lot of IT-admin type people fail to understand this and it's possible they are over-reacting.

On the other hand, a small number of vulnerabilities (e.g. one) can allow for pretty significant exploits so there's really no good argument for not working to patch the JVM.

Overall, though, it's likely that your vendor has creared vulnerabilities in their code or have used libraries with vulnerabilities. I would wager it's far more likely those issues will be exploited than JVM/JDK vulnerabilities. This is suggested stringly by the fact that they seem unable/unwilling to retest their code on a new version of Java. Backwards compatability is very well maintained in Java. It's really unacceptable for them to respond in this way. It implies they have very weak development processes.

What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?

Those are good questions to start. You probably need to have some help though. You might want to have someone do a static analysis (their license may forbid this, however) of the system and/or penetration testing.

Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?

I would. It really should not be an issue. They won't need to change any code, to my knowledge. It's unreasonable for them to refuse.

Is it true that 1.6 is at end of life and therefore no more security patches are generated?

Yes, in 2013. You can buy extended support, however.

Is this is a concern?

I won't say no but one thing to realize is that Java comes with a lot of things that aren't relevant in any context you are likely to see it used. Almost all of the security vulnerabilities in Java are client-side. That is, most are only applicable when you are using Java plug-ins on your browser. Very few of the Java vulnerabilities are server-side. A lot of IT-admin type people fail to understand this and it's possible they are over-reacting.

On the other hand, a small number of vulnerabilities (e.g. one) can allow for pretty significant exploits so there's really no good argument for not working to patch the JVM.

Overall, though, it's likely that your vendor has creared vulnerabilities in their code or have used libraries with vulnerabilities. I would wager it's far more likely those issues will be exploited than JVM/JDK vulnerabilities. This is suggested stringly by the fact that they seem unable/unwilling to retest their code on a new version of Java. Backwards compatability is very well maintained in Java. It's really unacceptable for them to respond in this way. It implies they have very weak development processes.

What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?

Those are good questions to start. You probably need to have some help though. You might want to have someone do a static analysis (their license may forbid this, however) of the system and/or penetration testing.

Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?

I would. It really should not be an issue. They won't need to change any code, to my knowledge. It's unreasonable for them to refuse.

EDIT: I should add, if this is an application that is running on servers that your IT team controls, you can have your IT people install and run the application on an updated JVM without any assistance from the vendor. It's unlikely there will be any issues unless they are doing something goofy but they might use this as an excuse for not supporting the application. There's no need to recompile or anything, an application written using Java 1.6 should run on a 1.8 JVM.

Is it true that 1.6 is at end of life and therefore no more security patches are generated?

Yes, in 2013. You can buy extended support, however.