Should we release the security issues we found in our product as CVE or we can just update those on weekly...
We are a vendor providing a product that is being used in enterprises. We know that those companies having periodic CVE scans on products they are using part of their vulnerability management process. My question is, do we have to raise a CVE if our own security researcher found a vulnerability in our product or we can just raise this vulnerability in the weekly security updates we publish in our official website?
vulnerability known-vulnerabilities cve
add a comment |
We are a vendor providing a product that is being used in enterprises. We know that those companies having periodic CVE scans on products they are using part of their vulnerability management process. My question is, do we have to raise a CVE if our own security researcher found a vulnerability in our product or we can just raise this vulnerability in the weekly security updates we publish in our official website?
vulnerability known-vulnerabilities cve
1
For anyone else wondering... CVE is "Common Vulnerabilities and Exposures" en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures
– RyanS
3 hours ago
add a comment |
We are a vendor providing a product that is being used in enterprises. We know that those companies having periodic CVE scans on products they are using part of their vulnerability management process. My question is, do we have to raise a CVE if our own security researcher found a vulnerability in our product or we can just raise this vulnerability in the weekly security updates we publish in our official website?
vulnerability known-vulnerabilities cve
We are a vendor providing a product that is being used in enterprises. We know that those companies having periodic CVE scans on products they are using part of their vulnerability management process. My question is, do we have to raise a CVE if our own security researcher found a vulnerability in our product or we can just raise this vulnerability in the weekly security updates we publish in our official website?
vulnerability known-vulnerabilities cve
vulnerability known-vulnerabilities cve
asked 6 hours ago
FilopnFilopn
38013
38013
1
For anyone else wondering... CVE is "Common Vulnerabilities and Exposures" en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures
– RyanS
3 hours ago
add a comment |
1
For anyone else wondering... CVE is "Common Vulnerabilities and Exposures" en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures
– RyanS
3 hours ago
1
1
For anyone else wondering... CVE is "Common Vulnerabilities and Exposures" en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures
– RyanS
3 hours ago
For anyone else wondering... CVE is "Common Vulnerabilities and Exposures" en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures
– RyanS
3 hours ago
add a comment |
3 Answers
3
active
oldest
votes
You can do either, but I recommend applying for a CVE so that customers who get threat intelligence feeds are more likely to notice the issue and expedite a patch. Assigning a CVE also makes it easier to reference a specific vulnerability in general communications if you need to later. It's also a signal to your customers that you take security transparency seriously.
CVEs are assigned and managed by MITRE, and you can use the CVE application form to make a request.
add a comment |
It would be helpful to publish the CVE so that others know it's necessary to update: as you said, they can see it in threat intelligence feeds (or CVE scans) instead of having to read the changelog of every update to decide whether they need to update.
Additionally, as a pentester, it helps us a lot in our work. If we find SAPConnectorDeluxe 4.1.39, the first thing we do is check a CVE database for any vulnerabilities. Even if the software is proprietary and in use for only a few companies, it is useful for us to know the risks of running that software so that we can advise the customer correctly.
It also tells us how frequently and what kind of issues are being found: if we see that a small software component had 10 buffer overflow vulnerabilities in the past year, we know the developers don't get the time to include security in their development process. In such a case, it's very likely that more vulnerabilities will be found, or are already found by malicious parties.
Submitting CVEs is not common if the software is only used internally. If we find custom software, we do some analysis (depending on how much time we have) and advise to have someone review its security more thoroughly. Info about internal products would not help anyone outside the company, so there is no need to publish it to a central database like CVE.
add a comment |
You are not required to request a CVE, but you are free to do so when you think it will be benificial.
A CVE is just a central number that identifies a vulnerability, which can assist when communicating about vulnerabilities. CVE's are particularly helpful when there are multiple parties involved. Anyone can request a CVE in your product, but in my opinion it looks better if you do it yourself before somebody else does.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f205271%2fshould-we-release-the-security-issues-we-found-in-our-product-as-cve-or-we-can-j%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can do either, but I recommend applying for a CVE so that customers who get threat intelligence feeds are more likely to notice the issue and expedite a patch. Assigning a CVE also makes it easier to reference a specific vulnerability in general communications if you need to later. It's also a signal to your customers that you take security transparency seriously.
CVEs are assigned and managed by MITRE, and you can use the CVE application form to make a request.
add a comment |
You can do either, but I recommend applying for a CVE so that customers who get threat intelligence feeds are more likely to notice the issue and expedite a patch. Assigning a CVE also makes it easier to reference a specific vulnerability in general communications if you need to later. It's also a signal to your customers that you take security transparency seriously.
CVEs are assigned and managed by MITRE, and you can use the CVE application form to make a request.
add a comment |
You can do either, but I recommend applying for a CVE so that customers who get threat intelligence feeds are more likely to notice the issue and expedite a patch. Assigning a CVE also makes it easier to reference a specific vulnerability in general communications if you need to later. It's also a signal to your customers that you take security transparency seriously.
CVEs are assigned and managed by MITRE, and you can use the CVE application form to make a request.
You can do either, but I recommend applying for a CVE so that customers who get threat intelligence feeds are more likely to notice the issue and expedite a patch. Assigning a CVE also makes it easier to reference a specific vulnerability in general communications if you need to later. It's also a signal to your customers that you take security transparency seriously.
CVEs are assigned and managed by MITRE, and you can use the CVE application form to make a request.
answered 6 hours ago
PolynomialPolynomial
99.7k31245337
99.7k31245337
add a comment |
add a comment |
It would be helpful to publish the CVE so that others know it's necessary to update: as you said, they can see it in threat intelligence feeds (or CVE scans) instead of having to read the changelog of every update to decide whether they need to update.
Additionally, as a pentester, it helps us a lot in our work. If we find SAPConnectorDeluxe 4.1.39, the first thing we do is check a CVE database for any vulnerabilities. Even if the software is proprietary and in use for only a few companies, it is useful for us to know the risks of running that software so that we can advise the customer correctly.
It also tells us how frequently and what kind of issues are being found: if we see that a small software component had 10 buffer overflow vulnerabilities in the past year, we know the developers don't get the time to include security in their development process. In such a case, it's very likely that more vulnerabilities will be found, or are already found by malicious parties.
Submitting CVEs is not common if the software is only used internally. If we find custom software, we do some analysis (depending on how much time we have) and advise to have someone review its security more thoroughly. Info about internal products would not help anyone outside the company, so there is no need to publish it to a central database like CVE.
add a comment |
It would be helpful to publish the CVE so that others know it's necessary to update: as you said, they can see it in threat intelligence feeds (or CVE scans) instead of having to read the changelog of every update to decide whether they need to update.
Additionally, as a pentester, it helps us a lot in our work. If we find SAPConnectorDeluxe 4.1.39, the first thing we do is check a CVE database for any vulnerabilities. Even if the software is proprietary and in use for only a few companies, it is useful for us to know the risks of running that software so that we can advise the customer correctly.
It also tells us how frequently and what kind of issues are being found: if we see that a small software component had 10 buffer overflow vulnerabilities in the past year, we know the developers don't get the time to include security in their development process. In such a case, it's very likely that more vulnerabilities will be found, or are already found by malicious parties.
Submitting CVEs is not common if the software is only used internally. If we find custom software, we do some analysis (depending on how much time we have) and advise to have someone review its security more thoroughly. Info about internal products would not help anyone outside the company, so there is no need to publish it to a central database like CVE.
add a comment |
It would be helpful to publish the CVE so that others know it's necessary to update: as you said, they can see it in threat intelligence feeds (or CVE scans) instead of having to read the changelog of every update to decide whether they need to update.
Additionally, as a pentester, it helps us a lot in our work. If we find SAPConnectorDeluxe 4.1.39, the first thing we do is check a CVE database for any vulnerabilities. Even if the software is proprietary and in use for only a few companies, it is useful for us to know the risks of running that software so that we can advise the customer correctly.
It also tells us how frequently and what kind of issues are being found: if we see that a small software component had 10 buffer overflow vulnerabilities in the past year, we know the developers don't get the time to include security in their development process. In such a case, it's very likely that more vulnerabilities will be found, or are already found by malicious parties.
Submitting CVEs is not common if the software is only used internally. If we find custom software, we do some analysis (depending on how much time we have) and advise to have someone review its security more thoroughly. Info about internal products would not help anyone outside the company, so there is no need to publish it to a central database like CVE.
It would be helpful to publish the CVE so that others know it's necessary to update: as you said, they can see it in threat intelligence feeds (or CVE scans) instead of having to read the changelog of every update to decide whether they need to update.
Additionally, as a pentester, it helps us a lot in our work. If we find SAPConnectorDeluxe 4.1.39, the first thing we do is check a CVE database for any vulnerabilities. Even if the software is proprietary and in use for only a few companies, it is useful for us to know the risks of running that software so that we can advise the customer correctly.
It also tells us how frequently and what kind of issues are being found: if we see that a small software component had 10 buffer overflow vulnerabilities in the past year, we know the developers don't get the time to include security in their development process. In such a case, it's very likely that more vulnerabilities will be found, or are already found by malicious parties.
Submitting CVEs is not common if the software is only used internally. If we find custom software, we do some analysis (depending on how much time we have) and advise to have someone review its security more thoroughly. Info about internal products would not help anyone outside the company, so there is no need to publish it to a central database like CVE.
answered 4 hours ago
LucLuc
23.4k644101
23.4k644101
add a comment |
add a comment |
You are not required to request a CVE, but you are free to do so when you think it will be benificial.
A CVE is just a central number that identifies a vulnerability, which can assist when communicating about vulnerabilities. CVE's are particularly helpful when there are multiple parties involved. Anyone can request a CVE in your product, but in my opinion it looks better if you do it yourself before somebody else does.
add a comment |
You are not required to request a CVE, but you are free to do so when you think it will be benificial.
A CVE is just a central number that identifies a vulnerability, which can assist when communicating about vulnerabilities. CVE's are particularly helpful when there are multiple parties involved. Anyone can request a CVE in your product, but in my opinion it looks better if you do it yourself before somebody else does.
add a comment |
You are not required to request a CVE, but you are free to do so when you think it will be benificial.
A CVE is just a central number that identifies a vulnerability, which can assist when communicating about vulnerabilities. CVE's are particularly helpful when there are multiple parties involved. Anyone can request a CVE in your product, but in my opinion it looks better if you do it yourself before somebody else does.
You are not required to request a CVE, but you are free to do so when you think it will be benificial.
A CVE is just a central number that identifies a vulnerability, which can assist when communicating about vulnerabilities. CVE's are particularly helpful when there are multiple parties involved. Anyone can request a CVE in your product, but in my opinion it looks better if you do it yourself before somebody else does.
answered 5 hours ago
SjoerdSjoerd
20.2k94865
20.2k94865
add a comment |
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f205271%2fshould-we-release-the-security-issues-we-found-in-our-product-as-cve-or-we-can-j%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
For anyone else wondering... CVE is "Common Vulnerabilities and Exposures" en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures
– RyanS
3 hours ago